Here is a list of common issues I've encountered with bubble_pressure and am still trying to find ways to fix:

• DomainError when the packing fraction goes above 1.
• The solution results in Vapour=Liquid below the critical point of the mixture.
• Vapour fractions add up to more than one due to high liquid phase compositions
• Negative vapour fractions due to low liquid phase compositions.

Any suggestions on how to address any of these problems are more than welcome!

Cool new activity coefficient model which uses NRTL in combination with association fluid theories: https://aiche.onlinelibrary.wiley.com/doi/abs/10.1002/aic.17061

this is an issue recollecting all the breaking changes that will be done on Clapeyron 0.4.0

As a basic correctness check, I queried the speed of sound and isentropic exponent of nitrogen at STP using Peng-Robinson and PC-SAFT models.

julia> using Clapeyron, Unitful

julia> N2_PR = PR(["nitrogen"])
PR{BasicIdeal} with 1 component:
 "nitrogen"
Contains parameters: a, b, acentricfactor, Tc, Pc, Mw

julia> N2_SAFT = PCSAFT(["nitrogen"])
PCSAFT{BasicIdeal} with 1 component:
 "nitrogen"
Contains parameters: Mw, segment, sigma, epsilon, epsilon_assoc, bondvol

julia> speed_of_sound(N2_PR, 101325u"Pa", 300u"K")
8669.296616665222 m s^-1

julia> speed_of_sound(N2_SAFT, 101325u"Pa", 300u"K")
10468.079131748613 m s^-1

julia> isobaric_heat_capacity(N2_PR, 101325u"Pa", 300u"K") / isochoric_heat_capacity(N2_PR, 101325u"Pa", 300u"K")
874.8616410752167

julia> isobaric_heat_capacity(N2_SAFT, 101325u"Pa", 300u"K") / isochoric_heat_capacity(N2_SAFT, 101325u"Pa", 300u"K")
1275.2917204657658

Needless to say, these values are a bit off the mark (a = 352 m/s and γ=1.4). The test suite has some property tests, but relative tolerances are set to 1E10. If this functionality is not yet implemented (/validated), I would recommend changing that test block to @test_skip and clarifying the current state of property methods in the documentation.

First things first - thank you so much for your wonderful work on this package! I am currently doing research on transport phenomena in high pressure ternary mixtures of CO2/water/cosolvent[methanol/acetonitrile/etc.] and the existence of a simple to use group contribution SAFT implementation in Julia, for prediction of fugacity coefficients, and hopefully for analysis of LLE, is a godsend. I have some interest/background/time to work on multicomponent flash calculations; if there are any algorithms which you are looking to implement, I'd be open to lending a hand.

I also have a brief technical question. I have been playing around with Clapeyron, and I have noticed a potential issue with bubble_pressure calculations when using SAFTgammaMie.

The following code for calculating the bubble pressure works well using PCSAFT:

system = PCSAFT(["methanol","water"])
p = 1e5
T = 383.15
T2 = 443.15
z = [0.5,0.5]
z_LLE = [0.27,0.73]

Clapeyron.bubble_pressure(system,T,z)

It also works well with SAFTVRMie. However, with SAFTgammaMie:

system = SAFTgammaMie(["methanol","water"])
p = 1e5
T = 383.15
T2 = 443.15
z = [0.5,0.5]
z_LLE = [0.27,0.73]

Clapeyron.bubble_pressure(system,T,z)

I get an error:

DimensionMismatch("first array has length 2 which does not match the length of the second, 1.")

I believe this may be traced back to lines 12 and 13 of bubble_pressure.jl, which require splitting the mixture model into pure models:

pure = split_model(model)
crit = crit_pure.(pure)

I noticed that split_model appears to split SAFTgammaMie mixtures into some kind of composite object with type:

SAFTgammaMie{BasicIdeal, SAFTVRMie{BasicIdeal}}

whereas if you use split_model on, say, SAFTVRMie, you get objects of a simpler type:

SAFTVRMie{BasicIdeal}

Do you know if this is a bug in either split_model or in the SAFTgammaMie implementation? It would be useful to do bubble_pressure calculations using SAFTgammaMie.

In the docs, it would be helpful to define what you mean by residual (for s_residual and mu_residual). There are many contradictory definitions in the literature and this is a common source of confusion.

Looks like this might the future of perturbation theories and might be a good idea for us to include them in Clapeyron:

1. uf-theory: https://doi.org/10.1063/5.0031545
2. uv-theory: https://doi.org/10.1063/5.0073572

In https://github.com/ypaul21/Clapeyron.jl/blob/master/src/methods/VT.jl#L19-L23

function VT_internal_energy(model::EoSModel, V, T, z=SA[1.])
    dA, A = ∂f(model,V,T,z)
    ∂A∂V, ∂A∂T = dA
    return A - T*∂A∂V
end

But the internal energy should be U = A - T*∂A∂T ?

Here is a list of common issues I've encountered with sat_pure and am still trying to find ways to fix:

• DomainError when the packing fraction goes above 1.
• The solution results in Vapour = Liquid below the critical point.

Any suggestions on ways to deal with these problems are more than welcome!

@TheFranCouz this is an issue to track progress on a possible implementation of https://pubs.acs.org/doi/10.1021/acs.jced.6b00565 . feel free to comment

it would be useful to have the translated and consistent PR and RK cubics. there is also a version with advanced mixing rules and their own set of parameters for van laar, UNIQUAC, NRTL and Wilson
https://pubs.acs.org/doi/10.1021/acs.iecr.1c03003

I am going to be playing with some SAFT variants, particularly group contribution methods for rather large molecules > 500 MW.

It would be real swell if there was a parser, so that given a SMILES i.d. or equivalent, all of the groups (and their amounts) were returned. rdkit can probably do this. I will likely look into this, but I have a feeling it will take a bit of work. I have not had to deal with using python from Julia, and don't look forward to it.

This would be a fantastic feature though. Drug molecules are such a pain.

This also reminds me that I thought there used to be an example for a (small) drug molecule for the GammaMie variant?

Possibly this is an issue with StaticArrays rather than you, it certainly doesn't seem to be on your end

To reproduce:

