Mcas w/generic crystallizer #1487
Conversation
…fig option, rename class
| __author__ = "Oluwamayowa Amusat, Adam Atia" | ||
|
|
||
|
|
||
| def add_crystallizer_rbf_model( |
There was a problem hiding this comment.
I am thinking about bringing this back as a method of the unit model...
There was a problem hiding this comment.
The question is whether we want to do that, or allow the user to define their own function entirely.
I don't think it should be in the unit model file. However, we could support rbfs and maybe even NN models as defaults. We could have the code in a different file that the user can load as the default with optional arguments.
There was a problem hiding this comment.
That was what I was thinking--something along the lines of calling the method on the unit model to build some surrogate(s). And defaults could sit in our data folder with a new directory for default_surrogates or something like that. Either way, I don't love the idea of it living in this test file or in some future example flowsheet file.
| # elif surrogate_model_form == "NN": | ||
| # print("\nNN models selected.\n") | ||
| # add_crystallizer_nn_model( | ||
| # m.fs.cryst, | ||
| # surrogate_inputs_with_bounds=surrogate_inputs, | ||
| # surrogate_outputs=surrogate_outputs, | ||
| # path_to_onnx_model=r"C:\Users\OOAmusat-II\Desktop\NAWI\WATERTAP\Phreeqc\crystallization\NN_40_NL_3_sigmoid_WD_1e-06_LR_0.01_testing.onnx", | ||
| # path_to_offsetscaler_json=r"C:\Users\OOAmusat-II\Desktop\NAWI\WATERTAP\Phreeqc\crystallization\scalingfile_testing.json", | ||
| # surrogate_to_flowsheet_basis_ratio=1, | ||
| # ) | ||
| # else: | ||
| # raise ValueError('"surrogate_model_form" must be "RBF" or "NN"') |
There was a problem hiding this comment.
Can probably test the NN surrogate form as well but just trying rbf first.
There was a problem hiding this comment.
I am going to exclude this for now since it might not be a priority given latest developments.
There was a problem hiding this comment.
This looks good. The main changes seem to be in the way the ion list and vapor property package are handled.
The only comment I have is with your change to the mass balance constraint (eq_mass_balance_constraints(b, j)). You don't fix self.S['H2O'].fix(0.0), but instead, eliminate it from the water mass balance. Do you think the model will be more stable with that change?
There was a problem hiding this comment.
Consider that this was fixed to zero in the first place here, and that we only really need to index S by the ion list, I removed S[j] from the water mass balance.
| # elif surrogate_model_form == "NN": | ||
| # print("\nNN models selected.\n") | ||
| # add_crystallizer_nn_model( | ||
| # m.fs.cryst, | ||
| # surrogate_inputs_with_bounds=surrogate_inputs, | ||
| # surrogate_outputs=surrogate_outputs, | ||
| # path_to_onnx_model=r"C:\Users\OOAmusat-II\Desktop\NAWI\WATERTAP\Phreeqc\crystallization\NN_40_NL_3_sigmoid_WD_1e-06_LR_0.01_testing.onnx", | ||
| # path_to_offsetscaler_json=r"C:\Users\OOAmusat-II\Desktop\NAWI\WATERTAP\Phreeqc\crystallization\scalingfile_testing.json", | ||
| # surrogate_to_flowsheet_basis_ratio=1, | ||
| # ) | ||
| # else: | ||
| # raise ValueError('"surrogate_model_form" must be "RBF" or "NN"') |
| __author__ = "Oluwamayowa Amusat, Adam Atia" | ||
|
|
||
|
|
||
| def add_crystallizer_rbf_model( |
There was a problem hiding this comment.
The question is whether we want to do that, or allow the user to define their own function entirely.
I don't think it should be in the unit model file. However, we could support rbfs and maybe even NN models as defaults. We could have the code in a different file that the user can load as the default with optional arguments.
|
@adam-a-a are you only planning on making the surrogate compatible with MCAS or also the physical model? |
…-a/watertap into mcas_generic_crystallizer
|
@OOAmusat I think this is ready to go. @ElmiraShamlou @carson-tucker @avdudchenko this could use a review from at least one of you so that we can merge this and subsequently bring in Mayo's additional changes |
I would suggest adding saturation vapor pressure, as it directly impacts the system’s energy consumption. It is required for any Crystallizer heat recovery analysis. |
@kurbansitterley for the moment we were just doing this for the surrogate crystallizer, but we can think about doing so for the physical model. I am guessing that accounting for solids in MCAS would up the ante. |
This sounds like something that we can address in a subsequent PR. This PR just focuses on making MCAS compatible with the surrogate crystallizer formulation. As you can see, one of the surrogates incorporated in the test case predicts vapor pressure, but it is treated as a custom function that is separate from the unit model. Thus, it would be on the user to add such surrogates (at this point in time), so I presume that we could do the same with saturation vapor pressure. |
Unless you were implying that we should incorporate |
… idaes naming; also described a config option that was unclear
Fixes/Resolves:
Summary/Motivation:
Building on @OOAmusat 's work on a generic crystallizer by making it compatible with MCAS and also revising to match more closely with IDAES/WaterTAP standards.
Changes proposed in this PR:
Legal Acknowledgement
By contributing to this software project, I agree to the following terms and conditions for my contribution: