ParamTable doesn't detect the acentric factor parameter about clapeyron.jl HOT 4 CLOSED

yeah, paramtables are something of a stopgap that we coded a long time ago. now you can pass parameters as a named tuple.

julia> PR(["a1","a2"],userlocations = (Tc = [18.0, 3.5],Pc = [2.3, 0.1],Mw = [1.0, 1.0]),alpha_userlocations = (;acentricfactor =[0.1, 0.3]))
PR{BasicIdeal, PRAlpha, NoTranslation, vdW1fRule} with 2 components:
 "a1"
 "a2"
Contains parameters: a, b, Tc, Pc, Mw

but it is a relatively recent development (#156 ). there are some problems with that approach (what to do with group components? association?)

On the acentric factor, PR is really really general Peng-Robinson model, you can pass your own mixing rule, translation model, and alpha function. for example, Twu alpha does not depend on acentric factor. On more complicated models, the dependencies could change. for example, PSRK uses a mixing rule that depends on a UNIFAC model itself, but the main model is still a Redlich-Kwong model RK,. you can check the input parameters of PR (from the docs, or using the julia REPL (?PR):

  Input parameters
  ==================

    •  Tc: Single Parameter (Float64) - Critical Temperature [K]

    •  Pc: Single Parameter (Float64) - Critical Pressure [Pa]

    •  Mw: Single Parameter (Float64) - Molecular Weight [g/mol]

    •  k: Pair Parameter (Float64) (optional)

    •  l: Pair Parameter (Float64) (optional)

In that sense, the main PR model does not depend on acentricfactor, but the (default) alpha model does.
teqp has this function named canonical_PR, that is a shortcut for their generalized cubic form, that assumes the default alpha function and translation model. maybe we could add that.

To answer that specific param table question, you need to pass a table with acentricfactor to alpha_userlocations instead of locations.

from clapeyron.jl.

on the canonical_PR

function canonical_PR(Tc,Pc,acentricfactor,Mw = zeros(length(Tc));k = zeros(length(Tc),length(Tc)), l = zeros(length(Tc),length(Tc)))
    n = length(Tc)
    components = ["component " * string(i) for i in 1:n]
    return PR(components, userlocations = (;Tc = Tc,Pc = Pc,Mw = Mw, k = k,l = l), 
    alpha_userlocations = (;acentricfactor = acentricfactor))
end

then, on a script on a REPL:

julia> canonical_PR(rand(2),rand(2),rand(2))
PR{BasicIdeal, PRAlpha, NoTranslation, vdW1fRule} with 2 components:
 "component 1"
 "component 2"
Contains parameters: a, b, Tc, Pc, Mw

there are of course, some caveats to this. without specifying the molecular weight, you cannot calculate speed of sound measurements. and without specifying an appropiate ideal model, the calorific calculations will assume ideal gas (Cp = 5/2 * R)

from clapeyron.jl.

Thanks for the information! I come from libraries that use a very different approach in terms of modularity, so having the isolated alpha function was new to me.
I do like this approach, but maybe documentation wasn't clear (or straightforward) enough for me to understand that I should give the parameters to two different arguments. At a glance it seems that PR only depends (well it does technically) on those pure parameters only.

Thanks!

from clapeyron.jl.

An update about this. i just added a shortcut for this particular case, while it breaks the purity of the design, it is better for an usability perspective

from clapeyron.jl.