Seems like Clapeyron.fugacity_coefficient needs to be registered instead. I’m gonna take a look at it and release a new version of Clapeyron tomorrow
1 Like
I have another question that I haven’t found a good solution for: if my problem has 2 degrees of freedom and I have “n+2” variables and “n” equations, how should I switch the model when I’m modeling in MTK? In Pyomo, I can use “unfix/fix” to switch the state of the variables or I can explicitly ASSIGN certain variables in other modeling tools.
Are you referring to any kind of degree of freedom or thermodynamic variables?
As far as I know, by setting state_priority for a high value in the meta data of a variable, you can force a it to be a state instead of an observable.
I should be referring to the degrees of freedom at the model level. For example, in the PTflash calculation, P, T, and vapor fraction are the three variables; P and T are fixed. By then, the P vapor fraction in PV flash is fixed; when I create problems with gPROMS or Pyomo, I usually set the three of them as variables and use ASSIGN or FIX to fix those fixed variables.
I see. I used gproms for a couple of years and IIRC, you can use ASSIGN to fix the value of a variable like in a procedural programming environment, e.g., P = 10, for example. Then, P is like a parameter and kept at this value for the whole simulation unless an event modify it with REASSIGN.
This is a bit confusing in gproms since P, in this example, could also be a parameter and everything would work in the same way.
I am not sure how gproms handle the ASSIGN keyword in terms of codegen, but in modelingtoolkit P ~ 10 does not define a procedure (it doesn’t assign the number 10 to P), it defines an equation that later is either solved or kept as an observable.
I don’t know how to mimic the ASSIGN behavior of gproms in modelingtoolkit.
1 Like