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

kbrunik

Exciting stuff! It was fun getting a chance to dig into it a little. Overall I think it's coming along, I have a few bigger comments particularly regarding the use of a multivariable commodity that I'd love to address before this is ready to come in. Thanks for putting this together though, I think it's really pushing the boudaries of H2I as we know it :)

kbrunik · 2026-08-06T22:11:12Z

+        )
+
+        # Setup OpenMDAO inputs
+        self.add_input(


Hey I saw your discussion with @elenya-grant about PR #480 and I was thinking more about it. H2I currently focuses on passing commodities or physical mass/electrons around a system. @johnjasa added the notion of multivariable commodities where you can add things like temperature and pressure to the commodity. I think to maintain our structure and plan for a larger heat integration effort in the future we should use that paradigm when handling the heat exchanger so your commodities would be your working fluid and your process fluid and those would have associated temperatures and mass flows. Then you would be able to add a commodity that can be more easily tracked in h2i. This converter has a good example of how to add inputs and outputs that way: https://github.com/NatLabRockies/H2Integrate/blob/develop/h2integrate/converters/natural_gas/dummy_gas_components.py

It might not be fully necessary in this PR to move in this direction but I do think in the long run it's going to be easier on the user to appropriately track heat across their system (through things like combiners, splitters and transporters).

kbrunik · 2026-08-06T22:13:02Z

+            "temp_cold_out", val=0.0, units="degC", desc="Cold fluid outlet temperature"
+        )
+        self.add_output("Q_total", val=0.0, units="kW", desc="Total heat transfer rate")
+        self.add_output("epsilon", val=0.0, desc="Effectiveness of the heat exchanger")


On naming outputs it would be really helpful if the OpenMDAO outputs were more descriptive. Also, I've seen it a few places but be sure to keep the units out of the OpenMDAO name.

kbrunik · 2026-08-06T22:14:34Z

@@ -0,0 +1,916 @@
+"""


This file looks duplicative with what's in the body of the ShellTubeHXPerformanceModel, I'd suggest removing this.

kbrunik · 2026-08-06T22:19:09Z

+
+@define(kw_only=True)
+class ShellTubeHXPerformanceModelConfig(BaseConfig):
+    """


I would suggest adding an optional argument to be able to plot using the plot_results() function

kbrunik · 2026-08-06T22:20:02Z

+    # ----------------------------------------------------------------------
+    # 4) Printing summary utility
+    # ----------------------------------------------------------------------
+    def print_summary(res, label="Python + CoolProp"):


suggest removing or adding an option for a user set in the config to print the summary.

kbrunik · 2026-08-06T22:24:04Z

+        Tc_out0_max = Th_in - 1e-3
+        Tc_out0_guess = Tc_in + 0.7 * (Th_in - Tc_in)
+
+        def march_segments(Th_in_local, Tc_out0_local):


I would suggest adding at least a docstring to this function

kbrunik · 2026-08-06T22:25:38Z

+                S_gen_seg,
+            )
+
+        def residual_Tc_out(Tc_out0):


A docstring would be helpful

kbrunik · 2026-08-06T22:25:47Z

+            return Tc_at_L - Tc_in
+
+        # Simple bisection
+        def find_root_bisect(f, a, b, tol, maxit):


Also a docstring here

kbrunik · 2026-08-06T22:27:48Z

+    # ----------------------------------------------------------------------
+    # 3) Main HX model
+    # ----------------------------------------------------------------------
+    def hx_shell_tube_steady(self, params=None):


Are there any conditions that would cause this hx model to not work properly and are they captured by the attrs validators or are there some additional errors/warnings that should be added?

kbrunik · 2026-08-06T22:28:51Z

+
+class ShellTubeHXPerformanceModel(om.ExplicitComponent):
+    """
+    An OpenMDAO component that wraps the steady shell tube heat exchanger model.


steady state?

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

bayc added 2 commits May 21, 2026 11:37

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

092f51e

…nger

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

2c0e9b3

…nger

bayc reopened this Jul 22, 2026

pre-commit formatting

f9bfe3a

bayc force-pushed the feature/heat_exchanger branch from 445a159 to f9bfe3a Compare July 22, 2026 15:58

bayc added 6 commits August 4, 2026 07:56

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

f518834

…nger

update cost model

affc71e

naming updates and reorg

45eedd1

add to supported models

979352c

pre-commit updates

f0738a9

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

66c36e1

…nger

bayc marked this pull request as ready for review August 6, 2026 17:57

bayc added 6 commits August 6, 2026 11:01

remove outdate PR template option

a6d6aa7

add models to __init__

837cc21

correct validator import

b1e7ee2

fix import error in __init__

bcfb881

add missing test __init__

959e8eb

update docstring

57626d0

bayc requested review from jaredthomas68, johnjasa and kbrunik August 6, 2026 18:47

kbrunik requested changes Aug 6, 2026

View reviewed changes

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!

kbrunik 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!

bayc commented Dec 18, 2025 •

edited

Loading

alidor85 Jan 23, 2026 •

edited

Loading