Clarification/issue in SoftSAFT implementation

[ianhbell]

I can't figure out whether I am not understanding things or whether there is a typo in the implementation in Clapeyron.jl, but in the Soft-SAFT model, the implementation has:

https://github.com/ClapeyronThermo/Clapeyron.jl/blob/0a2ea2162603c83a8726f70150d49e6eded4c9cf/src/models/SAFT/softSAFT/softSAFT.jl#L165C1-L169C4

while the paper from Johnson has

and at contact, $r=\sigma$ and thus $\phi{LJ}=0$ so $y{LJ}=g_{LJ}$. Or?

The implementation in Clapeyron.jl assumes that the potential would have a value of $-\epsilon$ to get the result in Clapeyron.jl which doesn't make sense to me.

[pw0908]

Huh, good catch. Not quite sure what happened there. Logically, this won't affect phase equilibrium calculations since it just adds a constant in both phases; perhaps that's why we never noticed the issue.

I remember spending a week trying to figure out the soft-SAFT implementation and desperately trying whatever seemed reasonable at the time.

[ianhbell]

Ok, seems like a typo then.

Related: the chain term seems to be evaluated by different methods in the literature, and they don't seem consistent. For instance in Blas, what is referenced in the docs:

where one should use the value of $\sigma$ for each component $i$ to evaluate the $g{LJ}$ with the corresponding $\rho{S}^*$ if I understand correctly, the energy being the same for all components (or should all $T^*$, $\rho^*$ going into $g_{LJ}$ be for the component rather than the mixture)?

[ianhbell]

One of the soft-SAFT people will be at the Boulder conference next week so perhaps we can get some clarity

[pw0908]

Oh yes, there are a few versions of soft-SAFT. In Clapeyron, we have two (see softSAFT2016). The primarily differ by what reference EoS they use.

[ianhbell]

Yes, but the chain approach should be the same always, no?

[pw0908]

Do you mean the expression should be the same (i.e. use the Johnson correlation) or the use of WTPT1? If its the latter then yes, that's a hard requirement for all SAFTs. However, I do believe different correlations exist for the PDF of an LJ.

[ianhbell]

I mean whether what arguments go into $g{LJ}$. It takes a $T^*$ and a $\rho^*$ as arguments. If they are always the same, things are clear enough (I think) as the $\ln(g{LJ})$ factors out of the summation and you are left with:

alpha_chain = (1-m)*ln(g_LJ)

[longemen3000]

Yes, the chain approach is the same, softSAFT2016only changes the reference model to the thol one

[ianhbell]

You sort of already have this in your model hierarchy, but I am working on a generic SAFT model in teqp at the moment that allows you to specify the nonpolar contribution, the polar contribution (not yet implemented) and the association contribution independently so you can plug-and-play with models and don't have to name each individual model combination uniquely. The model permutations result in a lot of names as I know you realize.

[pw0908]

I see what you mean now. I think I got those mixing rules from one of the papers... Your idea of being able to swap out the different terms sounds very powerful! For the association term, Im guessing it will just be the association strength that changes?

[ianhbell]

I think that is correct about association.

But it is implemented very generically in the code - you just provide T, rho, mole_fraction to each contribution, and JSON is used to select models at construction-time, to instantiate type-generic std::variants. I think all of that should be possible in Julia too. Probably even easier I expect. I can show you my code once I push it.

[longemen3000]

i just saw the code, impressive. i was thinking on doing something like that, some thoughts:

• maybe adding a way to change the diameters? at first glance, some options come to mind, like the CK diameter (the one used on PCSAFT, and sPCSAFT), and the Mie one. there is also a modified expression used by the Critical point based PCSAFT (CPPCSAFT). A default option used for other other earlier eos is just using the current sigma values as diameter.
• you can just reuse some mie functions if you set λr = 12, λa = 6, like the mie diameter on PCSAFT.
• adding a translation would be useful, I-PCSAFT seems to use it
• on some PCSAFT versions, a temperature-dependent sigma is used, and as far as i know there are two versions of this temperature dependence. an optional field supporting this would be great.

[ianhbell]

I have added more to the generic SAFT approach, it is quite nice. You can pass any flags you want to each portion via the JSON data structure that the portion consumes. I have been doing model parameterization with this new approach and it is working well. Adding all the things you mention would be possible, if the underlying sub-model supports it. This overall structure makes adding model variants very easy. The compilation time is a killer though with all the different options.

I have explicitly not considered volume translation for two reasons: 1) it impacts properties in subtle ways that are not trivial and not always consistent (see the papers from the group of Jaubert) 2) it requires major changes to the library to account for which densities (volumes) are shifted and which are not. I figure it makes sense to force the user to engage their brain as a post-processing step so that they think about the consequences of volume translation.