Heat of vaporization (and others) should not be valid for single-phase states

[ianhbell]

In the GUI, if you provide a single-phase state, the heat of vaporization (and other things like it) is not allowed as an output (sensible, in my opinion):

In the DLL, it is allowed, and not only is it allowed, it yields inconsistent values. For DPDTSAT, the results are the same (using the temperature?), whereas for the other two, the TQ and TP inputs yield different results:

import os
from ctREFPROP.ctREFPROP import REFPROPFunctionLibrary
RP = REFPROPFunctionLibrary(os.environ['RPPREFIX'])
print(RP.RPVersion())

for hOut in ['DPDTSAT','DHDZSAT','HVAP']:
    for hIn, inps in [('TP', (300, 101325)), ('TQ', (300,1.0))]:
        print(hIn, inps)
        r = RP.REFPROPdll("PROPANE", hIn, hOut, RP.MOLAR_BASE_SI, 0, 0, *inps, [1])
        print(r.ierr, r.herr, r.Output[0], r.q)

yields

10.0.0.02
TP (300, 101325)
0  25077.25595308066 998.0
TQ (300, 1.0)
0  25077.25595308066 1.0
TP (300, 101325)
0  185199.55871165043 998.0
TQ (300, 1.0)
0  18808.960326156648 1.0
TP (300, 101325)
0  27932.724509367432 998.0
TQ (300, 1.0)
0  26572.140856894133 1.0

[EricLemmon]

This is an awkward one. About four years ago I came into your room at NIST with bewilderment on my face. I had just discovered that Hvap was being interpreted by the code as the vapor enthalpy, not the heat of vaporization. The expression on my face was then transferred to your face as you thought of the consequences of having done it this way. Ironically, here we are years later and both of us were tricked into thinking that hvap meant heat of vaporization. I had completely forgotten about that conversation at first and it required me to program things up before the realization of what's going on brought back the bewilderment. The reason we didn't simply change things is that the letters "liq" and "vap" can be used in conjunction with any property to indicate which phase should be returned for a saturated state. We finally decided to use HEATVAPZ, and also made it possible to calculate the heat of vaporization for a mixture by requiring the user to specify the property held constant in the change from liquid to vapor (or vice-versa). The nomenclature is given in the manual as something like this:

HEATVAPZ   Heat of vaporization (for pure fluids)         [J/mol]   [kJ/kg]
HEATVAPZ_T ...at constant temperature (for mixtures)      [J/mol]   [kJ/kg]
HEATVAPZ_P ...at constant pressure (for mixtures)         [J/mol]   [kJ/kg]

I still do not really like this solution, but even years later I don't know of a better way to do this. Simply reverting back to hvap is not an option or we risk breaking all sorts of code out there in use by others.

[ianhbell]

I forgot about that behavior. That's now obvious when you write it...

Even so, for a "HVAP" output (the saturated vapor enthalpy), it is allowed for a homogeneous state, which contradicts the documentation:

[EricLemmon]

I wonder if we should just state that this returns vapor state properties (and the same with "LIQ"). I see no reason that requires it to be saturated. What do you think?

[ianhbell]

I think we should require it be saturated. Otherwise if you specify a set of T,P inputs and HVAP, it is not clear whether you mean at the saturation temperature or at the saturation pressure.

[EricLemmon]

Actually I meant that the property returned would be at the specified inputs, not at saturation unless the inputs specify saturation. Thus T,P inputs would return the enthalpy in the vapor phase at that pressure and temperature. If the vapor phase state does not exist, an error would be returned.

I'm still not sure if this is a good or bad idea, it's just a possibility that we could implement if desired.

[ianhbell]

Let's stick with the documentation. *LIQ and *VAP are only valid inputs if the state is two-phase. Otherwise there is confusion about the distinction between H and HVAP