| |
---|
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:
|
| 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 | |
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 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? MT – When should I start cherry-picking PRs from master to topology-biopolymer-refactor ? 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.
|