Import critical properties for thermo and transport calculation

[Yuji-1]

Abstract

Enable the import method in transport model to import critical properties so that high pressure transport model will no longer rely on certain real-gas EoS and allow users to use high pressure transport model under ideal-gas EoS (for example, in 1D premixed flame simulation)

Motivation

In current implementation of high pressure transport model, the critical properties of all species are calculated through certain real-gas EoS. However, it will be more appropriate if critical properties (critical pressure, critical temperature, critical volume and critical compressibility factor) used in high-pressure transport model do not rely on certain real-gas EoS, when users try to combine ideal-gas EoS with high pressure transport model.

Possible Solutions

In my opinion, the possible solution is:

1. Directly modify transport model module to include and import these critical properties. If they are not provided, warn the user (Missing critical properties for species xx, high pressure transport model may not be available). The corresponding import format may be like (in yaml files):

- name: C2H4
  composition: {C: 2, H: 4}
  thermo:
    model: NASA7
    temperature-ranges: [200.0, 1000.0, 3500.0]
    data:
    - [3.95920148, -7.57052247e-03, 5.70990292e-05, -6.91588753e-08, 2.69884373e-11,
      5089.77593, 4.09733096]
    - [2.03611116, 0.0146454151, -6.71077915e-06, 1.47222923e-09, -1.25706061e-13,
      4939.88614, 10.3053693]
  equation-of-state:
    model: Redlich-Kwong
    a: [7.829395e+12,0]
    b: 4.021577e+01
    note: L1/91
  transport:
    model: gas
    geometry: nonlinear
    well-depth: 280.8
    diameter: 3.971
    rotational-relaxation: 1.5
    crit_pres: xxx
    crit_temp: xxx
    crit_vol: xxx
    crit_comp: xxx

2, As for the modifications in high pressure transport model, it will reserve 4 arrays to store critical properties respectively, as the style of equation parameters in R-K EoS module (a_vec_Curr_). The access to critical properties will be changed from calculations through real-gas EoS (double tc = m_thermo->critTemperature()) to user-provided data (double tc=m_crit_temp[i]), thus eliminating the dependance on certain EoS and enhancing the flexibility of Cantera.

