Applying Unit Test Harness

[MarcusHolly]

Description

To be completed in the December release:

• Ultraviolet Advanced Oxidation Process @luohezhiming
• Dewatering Unit @adam-a-a
• Electrodialysis 0D & 1D @lbibl
• ElectroN-P @luohezhiming
• Nanofiltration (0D, DSPMDE, & ZO) @adam-a-a
• Pressure Exchanger @luohezhiming
• Stoichiometric Reactor @avdudchenko

Completed in the June release:

• Boron Removal @savannahsakhai Boron removal unit test harness #1415
• Coag & Floc @MarcusHolly Pressure Changer and Coag & Floc Test Harness #1363
• CSTR @agarciadiego test harness for unit models of waste treatment  #1371
• CSTR Injection @agarciadiego test harness for unit models of waste treatment  #1371
• Ion Exchange @kurbansitterley
• 0D Membrane Distillation @ElmiraShamlou
• Osmotically Assisted Reverse Osmosis (0D & 1D) @luohezhiming Unit test harness for OARO models #1367
• Pressure Changer @MarcusHolly Pressure Changer and Coag & Floc Test Harness #1363
• Thickener @agarciadiego test harness for unit models of waste treatment  #1371

Completed in the March Release:

• Reverse Osmosis (0D & 1D) @MarcusHolly Clarifier, Crystallizer & RO Unit Test Harness #1301
• Clairifer @MarcusHolly Clarifier, Crystallizer & RO Unit Test Harness #1301
• Crystallizer @MarcusHolly Clarifier, Crystallizer & RO Unit Test Harness #1301
• Granular Activated Carbon @hunterbarber GAC Test Harness #1311
• Electrolyzer @hunterbarber Electrolyzer Test Harness #1321
• 1D Membrane Distillation @ElmiraShamlou add MD1D #1323

Motivation

This will make unit model testing more standardized across the repository.

Possible Implementation

See Anaerobic Digester Test.

Additional Context

No response

[hunterbarber]

Can I make some changes to UnitTestHarness to add a self.costing_model_block to also assert values on m.fs.costing via self.costing_solutions[m.fs.costing.variable] = value? @TimBartholomew @MarcusHolly Thoughts?

[MarcusHolly]

m.fs.costing seems like it would involve multiple unit models (i.e. a flowsheet), so that seems more like a test that should be included in flowsheet tests as opposed to unit model tests. That being said, do you have an example/application in mind where you think it would be beneficial to have assert the values of m.fs.costing because maybe I'm just missing something.

[hunterbarber]

So maybe this is a call back to the prior decision that the unit model costing blocks don't have a dedicated test folder, and therefore have been tested in the unit model tests. In test_gac.py I was testing the costing package for coverage, but depending on the model (for a single unit model flowsheet) the m.fs.costing or m.fs.unit.costing may be referenced to assert values. So maybe this just means translating the m.fs.costing.variable checks to the m.fs.unit.costing.variable components that can still be accessed through unit_solutions[] (I think?)

[MarcusHolly]

Hmmm, I see. So the options would be to (1) make changes to the UnitTestHarness as you mentioned above or (2) choose to not test m.fs.costing in these tests at all. I'm curious what @TimBartholomew or others think.

As far as translating from m.fs.costing.variable to m.fs.unit.costing.variable, I'm not sure how trivial this is. I tried doing so in the existing GAC test and I get an AttributeError

[hunterbarber]

I have up the GAC test converted to the harness up until the costing variable checks. So I can push for more context but yea, I was also just curious for opinions.

[hunterbarber]

The solution may also be to create a CostingTestHarness in addition to the options we already brought up

[MarcusHolly]

The solution may also be to create a CostingTestHarness in addition to the options we already brought up

I think this sounds good, especially for scenarios where we want to test keeping the operating conditions the same but only change how the costing is handled.

[TimBartholomew]

@MarcusHolly @hunterbarber I think since IDAES and WaterTAP are organized around property, unit, and cost models as separate, that we should make a separate CostingTestHarness and that those tests live under the costing folder.

I think we've been a little loose with mixing unit and cost models together and that in general we should separate them more, specifically the tests and documentation (right now we don't really have costs documented, some unit models have them at the end of their unit model documentation but not all).

The challenge that I see is that the costing test needs a unit model built, specified, and solved (which is what the UnitTestHarness does). I think it would be bad to duplicate the whole unit model build and specification in a separate test file under the costing folder that then uses the CostingTestHarness (one of the points of test harness was to reduce copying and pasting), maybe what we do is that the costing test file imports the build/specifying the variables from the unit test file.

Anyways, what should we do now with our cost tests without a CostingTestHarness being made? I think there are two options:

1. Create a test file for the unit model costing, under the watertap/costing/unit_models/tests. Where you import the build function that creates the unit model and specifies the variables that you made for the UnitTestHarness. Then add costing, scale the model, initialize, and solve, and check costing outputs.
2. Maybe after doing 1, it would be easy and clear to adapt the UnitTestHarness to a new CostingTestHarness to handle the scaling, intialize, solve, and check costing outputs steps

[andrewlee94]

For testing costing, you should mock up a unit model that has only the variable that costing requires. E.g.,

m.dummy_unit = Block()
m.dummy_unit.area = Var()
m.dummy_unit.area.fix(...)

# Add costing to unit

This will let you unit test the costing in isolation. You can then add some integration tests where you double check that it works with a full unit, but you cn run these more sparingly.

[TimBartholomew]

Ohhh interesting. Yeah that could be best. That way all the unit model costing doesn't have to fully solve the detailed model, which is already tested.

[hunterbarber]

For testing costing, you should mock up a unit model that has only the variable that costing requires. E.g.,

m.dummy_unit = Block()
m.dummy_unit.area = Var()
m.dummy_unit.area.fix(...)

# Add costing to unit

This will let you unit test the costing in isolation. You can then add some integration tests where you double check that it works with a full unit, but you cn run these more sparingly.

The WaterTAP costing package does inherit the costing method based on the unit model class, so there will have to be some slightly strategic dummy blocks made here. I'm going to play around with the idea in #1311.

[MarcusHolly]

For testing costing, you should mock up a unit model that has only the variable that costing requires. E.g.,

m.dummy_unit = Block()
m.dummy_unit.area = Var()
m.dummy_unit.area.fix(...)

# Add costing to unit

This will let you unit test the costing in isolation. You can then add some integration tests where you double check that it works with a full unit, but you cn run these more sparingly.

The WaterTAP costing package does inherit the costing method based on the unit model class, so there will have to be some slightly strategic dummy blocks made here. I'm going to play around with the idea in #1311.

Alright, I will play around with this in my PR as well whenever I have some free time.