oemof
Sign of the vapor content property
This seems to be a bit confusing, right now it is 0 for all liquid state below critical pressure/temperature and 1 for all gas states below critical pressure/temperature. It could be differenciating a bit better, i.e. considering only pressure in gas phase and not temperature.
x=0.0 if liquid at subcritical temperature
x=... in two-phase region
x=1.0 if vapor at subcritical pressure (but can be supercritical temeprature)
x=-1.0 for supercritical pressure if temperature is also supercritical
Discussed in https://github.com/oemof/tespy/discussions/695
Originally posted by HaSchneider July 2, 2025 When is the vapor content 1.0 and when is it -1.0?
When I execute the following snippet, superheated steam seems to be 1.0 but for high superheating it swithes to -1.0.
from tespy.components import Sink, Source
from tespy.connections import Connection
from tespy.networks import Network
for _h in list(range(100,4000,200)):
nw = Network()
nw.set_attr(p_unit='bar', T_unit='C', h_unit='kJ / kg', iterinfo=False)
so = Source('source 1')
si = Sink('sink 1')
con = Connection(so, 'out1', si, 'in1')
nw.add_conns(con)
con.set_attr(fluid={'H2O': 1}, m=10, h=_h, p=5)
nw.solve('design')
print(_h, con.x.val)
This will print:
100 0.0
300 0.0
500 0.0
700 0.028422293594301193
900 0.12329788000828545
1100 0.21817346642226973
1300 0.31304905283625406
1500 0.40792463925023836
1700 0.5028002256642226
1900 0.5976758120782069
2100 0.692551398492191
2300 0.7874269849061754
2500 0.8823025713201598
2700 0.9771781577341441
2900 1.0
3100 1.0
3300 -1.0
3500 -1.0
3700 -1.0
3900 -1.0
````</div>
@fwitte perhaps you have seen it already, but the issue is a result of an incomplete mapping in the CoolPropWrapperd Q_ph method between the CoolProp phases and the corresponding quality calculation. Specifically, cp.iphase_supercritical_gas (I.e gas a sub-critical pressure but supercritical temperature)
However, there is a fundamental inconsistency with regards to how the quality is reported by different packages... CoolProp only reports a meaningful value in the two-phase region, whereas IAPWS also reports 0 and 1 outside the two-phase region.
I used to be in the camp of IAPWS because it is more satisfying to not see -1 being reported when the fluid was single phase, but I think Im now in camp CoolProp... clamping the values to "0" and "1" may result in accidentally initialising to saturated conditions when the fluid is actually two-phase.
The above being said, I think the quality is sometimes "misused" and used to determine the state of the fluid...
In my opinion, the phase_ph method would be a better alternative (although in its current implementation it is also missing some CoolProp phases...)
Hi @tlmerbecks and thank you for your elaborations on this!
clamping the values to "0" and "1" may result in accidentally initialising to saturated conditions when the fluid is actually two-phase.
In context of tespy, the x value is only used for initialization if the user specified that. If it is just sitting there as a result it is not considered in initialization. Of course, in case you do follow-up calculations that might be a problem.
In my opinion, the phase_ph method would be a better alternative (although in its current implementation it is also missing some CoolProp phases...)
Right now there is this kind of "convergence helper", which is called state in tespy. It forces the phase of the fluid into subcritical pressure and to the liquid or the vapor phase. Replacing this with phase as a user input and forcing the fluid to be in that phases for at least the first couple iterations (i.e. including two-phase, liquid at supercritical pressure and supercritical overall (p and T) phases next to the subcritical pressure liquid and vapor phases) would be helpful. And I think it can also be implemented quite straight forward.
Then only remains the result reporting of x. I would think, that everything with subcritical pressure could be mapped to 0...1 and supercritical pressure gets np.nan to keep things easy.