You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Remove the sparse solver for Association, the cost of building sparse matrices is not worth it, specially with combining rules. if we implement that + an special, non-allocating rule for association with 1-site, 1-comp, will allow 0 allocations PCSAFT.
Rename x_userlocations to x_userparams (@pw0908). now that we accept parameters, seems a better name indeed
There is still the problem with what should be the output from tp_flash models. we need to return the volumes, and the phases. maybe as a named tuple?
On the sigma profiles, if we don't include the meta field (a JSON file),then reading those seems straightforward. i could whip up a reader, but i would need some examples to see what are the possible universe of valid profiles to parse
On the parameter writing, we kind of already have a writer (ParamTable can write to disk) but given that now we can pass those parameters directly, i would say that we should deprecate that and adapt the current writer to take all the params in a model recursively.
Remove the sparse solver for Association, the cost of building sparse matrices is not worth it, specially with combining rules. if we implement that + an special, non-allocating rule for association with 1-site, 1-comp, will allow 0 allocations PCSAFT.
Rename
x_userlocations
tox_userparams
(@pw0908). now that we accept parameters, seems a better name indeedThere is still the problem with what should be the output from
tp_flash
models. we need to return the volumes, and the phases. maybe as a named tuple?Multiparameter models (Unify all Single Empiric Helmoltz models under one struct #148)
The text was updated successfully, but these errors were encountered: