Suggestion: functionality in mp1 for returning a string of the phase

[jranalli]

This is potentially a wormhole, but I think it might be useful to have a function that computes the phase for multiphase substances, and/or make it an option to have the string return from the quality function. It is of course easy to determine for yourself, but requires several calls back to pyromat after you get a quality of -1.

It also occurred to me that this might be useful if you ever need to case out certain types of iteration algorithms. For example, fixing state properties given T & h is hard outside the steam dome, but trivial underneath. Whether there are cases where knowing liq vs gas vs supercritical can be useful to the numerical approaches I can't say off the top of my head, but it seems possible. One thing that does come to mind is that you'd expect finding things as a function of T&d to be stiff in the liquid region due to incompressibility, so maybe knowing that would help determine expected uncertainty/accuracy in that region?

Even if it doesn't provide anything for casing out other operations, I can say that it is definitely useful pedagogically.

[chmarti1]

This is an interesting idea. If I understand the idea correctly, you are proposing methods that are specially constructed to deal with the special cases that the properties are under the dome.

As I think about it, I don't think a special function needs to be constructed. In theory, this should already be handled by the new _argparse() algorithm in version 2.2.0. In all of the test cases so far, T,h crashes because it is not well numerically (or theoretically) conditioned. However, you make a good point that it is numerically trivial under the dome. So far, my tests with T,h specified under the dome also fail in the working branch. I'll look more closely to see if we can just write this in.

[jranalli]

I guess I rambled, but it's kind of a two-part idea.

I think substance.phase() that returns a string or ENUM value of the phase would be useful for a variety of purposes.

A separate idea, but one such purpose is adapting numerical conditioning for special cases of substance pairs, such as under-dome properties. There are certainly other ways to tackle that though.

[chmarti1]

For a phase() property, there was a 2011 paper [1] that I've seen cited as proposing a "phase identification parameter" that uses partial derivatives w.r.t. T,v, and p. I have never read the original paper, but adding it as an available property would be one interesting way to satisfy the proposal. Fundamentally, the problem is that the boundary between the super-heated/-cooled regions and super-critical region is not clearly defined. Whatever choice one makes, it winds up being somewhat arbitrary.

I can confirm that _argparse already cases out properties under the dome just like you suggest, but for some reason it really doesn't like T,h - even under the dome. I'll dig in and figure it out.

[1] Venkatarathnam et al. Fluid Phase Equilibria, v301, pg225 2011.

[jranalli]

So I was thinking of liquid, vapor, mixture, supercritical categories. Textbooks and articles seem to define supercritical as both pressure and temperature exceeding the critical values, so there is a basis for using that as the boundary and skipping out on dealing with anything more detailed beyond that.

I skimmed the paper you mentioned and their specific motivation is in dealing with finding the phase for mixtures, where saturation properties are difficult to compute. They seem to suggest that if saturation properties are available, that's the typical method:

The identification of the vapor or liquid phase of a fluid is straightforward when the saturation properties are known.

The appendix of that reference does provide an implementation of the method, provided you can formulate your equation of state into their generic form. But since your current implementation of mp1 can unambiguously compute the steam dome, maybe just using the saturation props would be easier.

[chmarti1]

I've found and corrected the problem in the working code for v2.2.0 that prevented specifying T,h under the dome. There was a typo in the new _argparse() method that caused it to always use entropy as the inverse property... no matter what.

Specifying (T,h) is theoretically sound in liquid and saturated cases. I've tested both for H2O, and they both converge correctly.

I'm going to punt for now on the phase() property. After a major code release, we usually have small fixes / adjustments in the next months. If we decide to, we can always add it there.