2022-09-23 Thompson/Wagner Check-in meeting notes

Participants

  • @Matt Thompson

  • @Jeffrey Wagner

Discussion topics

Item

Notes

Item

Notes

Followup worksho goals/gaining industry engagement

CCG/espaloma meeting

  • JW – CCG is a company like Openeye. MOE is their equivalent to openeye-toolkits. I don’t know what Vir is but it’s probably a person. (later: MT: Vir Biotechnology is a company)

  • JW – What I’d really like from the meeting is an estimate for how expensive it would be to interoperate with MOE/CCG software (as in, “have OpenFF parameterize molecules which MOE then does something with”) -

    • Is it something that we’ll get for free by following our current roadmap?

    • Are there other interoperation pathways that they’re interested in?

    • JChodera will probably come up with plans around espaloma - We can’t commit to doing work to make those interoperate, but if that’s discussed it would be good to try and ballpark an estimate as well so JW can present it to the governing board (“we might get $50k from CCG, but it would cost us 4 months of engineer time” is probably a losing proposition)

      • MT – Espaloma can output to OpenMM systems and has been able to for a while now. Some question as to whether we can gobble up all the details.

      • MT – If asked for closer integration (like an EspalomaParameterHandler or EspalomaPotentialHandler…. or likely designs that are substantially different than that) I’d estimate support cost as being fairly high, given the poor maintenance track record of software like openmmforcefields and yank.

    •  

Workshop prep

  • JW – Could you populate the fields for materials and attendees on the workshop page at least 24 hours in advance, and ensure that there’s a way to run everything via binder?

    • MT – Will do

  • MT – potential workshop material

    • Will run through notebooks (construction, units, and export) in this PR

      • JW – These are great - Would be good to also have an “inspecting assigned parameters” bit

      • MT – I’d like to keep from encouraging people to change physics

      • JW – Might be best then to just show “hey, look at this angle parameter, here’s its k, here’s its id , moving on…” and let them mess with setters on their own.

    • Will show vsite example (using toolkit vsite offxml to avoid adding more confusion around this)

    • Will show protein-ligand example (uses amber FF port)

    • from_openmm protein example?

    • OpenMMForceFields integration?

    • Jumping back and forth between formats with things like modeller.add_solvent?

      • JW – Would probably be a big cognitive load for little gain - we can just point people to toolkit showcase for this

    • Foyer example? (wouldn’t like to do this)

    • Driver framework walkthrough (high-level function that executes single point energy operations in various engines)

      • JW – I’d leave this out or just briefly mention it

      • MT – I’d just mention it for ~2 minutes.

  • JW – In deciding on what to show, and for how long, the big picture goals are:

    • Inform people of what is possible using Interchange

    • Ensure that they can run it on their computers

    • Get them running code that will teach them how stuff works, and that they can modify to eat their own inputs

    • Support their exploration

    • So my idea lineup would be:

      • Intro: Talking about the “big picture” of what interchange does - maybe just covering the mermaid diagram

      • Basics of how to talk to interchange (notebooks in your PR) (including driver interface)

      • The protein-ligand example (have a nod to bespokefit workshop - “this is one of the primary pathways to set up a protein-ligand simulation using bespokefit output. You should attend that workshop in the coming weeks to see how to do this.”)

      • (maybe) vsite teaser (JW – I’d avoid too much depth on this, could take a lot of headspace/focus from their experimentation)

      • The from_openmm teaser (GAFF via openmmforcefields? Disclaim that this is NOT the amber implementation and uses naive AM1BCC)

      • Common debugging/what do these errors mean? (things like atom name handling, how to resolve errors in component combination, etc)

      • Try it on your own files, and we’re here to help!

Action items

@Matt Thompson
Add in more big picture stuff in preamble
What Interchange does, what it doesn’t do
Specify system preparation tasks that are in and out of its domain
What is expects as inputs, what it doesn’t expect

Decisions