ParamTable doesn't detect the acentric factor parameter

[fedebenelli]

I work with pseucomponents (so my components don't exist in any database). I found the ParamTable approach an easy way
to define my components in a single code cell. But it doesn't seem to work properly (or at least there is a missing step on the documentation)

data = (
    species = ["A", "B"],
    Tc = [18.0, 3.5],
    Pc = [2.3, 0.1],
    Mw = [1.0, 1.0],
    Vc = [1.0, 1.0],
    acentricfactor = [0.1, 0.3]
)

file = ParamTable(
    :single, 
    data,
    name="db1"
)

testmodel = PR(["A", "B"], userlocations = [file])

Gives the error:

cannot found any values for acentricfactor.

Stacktrace:
 [1] error(::String, ::String, ::String)
   @ Base ./error.jl:44
 [2] compile_single(name::Any, components::Any, type::Clapeyron.CSVType, options::Any)
   @ Clapeyron ~/.julia/packages/Clapeyron/teY8P/src/database/database_rawparam.jl:181
 [3] compile_param(components::Any, name::Any, raw::Clapeyron.CSVType, site_strings::Any, options::Any)
   @ Clapeyron ~/.julia/packages/Clapeyron/teY8P/src/database/database_rawparam.jl:137
 [4] compile_params(components::Vector{String}, allparams::Dict{String, Clapeyron.RawParam}, allnotfoundparams::Dict{String, Clapeyron.CSVType}, options::ParamOptions{Vector{String}, Vector{String}})
   @ Clapeyron ~/.julia/packages/Clapeyron/teY8P/src/database/database.jl:380
 [5] getparams(components::Vector{String}, locations::Vector{String}, options::ParamOptions{Vector{String}, Vector{String}})
   @ Clapeyron ~/.julia/packages/Clapeyron/teY8P/src/database/database.jl:215
 [6] #getparams#98
   @ ~/.julia/packages/Clapeyron/teY8P/src/database/database.jl:207 [inlined]
 [7] PR(components::Vector{String}; idealmodel::Type, alpha::Type, mixing::Type, activity::Nothing, translation::Type, userlocations::Vector{String}, ideal_userlocations::Vector{String}, alpha_userlocations::Vector{String}, mixing_userlocations::Vector{String}, activity_userlocations::Vector{String}, translation_userlocations::Vector{String}, verbose::Bool)
   @ Clapeyron ~/.julia/packages/Clapeyron/teY8P/src/models/cubic/PR/PR.jl:76
 [8] top-level scope
   @ In[53]:16

On a side note:

I find it quite unnecessary to define the unneeded parameters, if I want to use a PR model I should just need to define $T_c$, $P_c$ and $\omega$. This makes the use of the library tedious and also user prone to errors since one should check all the code to be sure which parameters are really used and which ones are not.

[longemen3000]

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.

[longemen3000]

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)

[fedebenelli]

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!

[longemen3000]

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