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
It would be useful to have a lightweight package for easily reading, interrogating, manipulating, and doing analysis of the JSON analysis files we generate from fah-xchem. To do this, we currently need to install the whole fah-xchem package (including several fragile pip+git installs), which is not friendly for any downstream users.
We should consider splitting the object models into a second package, perhaps harmonizing these with perses and the OpenFE effort.
Use cases might include:
Browsing the datasets for use in generating new compound designs
Analyzing accuracy of free energy calculations and interrogating failure modes
Training machine learning models to predict free energies or difficulties of transformations
Experimenting with better network construction or network free energy analysis methods
The text was updated successfully, but these errors were encountered:
We could have fah_xchem the library and fah_xchem_schema for the pure-schema structures, but keep them side-by-side in this repo. Do you see any problem with this proposal?
We don't need the entire object model to always live here
Much of the schema / object model is actually general, with xchem applications having specific interpretations of various fields (e.g. xchem_project is the specific project name, but all projects will have names; xchem_fragment_id is just a unique ID for the reference X-ray structure used)
We can refactor within this repo to generalize the object model and then eventually migrate into general FAH alchemy infrastructure as appropriate
It would be useful to have a lightweight package for easily reading, interrogating, manipulating, and doing analysis of the JSON analysis files we generate from fah-xchem. To do this, we currently need to install the whole fah-xchem package (including several fragile pip+git installs), which is not friendly for any downstream users.
We should consider splitting the object models into a second package, perhaps harmonizing these with
perses
and the OpenFE effort.Use cases might include:
The text was updated successfully, but these errors were encountered: