2022-03-30 and 04_01 Thompson/Wagner Check-in meeting notes

Participants

  • @Matt Thompson

  • @Jeffrey Wagner

Discussion topics

Item

Notes

Item

Notes

General updates

Priority ambiguity?

I don’t know what your priorities are, which I suspect means that you don’t either. We could rank order:

  • Ecosystem maintenance (you’ve been doing basically 100% of this for the org!)

  • “Interchange as export mechanism” project plan minimum goals

  • ???

    • System combination (Unclear how to test/no goalposts or references)

    • Vanilla AMBER export (Pretty much done)

    • AMBER export w vsites

    • AMBER export maintaining hierarchy info

    • Vanilla GROMACS export (Pretty much done)

    • GROMACS export maintaining hierarchy info

    • GROMACS export w vsites (Got TIP4P and 5P working, but not broadly funcitonal)

    • AMBER import

    • OpenMM import

    • GROMACS import

    • CHARMM export

    • CHARMM export w/ vsites

    • CHARMM import

    • LAMMPS export

    • LAMMPS import

    • ML export/interface (no spec)

    • ForceBalance replacement (no spec)

  • For hierarchy export to formats:

    • Finish line is something like “Loading an output trajectory in VMD let us do sane selection commands”

    • Big questions for export to different formats are:

      • What if the existing hierarchy info is INCOMPLETE (like, what if there are no residues defined?)

      • What if the existing hierarchy info in INCOMPATIBLE (like, two residues are named identically but have different chemistry/parameters)

 

Background: https://ambermd.org/doc12/Amber21.pdf section 17.5

AMBER email

Hi David and Darrin,

This is great to hear. We've read the manual and are mostly curious about three things:

  • Section 17.5 of the manual says "In Amber20, the sander and pmemd programs only support the most widely used cases of virtual sites (e.g. TIP4P and TIP5P water), but efforts are underway to support a broader variety of these virtual sites." Is there a roadmap for implementation of all of these

  • One of our anticipated virtual site styles is a 4-point model, though that's the least important one. What are the plans for adding that?

  • Are the &rule namelist variables in section 17.5 a 1:1 mapping to values in a prmtop file? (Is this complete+stable?)

Also we don't have access to the pmemd code. Could Matt and I have access to the main AMBER repository? We're "j-wags" and “mattwthompson” on GitHub.

 

MT: Above is approved

JW – Great. I’ll polish it and send to Mobley next

PR/issue clearance

  • MT:

    • JW – May be good to say exactly what you want from maintainers - Basically “This is a WIP, please activate tests”

    • JW – No need to have me review this, feel free to ping JM for a spot-check.

    • JW – The final energies seem resonable to me, the spec doesn’t actually say what the exclusion policies mean, so I’m not sure what the target behavior is.

    • MT – Summary of what I’ve seen so far is:

      • geoemtries are identical,

      • charges are identical (except for ambiguity in TrivalentLonePairSites).

      • Deepdiff of systems shows something with electrostatics, still looking into this

      • Exceptions show differences, I think there’s a good chance that Toolkit had been doing these wrong all along, also the spec doesn’t say what exactly is meant.

  • MT – Would like to schedule meeting with SB to show test results. I think the numerical tests are all good. The value propagation tests should pass but I need to do a bit more work.

    • (JW message MT and SB to schedule)

    • JW – This is a promising PR. I’m surprised that cache invalidation was taking so long. Please leave this open for a little while so I can try to review.

 

 

2022_04_01 Follow up

  • (JW and MT ensure that we have access to AMBER gitlab)

    • General – From the emails exchanged with AMBER devs, it doesn’t seem like they have a very stable interface for vsites. Specifically, we’ll need to BOTH write a prmtop AND make a mdgx script to apply vsites to that prmtop. Also there isn’t a way to evaluate energies/geometries in sander, so we need to evaluate whether mdgx can provide that, or we will be unable to integrate vsite export tests into our CI without a while new pipeline to build pmemd (2-3 dev months/year to maintain).

    • Decision - When MT begins building+testing AMBER vsite export, he should determine early on whether mdgx can evaluate vsite energies/geometries. If it can not, then we need to decide whether to continue on vsites knowing that we must use pmemd to validate vsites, and that can only be done locally (not in CI).

  • PR/Issue clearance

    • JW approved 1129, since he won’t have time to look at it today.

    •  

  • Returning to prioritization

    • Decision - Priority order above in notes is correct

    • Decision – We will NOT start a project page for Interchange imports/exports yet, but we will start collecting cases that we can use as tests for it, and we will spin up a project page for it in the future.

  • MT – I have bandwidth to do additional stuff. Is there anything that needs doing/reviewing?

    • JW – Will want help testing after the smarts-to-networkx-rdkit branch is merged

  • MT – When should I start cherry-picking PRs from master to topology-biopolymer-refactor?

    • JW – Wait until this PR is merged.

  • JW – Large uncertainty about the fraction of PDB files that can be loaded, and the runtime of protein loading + parameter assignment. I hope that the vast majority of load time is in networkx and the vast majority of parameter assignment time is in SMARTS matching, but if it’s instead something under our control we should absolutely focus on that.

Action items

Decisions