References
[1] (https://github.com/Cantera/cantera/blob/main/src/transport/HighPressureGasTransport.cpp)

[decaluwe]

Thanks, @Yuji-1 !

1. The first thought that comes to mind is that we likely do not want these loaded under the transport field. Even though you are using them for transport calculations, in this case, they are probably more accurately thought of as thermo parameters (although the same could likely be said about Lennard-Jones parameters). I don't necessarily need to stuff more into the thermo field, though; what would people think of creating a separate critical-properties list?

2. The second thought that comes to mind is how this impacts the EoS (Redlich Kwong and the proposed Peng-Robinson). In terms of the equation-of-state field, it provides another means of providing equivalent information. I suppose there is a pecking order, here: (i) look for user-provided a and b; (ii) look for user-provided critical-properties; (iii) look through the critproperties database.

3. We would also need something in place in HighPressureGasTransport to overwrite the Tcrit_i, Pcrit_i, etc. calculations, if the species critical properties are already stored. One thought would be that we eliminate these routines entirely, and use a routine during setup of the thermo class to covert the equation-of-state parameters to species critical properties (if those critical properties have not been provided by the user).

[Yuji-1]

1. I think creating separate field "critical-properties" will be better for both thermo and transport use. Equation parameters can be derived from critical properties (for P-R EoS, acentric factor is also necessary), and high pressure transport model will be accessible with the provision of critical properties. But I'm not sure how to implement it.
2. As for impacts on EoS, now that we've assigned critical-properties as an additional (or optional) field, the priority about the determination of equation parameters would be user-provided EoS parameters > user-provided critical properties > critical properties database. Relevant modifications on R-K and P-R class can be dealt afterwards.
3. The conversion from EoS parameters to critical properties should be less prior than user-provided critical properties, if you want to combine ideal-gas EoS with non-ideal transport model. Actually, with what has been done in 1, EoS parameters and non ideal transport model will be available given user-provided critical properties.
4. I guess if critical properties are stored, the initialization of HighPressureGasTransport can be done like initThermo in R-K and P-R EoS class, where the critical properties are reserved in arrays vector_fp m_crit_pres. Tcrit_i and Pcrit_i can be replaced with m_crit_temp[i] and m_crit_pres[i].
5. In other non-ideal transport model (Chung's model for viscosity, for example), acentric factor is also needed. I notice that acentric_factor is an optional parameter in GasTransportData, so I am wondering if someone wants to implement non-ideal transport model related to acentric factor, can it be directly used once you provide?

[speth]

We had previously discussed adding a field for critical property information in #20, with the consensus tending toward something like:

- name: C2H4
  composition: {C: 2, H: 4}
  thermo:
    ...
  equation-of-state:
    ...
  transport:
    ...
  critical-properties: # or maybe "critical-parameters"
    critical-pressure: ...
    critical-temperature: ...
    critical-volume: ...
    acentric-factor: ...

This same structure would also be used for the YAML replacement for critProperties.xml.

[decaluwe]

I think I like critical-parameters, if only for the inclusion of acentric-factor.

So does inclusion of acentric-factor here replace its inclusion in the transport field? Or do we simply accept that it may be included twice, for the time being?

[Yuji-1]

Besides, saturated vapor pressure is also needed in HighPressureGasTransport (or ThermoPhase::satPressure). It can estimated through Antoine equation or other methods, the input format is probably like:

  name-of-field:
    Antoine-coefficient: [xx, xx, xx]

I'm not sure it should be included in this field or a separate field.

[decaluwe]

I can see the value of providing species critical properties, regardless of EoS. To be frank, I am less convinced that there is a need to add other properties (which would require new Cantera functionality on the back end) into the species definition, all for this single use case. For this case, you would then need to add a saturation pressure routine to calculate P_sat as a function of T, in the IdealGas class. The entire idea of a saturation pressure for an ideal gas phase is a bit contradictory--if P_sat ever becomes relevant during a simulation, you are by definition no longer dealing with an ideal gas.

Speaking only for myself, doing this in service of a single use case is not terribly compelling. You are trying to combine non-ideal transport parameters with an ideal gas equation of state. The former assumes that there are inter-species interactions, while the latter precludes them - it is an inconsistent set of assumptions, all to get around the fact that the non-ideal flame equations are a bit complex (and not implemented in Cantera).

You are, of course, welcome to add such a routine to your own forked version of Cantera., which would let you carry out your planned analysis. If you do so, I would certainly be happy for you to submit a pull request so that we can consider it further.

I would just caution you to first run your simulations using ideal gas conditions and look at the compressibility of your mixture (Pv/RT) over the course of the simulation. @gkogekar and I have spent a good amount of time playing around with non-ideal effects, and have rarely found situations where they seem to matter much (to our dismay). Especially in combustion, where the high temperatures usually mean that the compressibility is very close to 1, and the results usually do not deviate by more than a few percent from ideal gas results.

That is not mean to dissuade you--my word here is by means authoritative--but just to advise a little investigation beforehand so that you don't go and do a bunch of work only to find afterward that it was not necessary.

[Yuji-1]

As you mentioned, the implementation of non-ideal flame equations is more complex and cannot be completed for the time being. However, for many high-pressure transport models, the residual properties (viscosity and thermal conductivity) are strongly related to density. In other words, non-ideal effects are reflected through density indirectly (not in a direct way of reduced pressure). Under ideal-gas assumption, large deviations of density are predicted under high-pressure occasions. So the high-pressure transport model is not accurate, unless RealGasFlow is finished and combined with these methods, I will follow your advice and evaluate the non-ideality of gas mixtures in my simulations, thanks for your advice.

[ischoegl]

This is implemented by Cantera/cantera#1141