julia> using Clapeyron
[ Info: Precompiling Clapeyron [7c7805af-46cc-48c9-995b-ed0ed2dc909a]

julia> model = VTPR(["carbon dioxide"])
PR{BasicIdeal, TwuAlpha, RackettTranslation, VTPRRule{VTPRUNIFAC{PR{BasicIdeal, PRAlpha, NoTranslation, vdW1fRule}}}} with 1 component:
 "carbon dioxide"
Contains parameters: a, b, Tc, Pc, Mw

julia> p = 1e5
100000.0

julia> T = 273.15
273.15

julia> volume(model, p, T)
0.022547066007297695

julia> fugacity_coefficient(model, p, T)
ERROR: setindex!(::StaticArraysCore.SVector{1, Float64}, value, ::Int) is not defined.
Stacktrace:
 [1] error(s::String)
   @ Base ./error.jl:33
 [2] setindex!(a::StaticArraysCore.SVector{1, Float64}, value::Float64, i::Int64)
   @ StaticArrays ~/.julia/packages/StaticArrays/dcWsT/src/indexing.jl:3
 [3] fugacity_coefficient(model::PR{BasicIdeal, TwuAlpha, RackettTranslation, VTPRRule{VTPRUNIFAC{PR{BasicIdeal, PRAlpha, NoTranslation, vdW1fRule}}}}, p::Float64, T::Float64, z::StaticArraysCore.SVector{1, Float64}; phase::Symbol, threaded::Bool)
   @ Clapeyron ~/.julia/packages/Clapeyron/NEYMK/src/methods/pT.jl:334
 [4] fugacity_coefficient (repeats 2 times)
   @ ~/.julia/packages/Clapeyron/NEYMK/src/methods/pT.jl:329 [inlined]
 [5] top-level scope
   @ REPL[6]:1

This error occurs when assiging a value to $\varphi$ on this line:

In #fugacity_coefficient#331(phase, threaded, , model, p, T, z) at /home/luc/.julia/packages/Clapeyron/NEYMK/src/methods/pT.jl:328
 330      μ_res = VT_chemical_potential_res(model,V,T,z)
 331      φ = μ_res
 332      Z = p*V/R̄/T/sum(z)
 333      for i ∈ @comps
>334          φ[i] = exp(μ_res[i]/R̄/T)/Z
 335      end
 336      return φ
 337  end

This occurs on Clapeyron release 0.3.7

(@v1.7) pkg> status
      Status `~/.julia/environments/v1.7/Project.toml`
  [6e4b80f9] BenchmarkTools v1.3.1
  [7c7805af] Clapeyron v0.3.7

Hopefully it is reproducable for you and a simple fix

A number of example notebooks have erros and do not execute:

The notebook multi-component_vle_vlle_lle_crit has an error as follows:

MethodError: no method matching ChemPotBubblePressure

Also the SAFT_eos.ipynb has a domain error for the CPA equation of state.

Any help in how to fix these.

In the volume solver, should all be operating normally (under critical point, two volume roots found etc), the gibbs free energies of the phases are checked, and the phase that minimises gibbs is returned:

    if gg<gl
        isstable(model,Vg,T,z,phase)
        return Vg
    else
        isstable(model, Vl, T, z, phase)
        return Vl
    end

However, by passing the phase to the stability check isstable, the isstable function automatically returns true

function isstable(model, V, T, z, phase=:stable)
    if phase != :stable
        return true
...etc

This doesn't seem like the intended use of the stability check, is this how it's intended to be used?

Interesting cross over between the chain term in SAFT and a cubic equation of state: https://pubs.acs.org/doi/abs/10.1021/acs.iecr.2c00902

Hi, we currently use CoolProp to get molar densities for noble gases and some molecules (not mixtures). E.g. helium, argon, hydrogen, nitrogen etc. We need a reasonable span of pressure and temperature, but nothing more complicated. We are considering using Clapeyron instead of CoolProp, but it is very hard for an ignorant user like me to understand which model to use for each fluid. CoolProp (and REFPROP previously) just had a default model (or perhaps only one, I never checked). Do you have a table of which model is best for each basic fluid?

The complexity of SAFT equations of state imposes quite a lot of overhead on this package, and that’s entirely justified for a research-grade EOS, but for simple day-to-day usage, it’d be great to have a low-overhead, fast-loading EOS package covering ideal/SRK/Peng-Robinson.

I'd like to calculate parameters with the SAFT-VRQ model, but I am not sure how to instantiate this model. Can you provide an example? I thought I remembered seeing an example somewhere, but I went all through the docs and folder of examples and didn't find it.

It took me a while to realize precisely what the problem was, but if I pass an integer argument in some cases I get what I assume are iteration failures, while when I pass the same quantity as a float, no problem. I assume the values should be up-cast to double first.

model = SAFTVRQMie(["hydrogen"])
display( model.params.sigma)
display(model.params.lambda_a)
display(model.params.lambda_r)
display(model.params.epsilon)

crit = Clapeyron.crit_pure(model)
print(crit)
Tc, pc, vc = crit
T = 14
print(T)
p, vl, vv = saturation_pressure(model, T)
prop = -Clapeyron.VT_entropy_res(model, vl, T, z)/8.31446261815324

yields

...
(33.434046890891814, 1.3841855209847114e6, 6.452374327127238e-5)14
InexactError: Int64(3.453199220287775e-10)

Stacktrace:
  [1] Int64
    @ ./float.jl:788 [inlined]
  [2] convert
    @ ~/.julia/packages/ForwardDiff/QdStj/src/dual.jl:433 [inlined]
  [3] setindex!
    @ ./array.jl:966 [inlined]
  [4] d(model::SAFTVRQMie{BasicIdeal}, V::Float64, T::ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fun#184"{SAFTVRQMie{BasicIdeal}, Float64, Vector{Float64}}, Int64}, Int64, 1}, z::Vector{Float64}, _σeff::Matrix{ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fun#184"{SAFTVRQMie{BasicIdeal}, Float64, Vector{Float64}}, Int64}, Float64, 1}})
    @ Clapeyron ~/.julia/packages/Clapeyron/u0y5V/src/models/SAFT/SAFTVRMie/variants/SAFTVRQMie.jl:164
  [5] macro expansion
    @ ~/.julia/packages/Clapeyron/u0y5V/src/utils/macros.jl:77 [inlined]
  [6] data(model::SAFTVRQMie{BasicIdeal}, V::Float64, T::ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fun#184"{SAFTVRQMie{BasicIdeal}, Float64, Vector{Float64}}, Int64}, Int64, 1}, z::Vector{Float64})
    @ Clapeyron ~/.julia/packages/Clapeyron/u0y5V/src/models/SAFT/SAFTVRMie/variants/SAFTVRQMie.jl:86
  [7] a_mono
    @ ~/.julia/packages/Clapeyron/u0y5V/src/models/SAFT/SAFTVRMie/variants/SAFTVRQMie.jl:74 [inlined]
  [8] macro expansion
    @ ~/.julia/packages/Clapeyron/u0y5V/src/utils/macros.jl:77 [inlined]
  [9] a_res
    @ ~/.julia/packages/Clapeyron/u0y5V/src/models/SAFT/SAFTVRMie/variants/SAFTVRQMie.jl:79 [inlined]
 [10] eos_res(model::SAFTVRQMie{BasicIdeal}, V::Float64, T::ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fun#184"{SAFTVRQMie{BasicIdeal}, Float64, Vector{Float64}}, Int64}, Int64, 1}, z::Vector{Float64})
    @ Clapeyron ~/.julia/packages/Clapeyron/u0y5V/src/base/EoSModel.jl:75
 [11] fun
    @ ~/.julia/packages/Clapeyron/u0y5V/src/methods/VT.jl:22 [inlined]
 [12] derivative
    @ ~/.julia/packages/ForwardDiff/QdStj/src/derivative.jl:14 [inlined]
 [13] derivative
    @ ~/.julia/packages/Clapeyron/u0y5V/src/solvers/ad.jl:6 [inlined]
 [14] VT_entropy_res(model::SAFTVRQMie{BasicIdeal}, V::Float64, T::Int64, z::Vector{Float64})
    @ Clapeyron ~/.julia/packages/Clapeyron/u0y5V/src/methods/VT.jl:23
 [15] top-level scope
    @ In[71]:17
 [16] eval
    @ ./boot.jl:368 [inlined]
 [17] include_string(mapexpr::typeof(REPL.softscope), mod::Module, code::String, filename::String)
    @ Base ./loading.jl:1428

FYI: The paper about the algorithm for finding VLLE from VLE tracing is now published: https://pubs.acs.org/doi/10.1021/acs.iecr.1c04703 . Let me know if you have any questions.

The successor to SAFT-VRQ Mie and a pretty cool concept: https://www.sciencedirect.com/science/article/pii/S0378381220303381

Given we already support Twu, I believe this is just a minor change to the mixing rule?

A cool improvement on the standard Wertheim TPT1 theory:
https://doi.org/10.1103/PhysRevE.105.034110

Cool extension of SAFT gamma mie which accounts for the structure of the molecule:

• Alkanes: https://aip.scitation.org/doi/10.1063/5.0048315
• Alcohols: https://pubs.acs.org/doi/abs/10.1021/acs.iecr.2c00198

It's a bit weird that it's only comparable to regular SAFT-gamma Mie (probably an indication of the limitations of the underlying theory). But would be interesting to see if Clapeyron can handle this input type.

I'm working on a C++ library (https://github.com/usnistgov/teqp) that implements EOS similarly to Clapeyon, and I was wondering whether one or more of your lead developers of Clapeyron might have an interest in serving as an informal internal reviewer for the manuscript about the library. I looked for contact info in the docs, but was stymied. You can email me at [email protected] if you are interested. I think we are working on a lot of similar problems and I think it might be nice to have some cross-pollination.

We could consider using newer methods to solve for the association fraction:

1. https://www.tandfonline.com/doi/full/10.1080/00268976.2012.668963
2. https://pubs.acs.org/doi/10.1021/ie034041q
3. https://pubs.acs.org/doi/abs/10.1021/ie060029x
   They don't look so complex and we could add them under AssocOptions

the Coolprop JSON has a lot of additional info that we currently don't use. other than that, it would require another dependency. but seems cool to instantiate and compare implementations (and methods)

Hello folks. You went and made a beautiful package and then made it depend on unstable packages or packages not in JuliaHub :D

It is like a series of dependency errors... have you folks tried installing your package from scratch? maybe I am doing something wrong but right off the bat I am met with

ERROR: Unsatisfiable requirements detected for package LogExpFunctions [2ab3a3ac]:
 LogExpFunctions [2ab3a3ac] log:
 ├─possible versions are: 0.2.0-0.2.4 or uninstalled
 └─restricted to versions 0.3 by Clapeyron [7c7805af] — no versions left
   └─Clapeyron [7c7805af] log:
     ├─possible versions are: 0.2.0 or uninstalled
     └─Clapeyron [7c7805af] is fixed to version 0.2.0

To install this, there is another error solved by first installing the package IrrationalConstants, and then install LogExpFunctions , both from Github. LogExpFunctions can be installed from JuliaHub, but is an old version, and Clapyron depends on the latest one, and won't install without version 0.3.

To install IrrationalConstants just do

']'
followed by (don't include pkg>)
pkg> add https://github.com/JuliaMath/IrrationalConstants.jl
followed by
pkg> add https://github.com/JuliaStats/LogExpFunctions.jl

Now upon retrying pkg> add https://github.com/ypaul21/Clapeyron.jl

I am met with the complaint

ERROR: Unsatisfiable requirements detected for package JuliaFormatter [98e50ef6]:
 JuliaFormatter [98e50ef6] log:
 ├─possible versions are: [0.1.0-0.1.5, 0.1.8-0.1.44, 0.2.0-0.2.4, 0.3.0-0.3.9, 0.4.0-0.4.3, 0.5.0-0.5.5, 0.6.0-0.6.9, 0.7.0-0.7.6, 0.8.0-0.8.2, 0.9.0-0.9.9, 0.10.0-0.10.9, 0.11.0, 0.12.0-0.12.3, 0.13.0-0.13.10, 0.14.0-0.14.7] or uninstalled
 ├─restricted by compatibility requirements with DataStructures [864edb3b] to versions: [0.1.0-0.1.5, 0.1.8-0.1.44, 0.2.0-0.2.4, 0.3.0-0.3.7, 0.7.2-0.7.6, 0.8.0-0.8.2, 0.9.0-0.9.9, 0.10.0-0.10.9, 0.11.0, 0.12.0-0.12.3, 0.13.0-0.13.10, 0.14.0-0.14.7] or uninstalled
 │ └─DataStructures [864edb3b] log:
 │   ├─possible versions are: [0.9.0, 0.10.0, 0.11.0-0.11.1, 0.12.0, 0.13.0, 0.14.0-0.14.1, 0.15.0, 0.16.1, 0.17.0-0.17.20, 0.18.0-0.18.9] or uninstalled
 │   └─restricted to versions 0.18 by Clapeyron [7c7805af], leaving only versions 0.18.0-0.18.9
 │     └─Clapeyron [7c7805af] log:
 │       ├─possible versions are: 0.2.0 or uninstalled
 │       └─Clapeyron [7c7805af] is fixed to version 0.2.0
 └─restricted by compatibility requirements with Atom [c52e3926] to versions: [0.4.3, 0.5.0-0.5.5] — no versions left
   └─Atom [c52e3926] log:
     ├─possible versions are: [0.8.0-0.8.8, 0.9.0-0.9.1, 0.10.0-0.10.2, 0.11.0-0.11.3, 0.12.0-0.12.32] or uninstalled
     └─restricted to versions 0.12.11 by an explicit requirement, leaving only versions 0.12.11

When trying to install JuliaFormatter I get ther error that it depends on CSTParser
So I must first install CSTParser and then JuliaFormatter

You cannot use the following
import Pkg; Pkg.add("CSTParser")
because that would be too easy, it installs the wrong version...

When I try
'pkg> add https://github.com/julia-vscode/CSTParser.jl' doesn't work either

ERROR: Unsatisfiable requirements detected for package CSTParser [00ebfdb7]:
 CSTParser [00ebfdb7] log:
 ├─possible versions are: 3.2.4 or uninstalled
 ├─CSTParser [00ebfdb7] is fixed to version 3.2.4-DEV
 └─found to have no compatible versions left with Atom [c52e3926] 
   └─Atom [c52e3926] log:
     ├─possible versions are: [0.8.0-0.8.8, 0.9.0-0.9.1, 0.10.0-0.10.2, 0.11.0-0.11.3, 0.12.0-0.12.32] or uninstalled
     └─restricted to versions 0.12.11 by an explicit requirement, leaving only versions 0.12.11

At this point, I am worn out. Maybe I have somehow done something terribly wrong, but is it necessary to have a package depend on so many unstable packages?

Or maybe there is somekind of setup script that auto installs the necessary dependencies?

Your Clapeyron.cite is a great idea that I will implement in teqp too. It would be nice to have the ability to dump a BibTeX file given the list of DOI. In Python, that looks something like:

def doi2bib(doi):
        """
        Return a bibTeX string of metadata for a given DOI. See https://gist.github.com/jrsmith3/5513926
        """
        headers = {"accept": "application/x-bibtex"}
        r = requests.get("http://dx.doi.org/" + doi, headers = headers)
        if r.ok:
            key = re.search(r'{(\S+),', r.text)
            return key.group(1), r.text
        else:
            return '?',''

seems interesting, and with it's own implementation challenges:
https://pubs.acs.org/doi/10.1021/acsomega.1c06142
inplementing this EoS could help in SLE equilibria, as probably any composite model would require the same infraestructure

hi, im developing some packages that are of common interest, namely, ThermoState.jl and ThermoModels.jl. im working with multiparameter equations of state (IAPWS95 and GERG2008)) and i needed a solver that requires the least amount of pressure evaluations posible. playing and trying to find something better, i found a good iteration scheme that converges to the gas volume or the minimum gas root available (a root that returns a pressure lower than the specified pressure, but is in the gas side of the pressure equation. the iteration exploits the property that, at gas densities you can do:

p = RT/(v-b)  - a/v^2 # at gas densities, v-b ≈ v
p = RT/v  - a/v^2

at each step:

1. p(n), v(n)
2. a(n+1) -> a(p(n),p(n))
3. v(n+1) = v(pspec,a(n+1))
4. p(n+1) = p(v(n+1))

i have an implementation here and i would love to see if the claims above mantain over complicated eos like the saft family

Dear all,
I'm new in Julia, and quite exited with this project. I'm a researcher and I've been developing yet another GC EOS since 2008, and I'd like to make it available.
So, I've been trying to follow some of the pynb examples, but it seems that the function names have been redefined or something.
For example, in the Gross2002.ipynb, the package is still called OpenSAFT.
Also, it seems that some function definitions have changed, as for example system. When I execute it I get
UndefVarError: system not defined

Stacktrace:
[1] top-level scope
@ In[3]:2
[2] eval
@ ./boot.jl:360 [inlined]
[3] include_string(mapexpr::typeof(REPL.softscope), mod::Module, code::String, filename::String)
@ Base ./loading.jl:1094
And it seems to work now with a function directly called PCSAFT instead. The same goes for get_crit_pure which seems to be now just crit_pure.

The example notebooks are great, but they seems needing an update. Since I'm starting, and they serve as exercises, I can do it; but I need kind of manual that I'm not sure how to get all the correct function names. Is there a manual which I can access?
Regards

I'm interested in using Claperyon for modelling the purification of molten lithium through crystallizer units. I have looked into using SOLIDS within Aspen Plus, and I was wondering whether Claperyon had a suitable alternative for this purpose. I see you have NRTL implemented, but I couldn't find something exactly as what I was looking to use in Aspen Plus.

Is anyone currently looking to add SOLIDS model to Claperyon?

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Hi! I'm trying to do some calculations about drugs using clapeyron.jl. I referred to the information in the user guide (using your own parameters). I have written:

model = PCSAFT(["griseofulvin","water"];userlocations=["C:/Users/GK/Desktop/Clapeyron.jl-master/PCSAFT_like.csv","C:/Users/GK/Desktop/Clapeyron.jl-master/PCSAFT_unlike.csv","C:/Users/GK/Desktop/Clapeyron.jl-master/PCSAFT_assoc.csv"])
T = 310.15
p = 1.01325e5
z=[0.00024993751562109475, 0.9997500624843789]
γ1=activity_coefficient(model,p,T,z)

However, when I calculated the activity coefficient of griseofulvin in water, the results were wrong.
The activity coefficient of griseofulvin, 3.740122415836513e8, The activity coefficient of water 1.0000354641606668

In fact, the correct result should be 47384.9 for griseofulvin and 1.04428e+10 for water.

I feel like I have a problem defining new parameters. Could you provide an example of defining a new component?

Also, binary interactions are usually linear functions of temperature, which the current code doesn't seem to take into account.

An impressive EoS: https://www.sciencedirect.com/science/article/pii/S0378381222000814

Aside from the GC component, I think we should be able to implement it very easily.

https://doi.org/10.1016/j.fluid.2020.112496
https://doi.org/10.1016/j.fluid.2020.112749 (corrigendum)

Basically, a GERG2008-like model for fluids containing ammonia and related mixtures.

Apart from the old function names due to the differences of the master/development branches in all notebook examples.

I found that in Gross2001.ipynb for all components, the "sat_pure" functions throws a log error when fed temperatures near the critical temperature (starting at around 20 Kelvin below it).

I found that the issue is caused by negative numbers in the expression "log(\zeta3-1)" part of the hard-sphere contribution a_hs. I think the solver moves outside the feasible region when trying to find saturation.
Maybe bounding the input domain with log(max(\zeta3-1,1E-330)) will do the trick.

Interesting new paper which extends SAFT-VR Mie using renormalisation methods: https://pubs.acs.org/doi/10.1021/acs.iecr.2c02004

This is a common strategy that's been used in SAFT-VR SW and soft-SAFT in the past. Could be interesting if we support something like this.

I tried:

using Clapeyron
import Pkg; Pkg.status("Clapeyron")
model = SAFTVRQMie(["helium"])
sat = saturation_pressure(model, 4)

and I obtained

Status `~/.julia/environments/v1.8/Project.toml`
  [7c7805af] Clapeyron v0.3.11
MethodError: no method matching -(::Matrix{Float64}, ::Float64)
For element-wise subtraction, use broadcasting with dot syntax: array .- scalar
Closest candidates are:
  -(::T, ::T) where T<:Union{Float16, Float32, Float64} at float.jl:384
  -(::LinearAlgebra.UniformScaling, ::Number) at /opt/homebrew/Cellar/julia/1.8.3/share/julia/stdlib/v1.8/LinearAlgebra/src/uniformscaling.jl:146
  -(::ChainRulesCore.AbstractThunk, ::Any) at ~/.julia/packages/ChainRulesCore/C73ay/src/tangent_types/thunks.jl:34
  ...

Stacktrace:
  [1] d(model::SAFTVRQMie{BasicIdeal}, V::ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, Float64}, Float64, 1}}, ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, Float64}, Float64, 1}, 1}, T::Float64, z::StaticArraysCore.SVector{1, Float64}, i::Int64, _data::Tuple{Float64, Float64, Float64, Float64, Float64, Matrix{Float64}})
    @ Clapeyron ~/.julia/packages/Clapeyron/wx1tK/src/models/SAFT/SAFTVRMie/variants/SAFTVRQMie.jl:152
  [2] d(model::SAFTVRQMie{BasicIdeal}, V::ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, Float64}, Float64, 1}}, ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, Float64}, Float64, 1}, 1}, T::Float64, z::StaticArraysCore.SVector{1, Float64}, _σeff::Matrix{Float64})
    @ Clapeyron ~/.julia/packages/Clapeyron/wx1tK/src/models/SAFT/SAFTVRMie/variants/SAFTVRQMie.jl:178
  [3] macro expansion
    @ ~/.julia/packages/Clapeyron/wx1tK/src/utils/macros.jl:77 [inlined]
  [4] data(model::SAFTVRQMie{BasicIdeal}, V::ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, Float64}, Float64, 1}}, ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, Float64}, Float64, 1}, 1}, T::Float64, z::StaticArraysCore.SVector{1, Float64})
    @ Clapeyron ~/.julia/packages/Clapeyron/wx1tK/src/models/SAFT/SAFTVRMie/variants/SAFTVRQMie.jl:86
  [5] a_mono(model::SAFTVRQMie{BasicIdeal}, V::ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, Float64}, Float64, 1}}, ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, Float64}, Float64, 1}, 1}, T::Float64, z::StaticArraysCore.SVector{1, Float64})
    @ Clapeyron ~/.julia/packages/Clapeyron/wx1tK/src/models/SAFT/SAFTVRMie/variants/SAFTVRQMie.jl:74
  [6] macro expansion
    @ ~/.julia/packages/Clapeyron/wx1tK/src/utils/macros.jl:77 [inlined]
  [7] a_res(model::SAFTVRQMie{BasicIdeal}, V::ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, Float64}, Float64, 1}}, ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, Float64}, Float64, 1}, 1}, T::Float64, z::StaticArraysCore.SVector{1, Float64})
    @ Clapeyron ~/.julia/packages/Clapeyron/wx1tK/src/models/SAFT/SAFTVRMie/variants/SAFTVRQMie.jl:79
  [8] eos_res(model::SAFTVRQMie{BasicIdeal}, V::ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, Float64}, Float64, 1}}, ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, Float64}, Float64, 1}, 1}, T::Float64, z::StaticArraysCore.SVector{1, Float64})
    @ Clapeyron ~/.julia/packages/Clapeyron/wx1tK/src/base/EoSModel.jl:68
  [9] (::Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}})(x::ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, Float64}, Float64, 1}}, ForwardDiff.Dual{ForwardDiff.Tag{Clapeyron.var"#fAᵣ#188"{SAFTVRQMie{BasicIdeal}, Float64, StaticArraysCore.SVector{1, Float64}}, Float64}, Float64, 1}, 1})
    @ Clapeyron ~/.julia/packages/Clapeyron/wx1tK/src/methods/VT.jl:128
 [10] f∂f
    @ ~/.julia/packages/Clapeyron/wx1tK/src/solvers/ad.jl:32 [inlined]
 [11] f∂f∂2f
    @ ~/.julia/packages/Clapeyron/wx1tK/src/solvers/ad.jl:44 [inlined]
 [12] second_virial_coefficient_impl(model::SAFTVRQMie{BasicIdeal}, T::Float64, z::StaticArraysCore.SVector{1, Float64})
    @ Clapeyron ~/.julia/packages/Clapeyron/wx1tK/src/methods/VT.jl:129
 [13] second_virial_coefficient(model::SAFTVRQMie{BasicIdeal}, T::Float64, z::StaticArraysCore.SVector{1, Float64})
    @ Clapeyron ~/.julia/packages/Clapeyron/wx1tK/src/methods/VT.jl:122
 [14] x0_sat_pure(model::SAFTVRQMie{BasicIdeal}, T::Float64, z::StaticArraysCore.SVector{1, Float64}) (repeats 2 times)
    @ Clapeyron ~/.julia/packages/Clapeyron/wx1tK/src/methods/initial_guess.jl:147
 [15] saturation_pressure_impl(model::SAFTVRQMie{BasicIdeal}, T::Float64, method::ChemPotVSaturation{Nothing, Nothing})
    @ Clapeyron ~/.julia/packages/Clapeyron/wx1tK/src/methods/property_solvers/singlecomponent/saturation/ChemPotV.jl:78
 [16] saturation_pressure(model::SAFTVRQMie{BasicIdeal}, T::Int64, method::ChemPotVSaturation{Nothing, Nothing})
    @ Clapeyron ~/.julia/packages/Clapeyron/wx1tK/src/methods/property_solvers/singlecomponent/saturation/saturation.jl:47
 [17] saturation_pressure(model::SAFTVRQMie{BasicIdeal}, T::Int64)
    @ Clapeyron ~/.julia/packages/Clapeyron/wx1tK/src/methods/property_solvers/singlecomponent/saturation/ChemPotV.jl:74
 [18] top-level scope
    @ In[17]:4
 [19] eval
    @ ./boot.jl:368 [inlined]
 [20] include_string(mapexpr::typeof(REPL.softscope), mod::Module, code::String, filename::String)
    @ Base ./loading.jl:1428

