Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification/issue in SoftSAFT implementation #279

Open
ianhbell opened this issue Jun 20, 2024 · 13 comments
Open

Clarification/issue in SoftSAFT implementation #279

ianhbell opened this issue Jun 20, 2024 · 13 comments

Comments

@ianhbell
Copy link
Contributor

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

image

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
Copy link
Member

pw0908 commented Jun 20, 2024

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
Copy link
Contributor Author

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:

image

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
Copy link
Contributor Author

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

@pw0908
Copy link
Member

pw0908 commented Jun 20, 2024

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
Copy link
Contributor Author

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

@pw0908
Copy link
Member

pw0908 commented Jun 20, 2024

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
Copy link
Contributor Author

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
Copy link
Member

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

@ianhbell
Copy link
Contributor Author

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
Copy link
Member

pw0908 commented Jun 20, 2024

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

ianhbell commented Aug 7, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants