Page Comparison

Status

MT

• v2-only branches in models and Interchange packages are sorta “development done”

  • Github link macro
    link https://github.com/openforcefield/openff-models/pull/42

  • Github link macro
    link https://github.com/openforcefield/openff-interchange/tree/develop

• These changes will come in versions

  • openff-models 0.2.0

  • openff-interchange 0.4.0

  • (toolkit does not hook into pydantic directly)

• OpenFF tests looking good:

  Github link macro
  link https://github.com/openforcefield/status/pull/78

• Upcoming changes in Interchange 0.4.x: https://docs.openforcefield.org/projects/interchange/en/stable/v0.4-changes.html

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

    Github link macro
    link https://github.com/openforcefield/openff-interchange/issues/1014#issuecomment-2263981634

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

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

• Code Block

  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')>)