2022-08-01 Core Developers meeting notes

General updates

• DD offline until Thursday

• PB – Could someone run tomorrow’s QCA meeting?

  • JW – Sure, I can do that

Individual updates

• DN

  • Was very sick much of last week

  • Finished subtitles for workshop video - matched up with my sleep level. This was quite difficult as a non-native speaker.

• MT

  • Took a day off last week for a move

  • Spent about half of last week fixing up ecosystem after pymbar 4.0.0 release. Everything is getting downpinned since nobody’s source is ready for version 4. Some of the big changes were changes from camelcase to snakecase. Worked updating forcebalance for this change and upcoming toolkit change. Also worked on Evaluator and Recharge.

    • Forcebalance pins to GROMACS 2019 and I’m not sure why

    • Some tricky things in evaluator which are a bit specific to their deployment (some things assume nvidia GPU, some things geared for lilac) - Haven’t yet run regression tests. Having some trouble testing a fix for hvap

    • Having some trouble with recharge - tricky to make a development environment. Largely difficult due to reliance on a specific psi4 version.

  • At some point this will need to be fixed, especially since we’ll need to fix evaluator+recharge tests in ForceBalance.

    • JW – Let’s see if LW can handle the recharge maint/CI fixing. We can talk about this in our meeting with LW tomorrow.

    • MT – Important to distinguish between nightly CI and deployment tests. For public-facing packages the latter is really important.

  • Interchange regression tests have all been run on my computer/UCI resources. But I can run a lot of them on GH Actions (though not all, many will require larger-scale compute)

• CC

  • Applying for postdoc fellowship from NIH, this took up a lot of time last week. This is submitted to UCSD for internal review so I’ll be waiting on this.

  • Did a lot of analysis on the protein datasets. Conclusion seemed to be that charged amino acids need to get different torsion parameters than their uncharged complement. I’m going to move forward with this assumption but use the validation dataset to subsequently verifiy this.

  • Worked on LiveCOMS review. Will try to get this to authors this week so we can move forward on it. This is important since it will take a long time for this to get to/from reviewers before it gets back to me.

  • MS wanted to see if we could guarantee the protein force field on a sooner date so it would be ready for our NIH grant renewal. Meeting with infrastructure team to talk about it this week.

    • PB – Feel free to use time in the FF release meeting to discuss this.

    • JW – Just to clarify - This meeting is with the “lead team”, which helps diego make decisions about how we spend the industry money. Shirts is accountable for the grant money, but not the pharma funding. I think it’s likely that these goals are closely aligned but we just want to make sure we don’t fail to meet the goals we’re funded for.

• PB

  • Spent a day wrangling with conda envs for openff-evaluator and the pymbar updates, Josh had trouble with dask runs which was just because of a config file which I forgot about. Thanks to Matt for jumping in to fix the compatibility issues.

  • QCA monitoring and optimization dataset for iodine containing molecules.

  • Posted results of valence refit of double exponential functional form for non-bonded interactions. It overlaps well with the sage refit on the same training set. This was on a reduced set of elements, all except {S, P, F, I}, so it didn't do that well wrt Sage vanilla.

  • Filtering out torsion training targets, mixing Gen1 and Gen2 sets, setting up a fit

    • Some general parameters have nearly 300 torsion scans and some have as few as 2. For example, {'t1': 117, 't17': 279, 't18': 184, 't30': 3, 't89':2, 't126':0} after applying filters like connectivity check, hydrogen bonds, undefinedstereo, etc. So, trying out a few iterations capping number of torsion targets to 50, or 20 per parameter.

  • Had a meeting with Openeye appln scientist who is trying to reproduce Lim Hahn benchmarks with Szybki instead of Openmm.

• JW –

  • Fixing final few things for biopolymer release - OE PDB atom indexing done, next is insersion code and warning spam

  • Closed a ton of PRs with MT

  • Meeting this afternoon on protein FF timing/deadlines

  • Chatted with OpenFE - We need to let them know well ahead of time if we’re going to add vsites to a FF release.

    • DN – Could we have a list of reasons that we won’t add vsites to rosemary 3.0.0?

      • OpenFE won’t be ready to handle vsites, so we’ll be unable to benchmark

      • ParmEd can’t handle vsites, interchange is still being developed

      • People expect big gains from vsites on sulfur, but we don’t have experimental data for fitting/validation involving sulfur vsites

      • We’re kinda time-constrained to the NIH renewal schedule so we can’t risk delaying that to add vsites

      • We’d need to tiptoe around proteins, since we’d be some of the first people to apply vsites to proteins.

        • CC – there’s a decent chance that this could improve things like amide torsions. On the other hand, this would add computational cost and users may not want that.

        • MT – This is a significant issue - There are (and will continue to be) different types of practitioners in the field - Some want high accuracy whatever the cost, others want fast simulations.

    • MT – It’d be good to explain why we won’t “fork” the force field lines with/without vsites

      • JW – I think the answer is that it would be incredibly complicated to handle multiple FF lines at the same time. We can barely handle corralling all of the different directions of improvements into a single FF line, it would become much more complex to do that for TWO FF lines.

•