Modifying the structure of Activity models

[pw0908]

Currently, activity coefficient models must be constructed with a model for the pure components to ensure one can model the vapour phase. This can sometimes be a bit troublesome as not every species has the parameters within this additional model and, with the structure of Clapeyron, it can sometimes be difficult to define these parameters manually. The work around so far has been to assume the vapour phase can be modelled using an ideal model. Unfortunately, a lot of operations in Clapeyron for activity coefficient models assume we have a saturation pressure for the activity model, which wont be the case if we use the ideal model.

One potential solution would be to treat activity coefficient models as just that, and not include any additional models for the vapour phase. If one wishes to use Activity models for VLE calculations, they can use the CompositeModel architecture:

model = CompositeModel(components;liquid=UNIFAC, gas=PR, saturation=PR)

Most of the Clapeyron architecture already knows how to handle composite models built like this. The only limitation we've identified is that activity coefficient models don't have an easy way to estimate general bulk properties (such as the volume).

[longemen3000]

Some things I've thinking about this:

• a standalone Activity model should suppose ideal gas. In they way, the current solvers will keep working as is.
• for real gas+activity, we need a constructor that accepts an activity and a real fluid:

#example, name subject to change
GammaPhi(act_model::ActivityModel;fluid = PR)

• For CompositeModel itself, I think we need to simplify some things. In hindsight, it has too many fields and new use cases (VRmie for solids), end up really cumbersome. I propose the following:

struct CompositeModel{F, S} 
  components::Vector{String}
  fluid::F
  solid::S
end

The fluid field contains fluid phase EoS. this field has three options:

1. fluid::EoSModel: one EoS is in charge of providing gas, liquid and saturation properties, really easy to handle,as it is the default on all EoS.
2. Activities: we store a struct containing the activities and the bulk phase fluid, defaulting to BasicIdeal.
3. Liquid-Sat-gas: another struct wrapping those three fields. This is was the original reason of the CompositeModel struct, wrapping those three properties into a subbstruct allows for easier handling.

The solid field has the solid phase EoS. I see two types that would use that field:

1. solid::EoSmodel. The EoS provides solid volumes and potential energies for equilibria (VRSMie and Solid softSAFT would use this. There are also reference equations of state of solids for some compounds, like benzene)
2. solid-melting-sublimation:same deal as the liquid-sat-gas case, wrapper struct over those three models. We dont have correlations for those yet, but they would be useful to add.

I have to check where Hfus enters, but it belongs on the solid field.

with that whole revamp in mind, I think we can perform the change on stages:

• Clapeyron 0.5: we support the new struct, while allowing the nested puremodel. And using that as the default. Fast would allow us to test the changes without needing to change every Activity model. We implicitly transform activity models into the new struct, unifying their treatment.
• Clapeyron 0.6: we remove the puremodel field from all activity models and make the default BasicIdeal.