Generalize API for Thermo Module

[TJP-Karpowski]

Hi,

I noticed , that the thermo interface has different function interfaces for H/S and cp/cv. The first return a vector of mole and a second function for mass, while the second return both in the same function call. I would propose to make the behaviour uniform. So each quantity gets a function

1. get_h -> mole based vector
2. get_hmass -> mass based vector
3. get_h_mean -> mole based mixture average
4. get_hmass_mean -> mass based mixture average
   I could implement that if you are okay with that.
   Furthermore in the long term I would like to simulate real gas behavior. To do that a different Thermo module would be needed. To do that, one could adapt the thermo functions to take an thermo class as input: get_S(thermo::IdealGasThermo , temperature, pressure, X0) and pass the function forward to thermo if a Solution is given:
   get_S(gas::Solution, T,p,X) = get_S(gas.thermo,T,p,X)
   That way one could easily extend Arrhenius with more Thermomodels as long as it supplies the required function.

[jiweiqi]

Hi @TJP-Karpowski , I think those are indeed valid suggestions.

The reason that I used different interfaces in Thermo.jl was mainly due to that mass-based properties can usually be derived from mole-based ones. But indeed, they are a little bit messy. It will be great to make them more consistent.

Meanwhile, I would suggest keeping backward compatibility when changing the function names and interface. I would suggest making a new set of functions, like cal_h, cal_hmass etc. (Basically, use a new prefix of cal_ to keep get_ unchanged. I have written a log of applications codes with the existing functions 🔢

For the real gas behavior, I guess there are multiple ways to do it with Julia's multi-dispatch. As you have proposed, we can create a new class/struct of Thermo::RealGasThermo and creating a RealGasThermo when creating a gas Solution. Or alternatively, one can simply dispatch the function get_S in the application code as well.

[TJP-Karpowski]

Okay that sounds good. I will try to add the cal interface in the next days.

[jiweiqi]

Hi

I am wondering do you want to have a brief zoom meeting to say hello to each other and discuss each other's interest in Arrhenius so that we can better collaborate on the development in the future.

You can drop me a email to set the meeting weiqiji@mit.edu

Weiqi

[TJP-Karpowski]

Hi @jiweiqi ,

I would like to change the implementation to enable the usage of other thermo models in the future. One way would be to implement the functions with the thermo interface as input:
function cal_a_RT(thermo::IdealGasThermo, T,p,X) ...
and use metaprograming to add
function cal_a_RT(gas::Solution, T,p,X) cal_a_RT(gas.thermo, T,p,X) end
This would enable the extension of Arrhenius with arbitrary Thermo models in the future. Do you have other ideas how this could be achieved? Since I am just starting programming in Julia I might have overlook some other possibilities.

[jiweiqi]

Aha, I am also relatively new to Julia. I thought you are an experience Julia user, as your code looks nice to me.

I think multi-dispatch might be a nice solution here ( I am not sure if it is called multi-dispatch). It will be something like

function cal_a_RT(gas::Solution, thermo::IdealGasThermo, T,p,X) and function cal_a_RT(gas::Solution, thermo::ReakGasThermo, T,p,X), the compiler will decide the right function according to the types of input arguments. BTW, we can use meta-programing to make the input argument consistent as well.

To accompany the changes, we only have to define a new Struct or a new DataType to distinct two Thermo class, something like
Thermo::IdealGasThermo and Thermo::RealGasThermo in https://github.com/DENG-MIT/Arrhenius.jl/blob/main/src/DataStructure.jl.

I haven't looked into how to define abstract types, which might make the type definition cleaner.

In summary, this could be done with multi dispatch.

[TJP-Karpowski]

Thanks for the praise, I took inspiration from https://github.com/longemen3000/ThermoState.jl to derive the metaprogramming for function definition. I will read-up on multi-dispatch and work out a prototype.