AirStripping0D and AirWaterEquilibrium Property Model + Docs #85
Conversation
| self.collision_function_zeta_param_A = a = Param( | ||
| initialize=-0.14329, | ||
| units=pyunits.dimensionless, | ||
| doc="Collision function zeta equation - A parameter", | ||
| ) | ||
|
|
||
| self.collision_function_zeta_param_B = b_ = Param( | ||
| initialize=-0.48343, | ||
| units=pyunits.dimensionless, | ||
| doc="Collision function zeta equation - B parameter", | ||
| ) | ||
|
|
||
| self.collision_function_zeta_param_C = c = Param( | ||
| initialize=0.1939, | ||
| units=pyunits.dimensionless, | ||
| doc="Collision function zeta equation - C parameter", | ||
| ) | ||
|
|
||
| self.collision_function_zeta_param_D = d = Param( | ||
| initialize=0.13612, | ||
| units=pyunits.dimensionless, | ||
| doc="Collision function zeta equation - D parameter", | ||
| ) | ||
|
|
||
| self.collision_function_zeta_param_E = e = Param( | ||
| initialize=-0.20578, | ||
| units=pyunits.dimensionless, | ||
| doc="Collision function zeta equation - E parameter", | ||
| ) | ||
|
|
||
| self.collision_function_zeta_param_F = f = Param( | ||
| initialize=0.083899, | ||
| units=pyunits.dimensionless, | ||
| doc="Collision function zeta equation - F parameter", | ||
| ) | ||
|
|
||
| self.collision_function_zeta_param_G = g = Param( | ||
| initialize=-0.011491, | ||
| units=pyunits.dimensionless, | ||
| doc="Collision function zeta equation - G parameter", | ||
| ) |
There was a problem hiding this comment.
Conventionally, I think these params would typically go on the param block. Any particular reason why you did it this way, other than convenience while developing?
I suppose the only reason it matters is that one would expect to access parameters from the param block, and that'd be pretty consistent with most things in IDAES/WaterTAP, if my recollection is correct.
There was a problem hiding this comment.
I guess the other advantage of doing it this way is that parameters associated with on-demand props wouldn't be built unnecessarily, and building these on the param block would be less straight-forward if you wanted to also build on-demand.
There was a problem hiding this comment.
Both of those reasons are pretty much it.
And I suppose I'd push back a bit on this convention. I don't see the advantage/logic behind putting them on the param block and them always being built, but maybe I am missing something. It makes more sense to me to build property-specific params when the on-demand property is built. I would liken this to how we started putting unit-specific costing parameters only in unit-specific costing packages so they weren't always built and cluttering up calls to .display() or sifting through components via .component_objects() calls (maybe I am the only one that does that regularly though...)
But I definitely won't die on this hill. I am not opposed to putting them on the param block (or making them Vars, which appears to also be convention).
There was a problem hiding this comment.
I won't die on this hill either. There are mountains to climb! =)
Add AWE and basic property pkg docs
kurbansitterley
changed the title
|
@adam-a-a do you mind doing a review of the documentation (added since your last review) |
| Sets | ||
| ---- |
There was a problem hiding this comment.
Did you intend to add sets here?
There was a problem hiding this comment.
oops just added
| doc="Safety factor for tower height", | ||
| doc="Factor to calculate tower height", |
There was a problem hiding this comment.
Minor, but any reason why you moved away from calling it "safety factor"?
There was a problem hiding this comment.
Because it isn't a safety factor. It is just the factor used to calculate the tower height from packing height. i.e., tower_height = packing_height * tower_height_factor
Seemed like a misnomer to me.
Co-authored-by: Adam Atia <[email protected]>
…tertap-seto into air_stripping
src/watertap_contrib/reflo/unit_models/zero_order/tests/test_chemical_softening.py
Outdated
Show resolved
Hide resolved
This PR will add: