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

0.5 breaking changes #160

Open
2 of 4 tasks
longemen3000 opened this issue Mar 30, 2023 · 2 comments
Open
2 of 4 tasks

0.5 breaking changes #160

longemen3000 opened this issue Mar 30, 2023 · 2 comments

Comments

@longemen3000
Copy link
Member

longemen3000 commented Mar 30, 2023

  • 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?

  • Multiparameter models (Unify all Single Empiric Helmoltz models under one struct #148)

@pw0908
Copy link
Member

pw0908 commented Apr 6, 2023

Some additional features to add (non-breaking):

  • Calculate AADs for each experimental data set in parameter estimation.
  • Export the parameters in a given model to csvs (making our lives easier when doing parameter estimation).
  • Since we're messing around with the reader, add a feature to read in sigma profiles.

@longemen3000
Copy link
Member Author

longemen3000 commented Apr 6, 2023

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.

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

2 participants