Add heat exchanger performance and cost components#418
Add heat exchanger performance and cost components#418bayc wants to merge 5 commits intoNatLabRockies:developfrom
Conversation
bayc
force-pushed
the
feature/heat_exchanger
branch
5 times, most recently
from
5cf34b2 to
8c1bcb7
Compare
bayc
force-pushed
the
feature/heat_exchanger
branch
from
8c1bcb7 to
a693f1c
Compare
|
|
||
|
|
||
| class ShellTubeHXCostModel(CostModelBaseClass): | ||
| """_summary_ |
There was a problem hiding this comment.
Remove autodoc string language.
| expected_epsilon = 0.5421484468743297 | ||
| expected_pump_power_kW = 0.28157427036731625 | ||
|
|
||
| assert Q_total_kW == approx(expected_Q_total_kW, rel=1e-2) |
There was a problem hiding this comment.
Make tolerances uniform.
| """_summary_ | ||
| This is a very simple placeholder cost model: | ||
|
|
||
| - Reference: 240,000 USD for a 1 MW HX with U ~ 1000 W/m²-K |
There was a problem hiding this comment.
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)
| 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 |
There was a problem hiding this comment.
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
left a comment
elenya-grant
left a comment
There was a problem hiding this comment.
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
| 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) |
There was a problem hiding this comment.
why is cost year an input to the performance model config? Doesn't look like its used in this model
|
|
||
| # Setup OpenMDAO inputs | ||
| self.add_input( | ||
| "Th_in_C", val=self.config.Th_in_C, units="C", desc="Hot fluid inlet temperature" |
There was a problem hiding this comment.
units="degC", "C" is Coulombs in OpenMDAO units
| ) | ||
|
|
||
| # Setup OpenMDAO outputs | ||
| self.add_output("Th_out_C", val=0.0, units="C", desc="Hot fluid outlet temperature") |
There was a problem hiding this comment.
Same note about units being degC instead of C
| "D_shell": self.config.D_shell_m, | ||
| } | ||
|
|
||
| res = hx_shell_tube_steady(params) |
There was a problem hiding this comment.
I kind of feel like whatever logic is done in the hx_shell_tube_steady() function should be replaced in ShellTubeHXPerformanceModel as a method
| "Tc_in_C", val=self.config.Tc_in_C, units="C", desc="Cold fluid inlet temperature" | ||
| ) | ||
| self.add_input( | ||
| "m_dot_h_kg_s", |
There was a problem hiding this comment.
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
| 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) |
There was a problem hiding this comment.
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_CorHot_temp_CTemp_cold_CorCold_temp_CHot_mass_flow_rate_kg_s
| cost_year (int): Year for cost estimation. | ||
| """ | ||
|
|
||
| Th_in_C: float = field(validator=gt_zero) |
There was a problem hiding this comment.
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?
4 participants
Add HX performance and cost components
This PR adds a simple heat exchanger model, along with a preliminary cost-scaling model.
Section 1: Type of Contribution
Section 2: Draft PR Checklist
TODO:
Type of Reviewer Feedback Requested (on Draft PR)
Structural feedback:
heatfolder to theconvertersdirectory.Implementation feedback:
Other feedback:
Section 3: General PR Checklist
docs/files are up-to-date, or added when necessaryCHANGELOG.mdhas been updated to describe the changes made in this PRSection 3: Related Issues
Section 4: Impacted Areas of the Software
Section 4.1: New Files
path/to/file.extensionmethod1: What and why something was changed in one sentence or less.Section 4.2: Modified Files
path/to/file.extensionmethod1: What and why something was changed in one sentence or less.Section 5: Additional Supporting Information
Section 6: Test Results, if applicable
Section 7 (Optional): New Model Checklist
docs/developer_guide/coding_guidelines.mdattrsclass to define theConfigto load in attributes for the modelBaseConfigorCostModelBaseConfiginitialize()method,setup()method,compute()methodCostModelBaseClasssupported_models.pycreate_financial_modelinh2integrate_model.pytest_all_examples.pydocs/user_guide/model_overview.mddocs/section<model_name>.mdis added to the_toc.yml