The provided ipyb example for the SAFT EOS seems to have some issues:

Specifically getting the critical points seems to produce a domain error (command: crit = crit_pure.(models); for the associated domain error see the attached file.

julia-ipyb-error.txt

add this when the paper is released, modify readme mentioning how to cite

Hi, I am using Calpeyron and have it working. However, even for a simple model with 2 components CO2 and N2 if I do a bubble point calculation it takes an enormous amount of time to get an answer. In fact, just setting the model takes ages.

I am doing this from the REPL. Is there a way to speed things up or is this as good as it is.

My session is:

using Pkg
using Clapeyron
model = GERG2008(["carbon dioxide","nitrogen"]);
z=[0.996,0.004];
bubble_temperature(model,40e5,z)

I am doing this from the REPL. Is there a way to speed things up or is this as good as it is.

Thanks

Hello Paul,
Thank you for a great talk at Juliacon 2021.
There is an error in the mapreduce call calculating molecular weights. The operators +,* should be interchanged to fix this issue. I have sent a pull request to fix this
Regards
Ramesh

thanks to julia broadcasting system, you can do:

f.(vec) 

that evaluates f in a vector vec.
at the moment, for example, get_volume returns a vector, but in the rest of equations, just the first element is used
to support this properly, you need to make the EoS broadcastable, this can be done by:

Base.broadcastable(x::SAFT) = Ref(x)

related to #52 .
the current situation is the following:
we have a damped sucessive substitution solver for the association fractions. the only way to control the current output of this is by passing a absolutetolerance=1e-12 keyword
as of 0.2.6, we solve analytically when there is one site (giving a lot of speed up on pure models)
The iteration procedure has a damping factor of 0.5 and (as 0.2.8) does 1000 iterations before giving up.
Maybe we can create an struct that can hold more information about the iteration procedure in addition to the tolerance, like iterations, damping factor, something like:

struct AssocOptions
  iterations::Int
  dampingfactor::Float64
  absolutetolerance::Float64
end

Another way to to this would be by calculating the max amount of iterations automatically, maybe 500*number_of_sites ? or a quadratic relation?

Just a list of things we need to fix in our implementation of the HELD algorithm:

• Rather than use randomly generated points for initial guesses in step 1 and step 4, use sobol points
• Fix the convergence issue with VLE phases
• Loop step 8 to step 3
• log-compositions on step 7?
• Try using BlackBoxOptim for step 4 and 7 instead of NLSolvers
• Recommendation: Solve step 4 multiple times to generate as many candidate phase as possible. Could speed up convergence?
• Use tunnelling in step 4? To avoid repeated solutions?

I am just curious what the roadmap is for flash calculations? Will you be implementing such things as the Tangent Plane Criteria etc and essentially solve for the number of possible phases automatically? Do you need or want help?

Pretty sure we wouldn't be able to support this, but still quite cool: https://aip.scitation.org/doi/10.1063/5.0096875

I had issues regarding the installation instructions.

Using:
Pkg> add [email protected]:ypaul21/OpenSAFT.jl.git
Lead to a repeated asking of a private/public ssh-key. Seems to be an open issue wen downloading private repos in julia (see e.g. https://discourse.julialang.org/t/pkg-clone-keeps-asking-for-my-ssh-key/15155)

A trivial but yet effective solution was to use instead:
Pkg> add https://github.com/ypaul21/Clapeyron.jl.git