Repair erroneous units for material_holdup in CV0D when mass basis defined

[adam-a-a]

Fixes: #1461

Summary/Motivation:

This PR adjusts the units defined for the material_holdup variable constructed in ControlVolume0D, which currently only sets units as mol regardless of whether a mole or mass flow basis is defined. This is a problem when working with a mass flow basis.

Notably, you would only notice this issue if you were constructing a dynamic ControlVolume0D using a mass flow basis, as we are starting to do on WaterTAP.

Changes proposed in this PR:

• set units to mol or mass basis for material_holdup, depending on basis defined for the prop pack
• add tests

Legal Acknowledgement

By contributing to this software project, I agree to the following terms and conditions for my contribution:

1. I agree my contributions are submitted under the license terms described in the LICENSE.txt file at the top level of this directory.
2. I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

[dallan-keylogic]

What happens if f_time_units is None and the first branch is traversed? Then holdup_units isn't assigned. I'm not sure when or why we're allowing flowsheets to have no units, but if it's supported we better support it all the way.

I think it might be that flowsheets are just allowed to have no units at all. In that case, you'd set holdup_units=None in that branch. Can @andrewlee94 confirm?

[adam-a-a]

@dallan-keylogic it looks like tests will fail for cases where dynamic=False and has_holdup=True, so I am going to setup holdup_units separately, under the conditional where has_holdup = True and right before material_holdup is defined.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 71.42857% with 4 lines in your changes missing coverage. Please review.

Project coverage is 76.38%. Comparing base (0db4b73) to head (8e2450c).
Report is 1 commits behind head on main.

Files	Patch %	Lines
idaes/core/base/control_volume0d.py	60.00%	1 Missing and 1 partial ⚠️
idaes/core/util/testing.py	75.00%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1460   +/-   ##
=======================================
  Coverage   76.38%   76.38%           
=======================================
  Files         394      394           
  Lines       65108    65121   +13     
  Branches    14423    14427    +4     
=======================================
+ Hits        49732    49742   +10     
- Misses      12814    12817    +3     
  Partials     2562     2562           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[andrewlee94]

I think this looks good,

[andrewlee94]

What is the intention of this comment?

[adam-a-a]

@andrewlee94 Since I am strictly attempting to fix the issue of using the correct units for holdup when dealing with mass as the material flow basis, here I am setting units to that of mass in that case, and for all other cases, use "amount" [mole], which was how the units were originally hard-coded for material holdup. So, I put this TODO note in case there were other conditionals that we wanted to account for (e.g., unitless, other cases).

[andrewlee94]

Ah - there is a third case which is other, in which case we should assign units of None (note not dimensionless - it is a minor distinction but None here indicates "we don't know" as opposed to actually being dimensionless).

[adam-a-a]

I suppose I can cover this with an else to include other and any other case that might arise, which seems to be consistent with how holdup_units is handled in the ControlVolume1D.

[andrewlee94]

@dallan-keylogic The flowsheet is allowed to have no units, which is mostly a holdover from before units existed. However, in order for there to be a dynamic term, the dynamic config argument must be True and the flowsheet should be insisting on having time units assigned in that case.

[andrewlee94]

@adam-a-a Whilst you are at it, could you check the 1D control volume as well to make sure it does not have the same issue.

[adam-a-a]

@adam-a-a Whilst you are at it, could you check the 1D control volume as well to make sure it does not have the same issue.

@andrewlee94 sure, I can do that. @dallan-keylogic let me know if you think there are edge cases that I should still account for in this PR or not.

[adam-a-a]

@andrewlee94 One problem with setting units to None in the other case for material flow basis is that the material_balances constraint can end up with inconsistent units, unless get_material_flow_terms and get_material_density_terms also return unitless material flow and density terms. I might need to edit StateTestBlockData to account for this in order to get tests to pass, but there could be cascading effects to repair (not sure).

[adam-a-a]

So I checked this (assuming other flow basis and thus dimensionless holdup and accumulation terms), and even if I account for dimensionless material flow and density terms to be returned, volume in the material_holdup_calculation constraint will result in inconsistent units (i.e., dimensionless vs. m**3).

Next step would be to allow for unitless volume in such a case...but before I continue down what seems to be a relatively fruitless path, do you think I should do this, or should we consider being more restrictive and doing away with the unitless option?

[andrewlee94]

@adam-a-a That unit consistency is quite possible OK - with a flow basis of other I would generally expect units to be inconsistent as it is saying "we don't know what the units of this are". other is basically an option to allow users to do what they want, but with the caveat that they take responsibility for making sure their model is consistent.

[adam-a-a]

Suggested change

	self.volume._units = None
	self.volume._units = None

@andrewlee94 - I am guessing you'd opt to remove this bit.

[andrewlee94]

Yes - I'd leave that as is and accept that units will not be consistent. We know what units volume will have from the property package, so we can assign them here.

For example, a flow-on effect of this would be that units would be inconsistent for rate based reactions (where we expect extent = volume*rate). I.e. this is just pushing the error around to a different location. Also note that with a flow basis of other we cannot convert a united reaction rate to the correct units either, so there is a potential second unit inconsistency that arises with flow basis of other (hence my comment that when a user selects other they are taking responsibility for unit consistency themselves).

[andrewlee94]

@adam-a-a Could you confirm that you checked the 1D control volume and that the issue was not present there?

[adam-a-a]

@adam-a-a Could you confirm that you checked the 1D control volume and that the issue was not present there?

@andrewlee94 - yes, I confirmed by reviewing the 1D CV code. I didn't go as far to test directly. The issue was not present there.

[andrewlee94]

@adam-a-a Thank you - adding a test would be a good idea if you could though (to make sure that it does not break in the future).

[adam-a-a]

@adam-a-a Thank you - adding a test would be a good idea if you could though (to make sure that it does not break in the future).

@andrewlee94 OK, added a test to check 1d unit consistency when dynamic and mass basis used

[dallan-keylogic]

LGTM