Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Item

Notes

General updates

  • JW – Working on QCSubmit fixes, in following order -

    • Permissive loader to skip corrupt dataset entries (ETA today if bespoke chatter dies down)

    • Update for removal of chemicalenvironment

    • Update for next version of QCF

  • Coordination on new releases for pydantic

    • MT – Rolled out for models, interchange, fragmenter. QCSubmit and bespokefit are still to go (maybe one or two more). Big blockers there are that tests don’t currently pass. Will need to be pinned to old stuff in QCA stack. I’m able to make working envs with pydantic 2, but there are probably still some gremlins to work out.

    • MT – A week or two ago I made a new release of openff-models that isn’t pinned to pydantic<2. I thought that would have some issues but nothing’s been reported. LW just merged her big nagl refactor and that should work for pydantic 1 and 2. So most of our stack should be compatible at the deployment, but not necessarily feature, level (all of our changes have used the import guard).

  • MT – It’s hard to work with users on workflows given the options of assembling systems using OpenMMs ForceField class, OpenMMForceFields, and SMIRNOFF.

    • JW – This could be an opportunity to come up with OpenFF-wide recommendations for users doing mixed-FF sims.

    • MT – How about these two options:

      • Only recommend users do workflows entirely in SMIRNOFF-land (ff14SB+parsley/sage+waters)

      • Peter’s FF class + + operator - but this would require further QA of from_openmm and + operator

    • JW – As a strawman proposal - How about we recommend 1) for folks whenever possible (when the OFFXMLs already exist) and 2) when they need an external FF, but we basically caustion against 3) (OpenMMForceFields-based workflows) and we warn them that deprecation is coming at some unspecified.

    • MT – Route 3 (OpenMMForceFields) is what OpenFE is doing

    • MT – There’s a more fundamental decision to make: Do we support people in making workflows other than what’s supported by route 1 at all?

      • JW – I think this is a business decision - I’ll run it by DMobley

    • MT – I think we need to support external FFs. There’s already a ton of momentum behind route 3. How would we go about changing people to using route 2?

    • JW – We could decide OMSF-wide that we should only instruct people to make workflows with route 2, and caution that route 3 won’t be supported in the long run.

    • MT – I don’t think that will actually be feasible in day to day work - We can’t refuse the built things for the people that pay us if they require route 3.

    • JW – I’ll start a discussion with OMSF about this idea - If we all get behind using route 2 and not route 3, I think we can train users.

Trello


Issues/PR

Action items

...