2022-11-21 Core Developers meeting notes

Participants

  • @Matt Thompson

  • @Jeffrey Wagner

  • @David Dotson

  • @Pavan Behara

  • @Diego Nolasco (Deactivated)

Discussion topics

Item

Notes

Item

Notes

General updates

  • JW – This Thursday+Friday, US people will be out for Thanksgiving

  • JW – UC strike is continuing

  • JW – JM is offline for 2 weeks.

  • JW – LW is offline next week.

  • DD – Possibly offline next Monday, will update calendar/status.

Individual updates

  • DN

    • Working a lot with OpenFE.

    • As you know, OMSF got CZI grant, which means we can have an in-person meeting using those funds. I talked to governing and advisory board about preference for time/place. Offered to do this alongside alchemistry in May in Boston, or ACS in San Francisco in August. Everyone preferred Boston in May. Do you have any preference between these two?

      • MT – No personal preference. Certainly seems like we should have a meeting before next renewal. So May seems better. But both dates would work for me.

      • DD – No personal preference. I’m happy to be at either.

      • PB – I’m fine with anything.

      • DN – Great, I’ll take this info to Karmen.

  • MT

    • Spent most of last week trying to update fitting stack up to date with latest version of core packages. Most of it is done but need to coordinate on getting the changes into place.

    • Is anyone actively using evaluator or recharge? If there are deployment issues please let me know, it’s been too quiet the last few months.

    • I’ve decided to update the openMM export in Interchange to default to combine nonbonded forces. This is what OpenFF Toolkit does when you run forcefield.create_openmm_system, but Interchange.from_smirnoff had defaulted to NOT combine the nonbonded forces. So now those will always be combined by default. This is mostly motivated by standardizing the behavior of our stack, but it may coincidentally fix some problems we were seeing in tests with the OpenMM 8 RC.

    • Also some other minor interoperability improvements to Interchange are likely in the upcoming release.

  • DD

    • Protein-ligand benchmarks / fah-alchemy

      • test suite to 80%

      • laid out issues for first release 0.1.0, second release 0.2.0

      • API clients and services now share core components, internally consistent

        • added authentication, JW tokens for APIs

      • tapped in David Swenson for CLI components; building up familiarity with codebase for some cross-pollination with OpenFE

        • added in database init, clear, and checks

      • Could use a bit of JM time in Jan to build up docs

        • JW – I’ll see if this fits into JM’s schedule - Currently is tentatively assigned to do initial NAGL docs, but the timeline for that is uncertain. We can also explore whether OpenFE is interested in helping generate docs for F@H-alchemy.

      • this week

        • continuing focus on compute service

        • probably reworking task queue system to be based on weights

    • QCA management

      • updated prod envs to use latest toolkit, QCEngine, QCElemental

        • not compatible with current release of psi4

    • JW – Expect MOsato to become the new F@H submission operator. Unfortunately she won’t come online until April, so you’ll need to work it for the first few months.

      • DD – Sounds good. That’ll give me the chance to dogfood it a bit to find the worst problems.

  • PB

  • JW –

    • 0.11.4 toolkit release.

    • Working on bespokefit stuff

    • Finalizing annual survey, will send out in Dec

    • We’ll be meeting with LPW on Weds to discuss best path forward on ForceBalance - How to divide responsibility for maint/whether to just work. Outcome will be somewhere between (we get to make some cleanups and simplifying changes and merge a bunch of PRs) <--> (we fork ForceBalance and jettison a bunch of stuff that makes CI hard)

      • DD – Hard dep on pymbar?

      • MT – It’s a dep of an optional dep, or something like that?

      • JW – It may be used for solvation free energies/evaluator stuff

      • PB – For LJ fitting, rarely used for valence parameters. Valence parameters can by satisfied by simpler minimizations. LPW doesn’t seem confident that new pymbar wouldn’t slow down FB fits. So I think that gaining agreement will require LPW to run testing on runtime and accuracy.

      • JW – FB is kinda hard to maintain, not all behaviors are tested, it’s not clear what warranty we have to offer on “things that break after our changes”, and it’s hard to predict how much engineering time we might need to spend to keep good relations if things break.

      • MT – More directly, FB hasn’t been actively maintained for a while, low test coverage, and tests have basically been failing using the most recent versions of deps for several months. The tests are just running the studies, but many (most) of them are currently skipped. This doesn’t align with our critical reliance on FB in our fitting stack. We could also greatly simplify things by removing Tinker, the GUI, other things.

      • DD – License?

      • MT – BSD3

      • DD – JC had talked a lot about a ForceBalance replacement using bayesian stuff. We didn’t have the resources at the time, but the current trajectory of ForceBalance is basically guaranteed to slow us down.

      • PB – It’d be difficult to do that - When we get in vsites/polarizable FFs, we may need TINKER to benchmark with certain types of functional forms. So maybe we can ask LPW to do further testing.

      • DD – I don’t think there’s a clear way to motivate LPW to update tests/maintain more.

    • Moved OE license channel to OMSF slack - Let me know if you need access to this and don’t have it.

      • JW – I didn’t see that DD ever had access to this license?

      • DD – I’m not on the OMSF slack…?

      • DN invites DD to OMSF slack

    • Worked with RAlford of J&J on some trickier PTM stuff. One example was that the LibraryCharge SMIRKS made by Chemper using the cap-and-charge approach won’t actually match the residue in the protein if there’s a disulfide bond that makes the backbone a loop, since the capped residue SMIRKS explicitly sets it to “no ring” in the bonds and atom descriptions.

Action items

Decisions