Page Comparison

General updates

• MT

  • Could I take weds+fri of thanksgiving week off?

    • JW – Approved, please file in justworks.

• JW

  • Following from lead team discussion - when reasonable let’s add 24h delay after last PR is merged so “latest CI” can run.

    • MT – Makes sense. In my followup investigation it wasn’t clear that any of our CI tests would have caught it pre-release. The “latest everything” tests don’t run

    .Path forward for units

    • tests from all repos, so things could have slipped through.

  • Request for spiritual guidance: Mysterious CI failures for GBSA energy comparison (for systems created using openff vs. created using OpenMM) , only on macos15, only for a single mol in freesolv, only for a single permutation of settings. Any hints?

    • MT – OS differences for packages are possible. Could try A/B testing openmm versions and platforms. OE/RDK/AT versions also come to mind. If it’s just 1 of many mols, it’s possible that others have differences that are staying just under tolerances. You’ll probably need to diff serialized systems. If you can pass same system through different VMs and get different outputs that’s a smoking gun. I’m seeing some small differences using openmm 8.1.2 and 8.2.0. Recommend looking at nonbonded settings FIRST (especially switching function, cutoffs, 1-4 exceptions). Also compare GBSA parameters. Also wouldn’t ignore possibility that something is being set differently for GBSA. Also I skimmed the OMM 8.2 releasenotes and PRs and didn’t see anything that touches nonbonded values, but I wasn’t looking for GBSA specifically. I have a very weak suspicion that there’s a hard-to-pin-down corner case, maybe something to do with platform selection.

    • Github link macro
      link https://github.com/openforcefield/openff-interchange/issues/1101

    • JW – I should check into platform selection on macos 15 - That could explain a lot.

  • I’ve “picked” OFFTK + OFF Units 0.2.3? main this sprint

    • Issues

      • Lazy loading (likely solved)

      • Mypy issues in Toolkit (yuck)any tips?)

    • MT – Start with units main branch, don’t try to use 0.2.3. For mypy issues - We’re a few releases behind pint (and pinned as such) since they move fast and break things. Pint is kinda a relic from pre-typing python - eg if you’re given a class like Quantity, it could be somethat that wraps a scalar or list or numpy array and has fancy stuff with xarray and pandas etc. So it’s highly polymorphic (by design) and getting typing to work is difficult since our usage of it just corresponds to a small subset of pint’s possibilities. So you’ll get a lot of typing errors regarding union-types. One way this could be worked around is by providing stubs (adding type annotations where upstreams don’t provide them). Also, using unit.Quantity to instantiate something confuses unit system, but doing the same by importing Quantity directly is fine.

    • JW – Two things I’m thinking of are:

      • Drop type checking (or at least on this part)

        • MT – I see only downsides here

      • Try using a newer pint and hope that it works better

        • MT – I think this could work, unsure what this would look like.

        • JW – So maybe I could start a branch of openff-units that uses new pint, and once that has green CI, then start a toolkit branch that installs from that pint branch and see if it gets happy.

        • MT – Right. Though be warned that we currently support 3-ish major pint versions, and adding more might cause trouble. And CI matrix for units package is pretty big, which I think is necessary to support this range of versions for pint.

        • MT – Also, some pacakges pin to old versions of mypy, so it might be that toolkit’s mypy is out of date, or that this may complicate finding a single version to work across our ecosystem.

        • It’s currently pinned to mypy 1.9, which is kinda old (1.10 had a lot of changes, 1.16 or something is newest)

          Github link macro
          link https://github.com/openforcefield/openff-units/blob/6eef13fe29478e8d59982be66b3010b5f2a298aa/devtools/conda-envs/test_env.yaml#L19

  • Gov board told us to go ahead and create PTM parameterization product. A good route forward will be directly assigning charges to some atoms of an already-made protein interchange. Do you estimate that will that hit major roadblocks?

    • MT – Unsure but seems unlikely to have major issues. Feel free to reach out once you get to that and I can work on it/help however I can.

Trello

https://trello.com/b/dzvFZnv4/infrastructure