2024-03-13 Thompson/Wagner Check-in meeting notes

General updates

• JW –

  • Cresset vsites thing - We’ve scheduled a meeting with them in 7 days to discuss next steps. We won’t change anything until we talk to them. You’re welcome to join but I assume you’d prefer not to.

    • MT – Sounds good. Would like plans for them to be deliberate+clear (like, we shouldn’t implement something that isn’t in the spec)

    • JW – I’m thinking of offering them:

      • Use divalentlonepair soon, and assume risks

        • MT – This will be a problem because we won’t be able to take it back in the future.

      • We’ll invent a new type of trivalent vsite for planar cases

        • MT – This would be my preferred outcome. Timescale would be at least multiple weeks though, and would require a toolkit and interchange release at the end.

      • We can give you a plugin but you’ll have to maintain

        • MT – I don’t think this is a good idea - I’m working on a issue right now that might mean that plugin vsites don’t work/are likely going to change a lot. And this would be high friction in terms of coordination.

        • JW – Ok, I won’t offer that, that sounds like a bad outcome.

        • …

        • JW – Though it’s possible that they say “we want to be able to experiment with arbitrary vsites”. What would our technical options look like there?

        • MT – saying “no” puts them in the same place they are now, which seems to be workable, presumably by hacking around on OMM System objects. Another option is something that JHorton implemented in a QUBEKit class, which might be excessively openmm-specific for anything we could bring back in.

        • JW – If they want unbounded experimentation, I’ll plan to tell them to keep hacking directly on OMM systems until they find some types that work and are worth the effort to make a spec proposal, and then we can implement that.

  • Thoughts on PDB reading thing? I’m planning on saying “explicit CONECT only, explicit Hs only, no radicals”

    • MT – This is near the edge of my expertise. I have to call into quesiton the utility of this:

      • If we want an add-on that lets PE do some new things with his dataset, that could be possible. It’s not clear which dataset PE has in mind here. IIUC, the goal is to better read PDBs that don’t contain full chemical info. The proposed restrictions sound like they’d close that gap well and sound sane. But these are in direct conflict with what makes it useful (we can say “you need CONECT records” but that rules out a lot of use cases).

      • JW – The big impact here is this would remove the need to use the unique_molecules in Topology.from_pdb.

      • MT – Do we also need ot know aromaticity?

      • JW – Aromaticity is derived from (formal charges, bond orders), and I think it’s clunky to go the other way. More info here. https://depth-first.com/articles/2021/07/14/the-trouble-with-huckel/

      • …

      • MT – Would be in favor of implementing something real in the next few weeks. Your proposed restrictions seem solid. This goes most/all of the way toward actually being able to load ligands from PDB. Maybe add “must have correct CONECT records and implementation should use those CONECTS and not distances”. RDKit implementation seems unavoidably distance-based, but maybe a reimplementation of the MDA thing could work.

  • QCSubmit stuff

    • JW will take this

  • Next bespoke session?

    • Friday

  • Update on OpenFE/SFE stuff?

    • MT – A few weeks ago, RG sent me a script that runs SFEs. I tried updating it and it ran a bit eventually crashed. RG reported being too busy to meet in the next two weeks. I could try to wade in and figure it out but there’s a completely unknown ETA on that.

Trello

Tutorial review

Project Plan: Common workflow conversion via Interchange