← Back to project catalogue
GP-CH-07UHKLXChemicalReady

Multi-Period Pinch Analysis and Variable Utility Temperature Resilience Study

A completed chemical-engineering study of heat-recovery targets, variable steam and cooling conditions, utility allocation, minimum-approach sensitivity, and multi-period resilience.

Multi-Period Pinch Analysis and Variable Utility Temperature Resilience Study project visual
GP-CH-07UHKLX · Chemical
  • Python 3.14
  • OpenPinch 0.5.4
  • NumPy
  • Pandas
  • Matplotlib
  • Seaborn

Project definition

Problem statement

Process heat-recovery targets are often calculated at one nominal condition even though throughput, stream duties, steam conditions, cooling-water temperature, prices, and annual operating hours vary.

The chemical engineering problem is to separate process targets from utility allocation, compare several operating periods, screen utility-temperature limits, and preserve every assumption and result in a reproducible evidence chain.

Project objectives

  • Reproduce process pinch targets for turndown, base, and peak operation from one retained OpenPinch case.
  • Compare fixed, seasonal, stressed primary-only, and resilient multi-utility portfolios.
  • Calculate annual screening cost and emissions with declared operating hours and factors.
  • Measure sensitivity to eight minimum process approach temperatures across all three periods.
  • Screen thirty-five peak-period steam and cooling-water temperature combinations.
  • Keep targeting claims separate from exchanger-network, plant, safety, and investment claims.

Project structure

Project components

01

Period materialisation

Selects each period vector explicitly and creates one auditable scalar OpenPinch case.

02

Pinch targeting

Calculates minimum hot utility, minimum cold utility, maximum process recovery, pinch temperature, composite curves, and grand composite curves.

03

Utility allocation

Evaluates several hot and cold utility levels under declared temperatures, prices, and screening carbon factors.

04

Resilience experiments

Runs the Delta Tmin study and peak utility-temperature grid while recording conservative terminal clearances.

05

Evidence and verification

Generates ten result tables, eighteen figures, documents, tests, audits, and a non-root Docker check.

Methodology

Project workflow

  1. 01
    Verify the retained case

    Check the source identity and extract the seven stream records for three declared periods.

  2. 02
    Calculate process targets

    Run OpenPinch independently for turndown, base, and peak operation.

  3. 03
    Allocate utilities

    Apply each declared utility portfolio without changing the process heat targets.

  4. 04
    Run sensitivity studies

    Vary Delta Tmin, medium-pressure steam temperature, and cooling-water temperature over bounded grids.

  5. 05
    Interpret the evidence

    Compare annual cost, screening emissions, terminal clearances, and the declared score with explicit limitations.

Demonstration scenario

At 10 C Delta Tmin, the retained case requires 184.375 kW of hot utility at turndown, 750.000 kW at base operation, and 1336.976 kW at peak operation. The demonstration then compares four utility portfolios, shows how the resilient ladder improves on the stressed primary-only case, and identifies seventeen flagged combinations in the peak utility-temperature grid.

Engineering

Tools and method

Tools
The project uses Python 3.14, OpenPinch 0.5.4, NumPy, Pandas, Matplotlib, Seaborn for subject analysis, simulation, and results.
Pinch engine
OpenPinch 0.5.4 performs problem-table targeting, composite curves, grand composite curves, and multi-utility allocation.
Experiment layer
Python and NumPy materialise periods, run scenario grids, calculate annual summaries, and preserve claim boundaries.
Evidence layer
Pandas, Matplotlib, and Seaborn create committed tables and figures from retained inputs.
Verification
Tests, linting, checksums, dependency audit, document inspection, repository validation, and Docker execution verify the handover.

Testing

Evaluation

Evaluation measures

  • Minimum hot utility, minimum cold utility, and maximum process heat recovery in each period
  • Utility-level duty allocation under all four declared portfolios
  • Weighted annual screening cost and emissions
  • Primary hot and cold terminal clearances
  • Target sensitivity across eight Delta Tmin values
  • Peak-period response across thirty-five utility-temperature combinations
  • Automated tests, coverage, dependency audit, document audit, and non-root Docker execution

Project boundaries

  • The retained source is a maintained OpenPinch example and not reconciled data from a disclosed refinery.
  • Costs, carbon factors, utility conditions, operating hours, and the decision score are declared screening assumptions.
  • A negative conservative primary clearance does not prove that the complete multi-utility portfolio is infeasible.
  • The study does not design exchanger matches, area, hydraulics, materials, fouling allowance, control, safety, or construction.
  • Plant use requires site data, exchanger-network synthesis, dynamic analysis, safety review, and verified economics.

Included

  1. 01Complete Python process-integration source code
  2. 02Retained seven-stream and three-period source case with exact checksum
  3. 03Four fixed, seasonal, stressed, and resilient utility scenarios
  4. 04Twenty-four minimum-approach sensitivity cases and a thirty-five-case peak utility grid
  5. 05Ten generated result tables and eighteen analytical figures
  6. 0688-page project documentation in PDF and editable Word formats
  7. 0714-page setup and usage guide in PDF and editable Word formats
  8. 08Forty-five annotated references and three licensed literature images
  9. 09Twenty-one automated tests with 98.87 percent branch-aware coverage
  10. 10Complete project files, calculations, results, and analysis material in a private GitHub repository

Project record

No information is collected on this page.

Permanent project ID
GP-CH-07UHKLX
Catalogued
21 Aug 2026
Completed
27 Aug 2026
Verified
27 Aug 2026
Demonstration
Included in repository

Handover

After purchase

  1. 01
    Payment is confirmed

    The project is marked unavailable and cannot be purchased again.

  2. 02
    Repository access is granted

    The buyer's submitted GitHub account receives access to the private repository.

  3. 03
    The purchase record is delivered

    The certification sheet is prepared from the reviewed buyer details and sent privately by email.