2022-08-08 Core Developers meeting notes

General updates

• JW and DN will need to leave for the governing board meeting, can stay 30 min.

• DN – Got an email from TFox at Boehringer Ingelheim - They’re pulling out of OpenFF, but will continue funding OpenFE. He says it’s the manager’s decision, and he thinks this team had been doing a good job. Not sure if this is related, but KMeier asked to meet me this Thursday.

Individual updates

• JW

  • Helping JMitchell with examples updates, led to looking for runtime performance improvements

  • Worked with MThompson on some vsite debugging. Lots of tricky little things. This week we’ll look at debugging using OpenMM’s TIP4P as a reference.

  • CDavel is making good progress on a custom-polymer-loader (helps users define substructures for loading non-protein polymers). Code is unlikely to become main-line functionality in the near future, but if folks are interested in testing I can put you in contact.

  • Basically doing final 0.11 release prep now, expect release any day.

• DN

  • Two months ago, I told DMobley that I’d build a “Critical Path” document - This is usually used to show how much time it will take to develop any of the features that we’re developing. It turned out to be a challenging job, since we have tech and science together. If we were just technical developers and we didn’t worry about science, then making time predictions would be easier. But since this project has science side-by-side with our development, it gets a lot more complicated. So I’ve been unable to put together a document, but I understand where the uncertainty/difficulty comes from. If we can get this out, it will help show people how to spend time on a daily basis.

• MT

  • A lot of my time+effort went into attempting to figure out why different versions of vsites workflows work/don’t work. We’ve teased out a few details:

    • In openmm-world, you can either put all the vsites at the end of the topology, or you can collate them in between the atoms/molecules. Either one is fine, but your topology and system particle orderings need to line up. We found a bug where the topology and system didn’t agree on this order and that was making bugs.

    • The coordinates passed to OpenMM need to have SOMETHING defined as coordinated for vsites. It wasn’t clear whether these vsite coordinates provided by the user were actually used in the simulation , or whether they were immediately overwritten. It turns out that they’re immediately overwritten, so the user can just provide all 0’s to OpenMM

  • Did a lot of looking into other reasons why vsites may be difficult/tip4p boxes may be exploding. Haven’t pinned it down. It’s not clear that this is a hard requirement for the 0.11 release, since we seem to be matching the old toolkit behavior.

  • Poked around ecosystem packages to get them ready for 0.11 release.

  • Tidied up Interchange code that handles OpenMM imports, this could unlock a lot of other imports in the short run as well. This isn’t ready for production use, but let me know if you’re interested in helping test.

• DD

  • Was out 7/28 - 8/4

  • Protein-ligand benchmarks

    • Focused on getting a few PRs out on gufe that are blocking components that build on them.

    • Then turning most of my attention to building fah-alchemy components

      • Storage and execution components built on existing data model for alchemical networks

    • Would like to meet with Diego sometime this week to update the project planning page

      • Route to achieve project goals changed due to collaboration with OpenFE. This was good, but need to update project plan.

    • ~4 weeks out from Sept 1 deadline for OpenFF use

  • QCArchive

    • keeping workers running on Lilac, MPI

      • PRP is not running jobs for RNA and protein datasets

    • responded to Chodera on mismatch between actual throughput on SPICE vs. their estimate

• PB

  • Fitting wise, I got the double exponential fits done, benchmarks mostly overlap with Sage refit on the same set of targets. I also optimized the 1-4 scaling factor with QM data along with other valence parameters, which showed slight improvement on TFD benchmark but RMSD and ddE remain almost same. scale14 changed from 0.5 to 0.33.

    • PB - Discussed this work in BespokeFit meeting last week

    • DD - Improvment on TFD alone still seems good, right?

    • PB - Yes, but it’s unclear whether scale14 should be optimized to QC or experimental datasetes

    • MT - Could you summarize your thoughts on that?

    • PB - We optimize other nonbonded parameters to experimental condensed phase properties, so I thought it makes sense to optimize scale14 to similar targets

    • MT - Do we have co-optimization infrastructure ready?

    • PB - Yes, but I’m the first person to use it. I used it for the double exp fit, but we coud use it for the general force field. SB also looked at optimizing the 1-4 scaling factor before he left.

    • MT - Is that documented somewhere? Often things like this work on a small scale but getting them into a big release somewhere is a hurdle.

    • PB - This is well documented in SB’s work, we just need developer time to finish getting it into a release.

    • MT - Is the 0.33 from a fit with double precision or a hand-picked 1/3?

    • PB - It’s from a fit.

  • Adding more targets from Gen1 and Gen3 didn't show any improvement in benchmark metrics except for slight improvement in ddE. Checked whether adding more torsion targets skewed the priority towards matching energies but it didn't.

  • Helped an OE application scientist to reproduce Lim-Hahn benchmarks with Szybki instead of openmm.

    • DD - What’s required to run with Szybki?

    • PB - It’s an MD engine. It does geometry optimization using MM force fields.

• CC

  • I worked on applying for an NIH postdoctoral fellowship. That is out the door and no longer a blocker.

    • proposing to work on some of the RNAs with therapeutic modifications via MD

  • Spent most of my time on LiveCOMS article on protein FF development

    • working on introductions to each section; can then push back to authors

    • aiming to get submitted in next 4-6 weeks, depending on author feedback

  • DD - how are protein QC datasets?

    • CC - slow but steady progress. This is not a blocker.