| | |
|---|
Status | MT | v2-only branches in models and Interchange packages are sorta “development done” These changes will come in versions OpenFF tests looking good:
Upcoming changes in Interchange 0.4.x: Upcoming changes in Interchange 0.4 — openff-interchange documentation IA: Will there be deserialization changes? (i.e. this could change existing alchemiscale results, and/or gufe settings) MT: Probably? Haven’t looked into it yet. Generally the expect the same version to round-trip. No guarantees a 0.3x JSON on disk will be loadable by 0.4 API. (General): Not clear how much a serialization change of Interchange would affect alchemiscale results (General): Might need to build some sort of migrator. Need to run tests to see if this is needed/how much it’s needed, if a migrator is feasible, etc.
All release Interchange builds should be constrained to current models 0.1.x line which is v2/v1 compatible These changes are all about using the v2 API, so I think (?) by definition v1 will not be allowed at install/packaging time
|
Timelines | MT | openff-models 0.2.0 (v2 API only) will come out sometime Interchange 0.4.x beta1 will be made at unclear date 2+ week of “no critical bugs” before Interchange 0.4.x Rc1 for for 2+ weeks 2+ weeks more testing before full Interchange 0.4.0 release After Interchange 0.4.0 release, 0.3.x line will move to “critical bugfixes” only for 4 months and all development will be in 0.4.x
MT: Sound okay? IA: Can’t comment on speeds now. Hannah is working on new GROMACS protocols - how does this relate to 0.4 transition? MT: Current changes are all in 0.3 line:
MT: Future or larger changes might need to get pushed back to 0.4 line MH: We’ll need to migrate to 0.4 eventually anyway MT: Most stuff/changes should be small, especially if not hooking into the API
IA: Unclear right now the scope of changes that OpenFE will need. Will need to do some tests (currently OpenFE’s responsibility). A little concerned about serialization, particularly units and gufe keys
|
Next? | | Downstream users of OpenFF infrastructure shouldn’t be affected if the right pins are made (might need to patch old builds!) Downstream developers could test the upcoming changes by installing against the two branches linked above (MT) Currently unaware of any major changes that OpenFE would need associated with these changes (MT) If there’s non-trivial coordination work to be done, let’s involve James early
|
| MH | How much work associated with v1-v2 migration? … Did some screen-sharing, an important outcome was classes from openff.models.dimension_types will do dimension checking but will NOT convert units (since it doesn’t know one classes from openff.models.unit_types will do above but ALSO convert into the defined units i.e. (general takeaway is that in the example of the thermo settings class in gufe, probably want to use a KelvinQuantity to ensure current behavior persists) In [14]: from openff.models.models import DefaultModel
In [15]: from openff.models.types.unit_types import *
In [16]: from openff.models.types.dimension_types import *
In [17]: from openff.units import unit, Quantity
In [18]: class NanometerClass(DefaultModel):
...: x: NanometerQuantity
...:
In [19]: class LengthClass(DefaultModel):
...: x: LengthQuantity
...:
In [20]: y = "1.5 angstrom"
In [21]: LengthClass(x=Quantity(y))
Out[21]: LengthClass(x=<Quantity(1.5, 'angstrom')>)
In [22]: NanometerClass(x=Quantity(y))
Out[22]: NanometerClass(x=<Quantity(0.15, 'nanometer')>)
|