2021-02-18 ParmEd/System Meeting notes

Merge ParmEd into System?

• MS – Overlapping goals are to wind up with “something that is maintained by multiple people that converts between CHARMM, AMBER, GROMACS, OpenMM”

  • JW – “between” or “to”?

• MT – Good to aspire to not have “hero” projects – It’s better to have a community of maintainers, but generally things start off as “hero” projects, and becomes community-maintained once head developer steps down.

  • MS – Our important goal will be to have a sufficient user/developer base for when MT steps down. ParmEd is a good example of what happens a hero leaves and has no replacement.

• MT – JS is probably interested in reducing overhead since he’s now committed to Entos. We’ll want to figure out whether we want to have first-class support for conversions to ParmEd, or export to AMBER directly.

  • MS – Companies are using ParmEd, and it’s worth it to them to have an actively-maintained replacement.

  • MT – If we reach feature-equivalence with ParmEd, would people actually migrate to use our stuff?

  • MS – I can check with other PIs on this, but if JS declares that the System object will be a replacement for ParmEd, we’ll get community buy-in.

• JW – Does ParmEd have energy tests/a complete test suite that would let us declare when it’s been sufficiently “replaced”?

  • MT – No energy tests, but my measure of success would be “can people replace ParmEd in their workflows?”. Complete test replacement isn’t that important, because there’s a signficiant fraction of ParmEd’s API that isn’t used by anyone.

• MS – How much of ParmEd’s code could be frankensteined into the System?

  • MT + JW – Very unsure.

• JW – Maybe we could have JS try using the current System to export something simple like butane and get an idea of our structure that way?

  • Is the API final enough to try this?

    • MT – Probably not. The API will change a few times in the next few months.

    •  

  • Would this be a good use of our time?

• MS – We don’t have to have the complete proposal ready right now. Our next step could be to have a synchronous chat with JS. We can offer a range of options along the continuum of < totally separate - Some copied code - JS directly implements support for stuff in System >

  • MT + JW – Agree. Let’s schedule a chat and understand what his plans/responsibilities are.

• MS – JS implied that work breakdown was going to be “98% jason or 98% matt”. Do we need to address concerns about “hero projects”?

  • MT – This seems like it’s kind of unavoidable that this will be a hero project

  • JW – Consider this an interview for giving JS “keys to the castle”? Basically lay out how disputes over core object model/design decisions will be resolved and give him admin access?

  • MT – It’s not clear to me that these disputes will arise any time soon.

  • MS – I think the point is that, if he’s on board with our big-picture design decisions, he’ll do a good job, and won’t need any restrictions on his access.

• Decision: Michael will organize a meeting with Jason to discuss details in 3 weeks.

Do we want to support residue templates? (/what does OMMXML mean?)

• JW – Were we planning on making residue template files?

  • Here’s an example of a residue template generator:

  • This is functionality to take a molecule and SMIRNOFF force field, and produce an atom type-based force field that works for instances of that single molecule

  • This is something that is only offered by openmmforcefields and ParmEd, and is out of scope for the current System plans, and we’ll want to resolve whether we’re taking ownership of it by accepting Jason’s help.