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
this should NOT be pulled down in any openff environments - could use support in double-checking that this would be true
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!)
openff-models ~=0.1.2
openff-interchange ~=0.3.29
Downstream developers could test the upcoming changes by installing against the two branches linked above
No migration guide (how useful would this be?) but the diff of the tests in models PR #42 is the gist of the Pydantic-facing changes
(MT) Currently unaware of any major changes that OpenFE would need associated with these changes
Something could crop up in testing period(s)
(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')>)
Action items
@Matt Thompson run Interchange serialization tests with 0.3.x on disk and 0.4 in-memory
OpenFE will run tests against development branches