Add heat exchanger performance and cost components by bayc · Pull Request #418 · NatLabRockies/H2Integrate

bayc · 2025-12-18T19:57:44Z

Add HX performance and cost components

This PR adds a simple heat exchanger model, along with a cost model. This model is meant to be used with other models that are being developed, such as the electric thermal energy storage model #810 and a yet to be opened electric/natural gas boiler model PR. As such, an explicit example using this technology has not yet been added, but will be as part of an integrated example of these components.

This model is meant to accept two fluids, a source fluid (that brings the heat) and a working fluid (that removes the heat). I would appreciate specific review on the implementation of these inputs/outputs and whether they should be changed in some way to reflect commodity streams, or some other form.

Also, review of the organization of the code would be helpful. I originally had the specific heat exchanger functions located in a sub-folder converters/heat/heat_exchanger_model, but the current version has those functions integrated directly into the model class. So feedback on which method will determine what remains and what gets removed.

Docs will be updated once reviewed to be informed by any required changes.

Section 1: Type of Contribution

Section 2: Draft PR Checklist

Open draft PR
Describe the feature that will be added
Fill out TODO list steps
Describe requested feedback from reviewers on draft PR
Complete Section 7: New Model Checklist (if applicable)

TODO:

Have TLDRD team review implementation of model.
Determine whether an example is needed now or later (once other heat components get added).
Ask for reviews from H2I team once above are complete.

Type of Reviewer Feedback Requested (on Draft PR)

Structural feedback:

Feedback on the addition of a heat folder to the converters directory.

Implementation feedback:

The specifications of the incoming and outgoing heat exchanging fluids as OpenMDAO inputs and outputs

Other feedback:

Section 3: General PR Checklist

PR description thoroughly describes the new feature, bug fix, etc.
Added tests for new functionality or bug fixes
Tests pass (If not, and this is expected, please elaborate in the Section 6: Test Results)
Documentation
- Docstrings are up-to-date
- Related docs/ files are up-to-date, or added when necessary
- Documentation has been rebuilt successfully
- Examples have been updated (if applicable)
CHANGELOG.md has been updated to describe the changes made in this PR

Section 3: Related Issues

Section 4: Impacted Areas of the Software

Section 4.1: New Files

converters/heat/shell_tube_hx.py
- Contains the heat exchanger model.
converters/heat/shell_tube_hx_cost_model.py
- Contains the heat exchanger cost model.
converters/heat/test/test_shell_tube_hx.py
- Simple test for heat exchanger.
converters/heat/test/test_shell_tube_hx_cost_model.py
- Simple test for heat exchanger cost model.

Section 4.2: Modified Files

Section 5: Additional Supporting Information

Section 6: Test Results, if applicable

Section 7 (Optional): New Model Checklist

alidor85 · 2026-01-23T18:59:39Z

+    """_summary_
+    This is a very simple placeholder cost model:
+
+    - Reference: 240,000 USD for a 1 MW HX with U ~ 1000 W/m²-K


I don't know the source for this function, I would rather use something from a chemical plant design handbook.
From Sinott and Towler (2021):
U-tube shell and tube HX:
Total installed costs = [(a+b*S^n) * f_year * f_install * f_material]
a = 28000
b = 54
n = 1.2
S - heat transfer area in m^2
limits: 10 m^2 <= S <= 1000 m^2

This is in CEPCI index = 532.9 so need to be converted (it's for Jan. 2010)
To get it to 2022 USD f_year = 816/532.9

f_install = 1.61 (default, maybe let the user add their own?)

It also assums simple carbon steel, so we need to account for materials once temperatures are higher
f_material = 1 for carbon steel (should be a default value), if user specifies another more expensive material they should include f_material

For the OpEx I am not sure we want to include it in a cost function, this should be in the general economic calculation (like ProFAST)

alidor85 · 2026-01-23T19:01:10Z

+        exp_Q = inputs["exp_Q"][0]
+
+        scale_Q = (Q_total_W / Q_ref) ** exp_Q if Q_total_W > 0 else 0.0
+        capex = C_ref * scale_Q


Do we want to add installation factor in here, or are those things usually accounted for elsewhere in H2I analysis?
I think in ther steel paper at least the cost functions are for totat installed costs

elenya-grant

Howdy Chris! I'm not sure whether this is ready for a full in-depth review yet but I left a few small comments and did a quick review (I will do another deeper-review once this is not longer a draft). Overall it seems like some very useful and cool functionality! Thanks for the work on this!

Some higher-level notes are:

heat_exchanger_model/hx_shell_tube_steady.py: more inline comments and docstrings would be helpful in the functions defined in here
Could you update the performance model to use the recently introduced PerformanceModelBaseClass? I'd be happy to help here if needed!
Don't forget to add the performance and cost model(s) to supported_models.py

elenya-grant · 2026-02-09T17:06:50Z

+    D_o_m: float = field(validator=gt_zero)
+    t_wall_m: float = field(validator=gt_zero)
+    D_shell_m: float = field(validator=gt_zero)
+    cost_year: int = field(validator=gt_zero)


why is cost year an input to the performance model config? Doesn't look like its used in this model

Copied from other code, good catch!

elenya-grant · 2026-02-09T17:07:41Z

+
+        # Setup OpenMDAO inputs
+        self.add_input(
+            "Th_in_C", val=self.config.Th_in_C, units="C", desc="Hot fluid inlet temperature"


units="degC", "C" is Coulombs in OpenMDAO units

I wonder if we will ever model Coulombs...

elenya-grant · 2026-02-09T17:08:11Z

+        )
+
+        # Setup OpenMDAO outputs
+        self.add_output("Th_out_C", val=0.0, units="C", desc="Hot fluid outlet temperature")


Same note about units being degC instead of C

elenya-grant · 2026-02-09T17:11:44Z

+            "D_shell": self.config.D_shell_m,
+        }
+
+        res = hx_shell_tube_steady(params)


I kind of feel like whatever logic is done in the hx_shell_tube_steady() function should be replaced in ShellTubeHXPerformanceModel as a method

I could understand the reasoning there. The reason why I kept it in a separate file is because that method is ~600 lines of code. Plus the model comes with some printing and plotting utilities. I will move them into the class and have you take a look to see if you think it is better or if keeping them separate is preferred.

Moved! Let me know what you think.

elenya-grant · 2026-02-09T17:17:28Z

+            "Tc_in_C", val=self.config.Tc_in_C, units="C", desc="Cold fluid inlet temperature"
+        )
+        self.add_input(
+            "m_dot_h_kg_s",


I don't think these input and output names should have units in them - because it gets confusing if I did prob.model.get_val("hx.m_dot_h_kg_s", units="kg/h"). I do think units are appropriate for the config input names

elenya-grant · 2026-02-09T17:27:35Z

+    Th_in_C: float = field(validator=gt_zero)
+    Tc_in_C: float = field(validator=gt_zero)
+    m_dot_h_kg_s: float = field(validator=gt_zero)
+    m_dot_c_kg_s: float = field(validator=gt_zero)


I understand that the h and c in the variable names mean "hot" and "cold" but I think that it'd be nice to have the "hot" and "cold" within the variable names themselves, something like:

Temp_hot_C or Hot_temp_C

Temp_cold_C or Cold_temp_C

Hot_mass_flow_rate_kg_s

I've tried to update all the inputs and outputs to be spelled out.

elenya-grant · 2026-02-09T17:30:55Z

+        cost_year (int): Year for cost estimation.
+    """
+
+    Th_in_C: float = field(validator=gt_zero)


Perhaps this relates to PR #480, but I think that this could be generalized to just define the two commodities coming into the heat exchanger. Then in ShellTubeHXPerformanceModel, the inputs would be something like: f"{commodity1}_in_temp", f"{commodity2}_in_temp", f"{commodity1}_in", f"{commodity2}_in".

Is the "hot" thing in just hotter than the "cold" thing in (if so - then the model could see which one is hotter rather than having the user define it). Or is the "hot" thing the thing getting heated?

I am not sure if it ties to #480, to be honest. I could see the generalization happening as the commodities would be the working fluid and the source fluid, which the temperatures of which would be defined by other components. The "cold" thing (working fluid) is the thing getting heated by the "hot" thing (source fluid). For example, the working fluid could be a feedstock for a food/beverage process, while the source fluid could be water that is heated from an electric boiler.

Can you re-evaluate this with respect to #480 now that that is merged in and see if your thoughts/suggestions have changed at all? If not, I can work to implement the generalization as you suggested.

I think you're right - I don't think this is related to PR #480 (what a long time ago that was). I haven't re-looked into the code yet, and I understand your definition of the working fluid vs source fluid. But what if the food/beverage process feedstock had more thermal energy than the water - then the working fluid would be the water and the source fluid would be the food/beverage feedstock - right? I'll update this comment in a sec - I'm going to look back at the code real quick.

Okay - my above comment was more related to the openmdao inputs rather than the config inputs. I guess I was imaging this as almost a transport model instead of a converter. Like - where I could connect the temperature and "out" of two commodity streams to this heat exchanger and that it'd output the temperate after heat has been exchanged. If that's the intended usage - then I think that some of these config inputs would not be necessary because they'd be inputs from upstream techs. Anyway - I think that using this model as a transport model instead is probably out of scope for this PR. So - no changes necessary on this topic!

…into feature/heat_exchanger

…nger

* initial example files for plm for a converter * run converter plm with single demand profile * have precommit ignore demand profiles for converter plm example * peak load converter working with multiple demand profiles * minor plot updates * remove incorrect comments * add key file that was missed earlier * include init file * update units/naming * bugfix, grap element instead of array * include price dispatch capability to converter demand control * wip * include unit definitions for peak cutoff * update naming: * Fuel Cell Operational Calculations (NatLabRockies#5) * varopex * refurb schedule * update fuel cell schedule calc to allow for non-integer multiples of eol and timesteps * extend liftime for schedule test * Update h2integrate/converters/hydrogen/h2_fuel_cell.py --------- Co-authored-by: Jared Thomas <jaredthomas68@gmail.com> Co-authored-by: Jared Thomas <jaredthomas68@users.noreply.github.com> * move demand profiles for examples to library and update converter plm example to work with latest changes in H2I * put converter and storage peak load management examples in subfolders under a single example * reformat and fix pre-commit hook ignores * move heuristic plm examples to 33_peak_load_management_heuristics * rename run files for example 33 * update docstrings and example descriptions for plm heuristic * update descriptions * make plm converter controller tech agnostic by using rated production instead of capacity * set time step bounds and add example tests for plm converter example * update docs to include the converter plm controller * update changelog * update class hierarchy * update doc strings, class hierarchy, model overview, and comments * rename and move converter controller section * update path in test * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * update based on copilot review * minor updates based on copilot feedback * fix docs * Minor doc/comment changes * include tests for plm openloop converter controller * change from 'electricity' to 'commodity' for kind spec * add clarifying comments to demand profiles * naming changes and vectorizing * fix doc string indentation * add example for price mode * correct changelog * include reorganized and new price profile example files --------- Co-authored-by: kbrunik <102193481+kbrunik@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: kbrunik <kbrunik@gmail.com> Co-authored-by: John Jasa <johnjasa11@gmail.com>

…ification

…nger

bayc added 2 commits December 18, 2025 12:46

add shell tube heat exchanger peformance model and test

1db1ccb

add shell tube heat exchanger cost model and test

ebe2fcc

bayc self-assigned this Dec 18, 2025

bayc added enhancement New feature or request in progress labels Dec 18, 2025

bayc marked this pull request as draft December 18, 2025 19:58

bayc force-pushed the feature/heat_exchanger branch 5 times, most recently from 5cf34b2 to 8c1bcb7 Compare December 18, 2025 20:50

pre-commit formatting

a693f1c

bayc force-pushed the feature/heat_exchanger branch from 8c1bcb7 to a693f1c Compare December 18, 2025 20:58

bayc commented Jan 6, 2026

View reviewed changes

Comment thread h2integrate/converters/heat/shell_tube_hx_cost_model.py Outdated

bayc commented Jan 6, 2026

View reviewed changes

Comment thread h2integrate/converters/heat/test/test_shell_tube_hx.py Outdated

Merge branch 'develop' into feature/heat_exchanger

137ae08

elenya-grant self-requested a review January 22, 2026 20:39

alidor85 reviewed Jan 23, 2026

View reviewed changes

update costmodelbaseconfig import

3173feb

elenya-grant requested changes Feb 9, 2026

View reviewed changes

johnjasa and others added 4 commits February 12, 2026 10:57

Merge branch 'develop' into feature/heat_exchanger

94dd5a8

Merge branch 'develop' into feature/heat_exchanger

36749c5

Merge branch 'feature/heat_exchanger' of github.com:bayc/H2Integrate …

788016c

…into feature/heat_exchanger

Merge remote-tracking branch 'origin/develop' into feature/heat_excha…

8719f70

…nger

bayc closed this Apr 15, 2026

bayc added 4 commits April 17, 2026 16:44

udpate tests

88e0a95

Merge remote-tracking branch 'origin/develop' into feature/heat_excha…

bb9c489

…nger

updates due to changes in develop

affd61e

Merge remote-tracking branch 'origin/develop' into feature/heat_excha…

61eab03

…nger

jaredthomas68 and others added 30 commits August 26, 2026 15:36

replace custom validators with direct replacement built-in validators

b5841bb

add handling for single key input for validation

b6fc100

replace contains with attrs.validators.in_

7cef364

remove contains

85bfc39

remove has_required_keys with deep_mapping

3574718

update changelog

f5ef373

update docs references to validators

63c9f8d

add pr #

52fcaeb

fix find and replace error

791b89b

replace missed validators

021a16a

replace must_equal with in_

5c94d9e

Fixing import

d21bd62

Fixing example plant config

c31983c

fix validators

f3c386e

remove unused heat rate input

ffa2d23

Do not check demand component commodity reception for interconnections

f425443

Updated changelog

1fbf16a

correct tests for ng cost model adjustment

8d434d6

switch from generator nameplate spec to generator oversize ratio spec…

ebd5e3e

…ification

Added more precise checks for demand components

7de9fce

switch to num turbines model, modify ng cost model for compatibiliy

bb1e7f9

Moved NGCT definitions

e95064c

Made the run_turbine method always deal with lists

dc96190

Note functions just used for testing

7413f30

Cleanup and docstring addition

5a424e7

fix ngct tests and adjust cost model compatibility per PR discussions

cef659d

adjust tests to conform with new ng cost model form

5f7de06

add multivariable commodity streams

5856c83

Merge remote-tracking branch 'origin/develop' into feature/heat_excha…

875c901

…nger

Uh oh!

Conversation

bayc commented Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Add HX performance and cost components

Section 1: Type of Contribution

Section 2: Draft PR Checklist

TODO:

Type of Reviewer Feedback Requested (on Draft PR)

Section 3: General PR Checklist

Section 3: Related Issues

Section 4: Impacted Areas of the Software

Section 4.1: New Files

Section 4.2: Modified Files

Section 5: Additional Supporting Information

Section 6: Test Results, if applicable

Section 7 (Optional): New Model Checklist

Uh oh!

Uh oh!

Uh oh!

alidor85 Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elenya-grant left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

bayc commented Dec 18, 2025 •

edited

Loading

alidor85 Jan 23, 2026 •

edited

Loading