PT flash calculations at saturation should fail

[ianhbell]

In my case, I am using an ECS fluid file, but nonetheless, when I do calculations with PT as input variables at saturation, this is an indeterminate set of inputs, and it should not yield any answer. Example:

from ctREFPROP.ctREFPROP import REFPROPFunctionLibrary
RP = REFPROPFunctionLibrary('D:\\REFPROP')
RP.SETPATHdll('D:\\REFPROP')
MOLAR_BASE_SI = RP.GETENUMdll(0, "MOLAR BASE SI").iEnum
T = 300
psat, rho = RP.REFPROPdll('Water',"QT","P;D",MOLAR_BASE_SI,0,0,0,T,[1.0]).Output[0:2]
print(psat,rho)
r = RP.REFPROPdll('Water',"PT","D",MOLAR_BASE_SI,0,0,psat,T,[1.0])
print(r.Output[0], r.ierr, r.herr)

yields (note ierr=0, no error message, vapor density)

3536.8068034278945 55314.91551874966
1.4204437066224727 0 

[ianhbell]

I should of course mention this is only the case for pure fluids.

[nist-aharvey]

I dunno -- hard to imagine checking every pure-component P-T flash to see if it is exactly on the saturation curve, as opposed to, say, a machine precision bit on one side or the other. Such checks might also be problematic with finite convergence tolerances for the saturation calculation.

[EricLemmon]

These have also been my thoughts, I have always left it up to the user to look at the density and see if he or she got back the answer they wanted. Perhaps not the best solution, but most people are aware enough of this that it has only been a problem for just a handful of people.

[ianhbell]

Yes, once you look at the density, it’s clear, but without, not at all. I much, much prefer CoolProp’s approach. There are a lot of non-expert users of REFPROP, and we should hold their hands. (We can use ancillaries to check for phase boundary, which is the approach taken in CoolProp).

[EricLemmon]

I'm going to close this one as well, it also has the feature-request label and we'll return to it later.