Restructure Unit/Property Model Imports; Eliminate Duplicate Prop Model Names

[kurbansitterley]

Fixes/Resolves:

NA

Summary/Motivation:

Currently importing a property model requires also knowing the name of the actual file the parameter block lives in, which is often non-intuitive and cumbersome. Additionally, we have several property models that have the same named parameter block, which is also non-intuitive and cumbersome (and confusing). The same is true for unit models.

This PR modifies the init so you can:

from watertap.property_models import __________

Or for unit models:

from watertap.unit_models import ________

We also have a few property models that share a name:

• NaClParameterBlock is shared by three property models
• WaterParameterBlock is shared by two property models

This PR also renames them to the following:

• NaClParameterBlock for crystallizer is CrystallizerParameterBlock
• NaClParameterBlock for the temperature dependent property model is NaClTDepParameterBlock
• WaterParameterBlock for the ZO property model is now ZOParameterBlock

This PR also cleaned up and improves the import structure in many unit files to follow

stdlib imports

third-party imports

pyomo imports

idaes imports

idaes-flowsheet-processor imports

watertap imports

THIS ORDER WOULD BE ENFORCED BY A TEST test_import_order.py

Imports are updated where necessary. Docs are updated where necessary.

Changes proposed in this PR:

• restructure property package imports
• add all unit models to unit_models init
• eliminate duplicate names of property models to be more intuitive and rename tests to reflect new names
• move ZO property package to property_models and rename to zero_order_prop_pack
• move, improve, and correct ZO property model docs to property model section of docs
• add import headers to all prop model doc files
• update/improve/clean up imports where necessary in entire package
• update docs to reflect all changes

TO DO:

• continue updating imports where necessary
• update docs to reflect changes where necessary
• add deprecation warnings

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.

[adam-a-a]

Suggested change

	pair: watertap.core.zero_order_properties;ZOParameterBlock

SHould this pair be updated too?

[kurbansitterley]

yeah docs are still a TO DO

[adam-a-a]

Suggested change

	The ideal water properties module (zero-order property model) contains a simple property package for saline waters which is intended for use with the WaterTap zero-order unit model library. The ideal water property package can be used in a flowsheet as shown below:

Shouldn't we update the description a little bit?

[kurbansitterley]

Yes definitely. I would argue we should drop the "ideal properties" language entirely

[kurbansitterley]

This doc was re-written and moved.

[adam-a-a]

No big deal, but I noticed that in another file change, you switched to importing MaterialFlowBasis from idaes.core. That said, I prefer having MaterialFlowBasis importable from watertap.property_models too for convenience.

[kurbansitterley]

I agree and I was going to do this but thought I would get pushback because it would require doing from idaes.core import MaterialFlowBasis in the init and I am not sure if that is a packaging no-no. But I can add it

[adam-a-a]

just a note on consistency---in other files, you do import ZOParameterBlock--but not here.

[kurbansitterley]

Yeah haven't finished cleaning things up yet. I intend to be consistent across all files.

[sufikaur]

Probably want to come back to this soon since a new release cycle has just begun

[ksbeattie]

@kurbansitterley might you consider breaking this PR up into a few smaller ones? i.e. one for the import reorder, one for the renaming and one for changes in the way the imports are actually done.