Support additional Sherwood number calculation

[TimBartholomew]

Description

Add recently published relationship for sherwood number calculation: https://doi.org/10.1016/j.seppur.2022.122121

Motivation

NAWI funded a project to analyze concentration polarization and they found that the sherwood number calculation we use from Guillen and Hoek (2009) can be pretty inaccurate. This NAWI project came up with another correlation and it would be good to add it as an option, or potentially replace Guillen and Hoek's relationship.

Possible Implementation

• Replace the Sherwood number calculation in the membrane channel class
• Or add a configuration argument where users can select which relationship they want to use

Additional Context

This new Sherwood number calculation includes another variable (distance from the RO module entrance), it may make the model harder to solve. We should assess the stability of this formulation.

[hunterbarber]

I understand this is discussion for Sh calculations for membrane units. For variables solved via correlations, is there any motivation to create a centralized location (similar to idaes.core.util.constants.Constants) that enables function calls of variables requiring correlations? For example,

variable_for_correlation(method_enum, required_var_1, ..., required_var_n)

or one example specifically,

liquid_film_transfer_rate('gnielinski',particle_diameter, sphericity, liquid_diffusivity, Re, Sc)

If these correlation variables are dependent on both unit design and fluid properties, it feels odd to house a fluid property correlation in the fluid prop_pack (which I believe is relatively standard convention now) but hard code all of the fluid and unit design dependent correlations (such as Sh) across all unit model codes on an as needed basis.

Just genuinely curious about this and it is up for discussion. Does this inherently break the EO solution structure when implemented via a constraint? (variable == variable_for_correlation(method_enum, required_var_1, ..., required_var_n) Are the correlations so model specific that they will not be relevant across various models? The advantage would be quick change of correlations based on flowsheet or unit op specific requirements and ensuring unified calculations of these correlations across all unit models.

[andrewlee94]

@hunterbarber The first problem I see here is that there is no single (or even short list) of standard correlations for these things. Taking the Nusselt number as an example (that I am familiar with), there are a huge number of correlations for different geometries and applications. Such a library would be huge, and would also need to come with sufficient documentation to explain to users when it should be used, along with a similar amount of testing. Short answer is that whilst it sounds nice, it would be a huge amount of work to do it right.

Secondly, if it were to happen I would have it as a library of separate correlations, not as a method which takes a correlation name as an argument, Having an argument like that tends to lead to it being fragile, difficult to extend, and hard to document (from experience).

[hunterbarber]

@andrewlee94 The exhaustive list of correlations makes a lot of sense to deter away from this. Though, with any predefined list implemented for ease of use, you're never going to be able to suit every niche scenario of lesser used but still relevant correlations.

I would be curious to review the diversity across WaterTAP models, for example seeing if (for a specific variable requiring a correlation) spiral wound and cylindrical geometries are used across 90% or some arbitrary majority of use cases. If every model is hard coding the same 2-3 equations for multiple correlated variables it would become more interesting, but again with the model specificity I'm just not sure if that is the case. There are obviously more complexities such as being valid within ranges of Re, geometries, etc. that would further complicate this.

If it were to happen yes, I was pretty sure there were better ways to implement than what I had said, but I was just hoping to at least clearly convey the idea.

[adam-a-a]

We discovered an issue with applying this new relationship since it is a function of x, the length across the membrane. At the inlet for 0D RO for example, the Sherwood number would be undefined. The problem can also be extended to 1D when number of elements is very high.