2021-02-17 Biopolymer infrastructure Meeting notes

Recap previous meeting

• 2021-02-11 Topology refactor Meeting notes

John API suggestions

• Change one residue into another (OK if this produces a new topology and atom mapping)

• Phosphorylate

• Covalent ligands

• Take a residue, and get a capped molecule with atom mapping

• Take a residue, and get a UNcapped molecule with atom mapping → Make sure that these fragments can make it to an OEMol/RDMol with some basic capabilities.

• Can get further use case info/feedback from Dominic Rufa

• SB – What do we want as the long-term vision for these objects vs. what would Chapin need in the short term? Would we expect major refactor to be done in time for his start?

• DD – What’s expected molecule/system size?

  • JW – up to 1000 residues, 100ks of atoms including water

  • DD – In MDAnalysis, we used topology objects that had slot-based classes. But we had scaling issues when we got near a million atoms. Had a hierarchy of atom/residue/segment mappings, which are now efficient because they’re based on numpy.

• (General) – Numpy/number-based indexing/bookkeeping is more efficient, but it assumes that the system doesn’t change (have atoms added/removed). So a big decision is the extent to which our biopolymers will be mutable. This will determine whether we make a “worldbuilding” guarantee to the users.

  • SB – We almost certainly want to allow mutability

  • JW – Agree

  • SB – My preference is to have an immutable inner data model, and a mutable layer around it that offers safe mutation/copy+replacement of the inner model. (so the rebuilding may or may not happen, but the user won’t know). Anything else makes bookkeeping really hard.

  • MT – This idea doesn’t remove the need to handle lots of complexity. I’m not comfortable with the idea that anything which we don’t explicitly allow isn’t available to users.

    • JW – Agree. Maybe we could offer a “safe” API that makes some guarantees, but also make it possible for people to directly access underlying data and take risks

    • SB – We’ll probably want to start with a small API and take user feedback for new mutators. People will be free to make mutations by making a subclass of our stuff. This could be viewed more as a documentation challenge than an API challenge.

    • JW – We’ll need to have formal cache-invalidation logic in our mutators, so if a new mutator calls three existing mutators, it will able to declare which caches/atom groups it invalidates by combining those three. And if we make that information readily availabe to developers then they can safely implement their own mutators.

    • MT + SB – This may not be a day-0 issue

• SB – We should make sure we have a plan to improve performance of OE and RDKit biopolymers on SMARTS matching.

  • JW – This is on my roadmap. Looking into caching to_rdkit/openeye outputs, reversing SMARTS search, parallelizing SMARTS search, deduplicating parameters.

  • DD – Timing differences between OE and RDKit?

    • JW – I need to send them an example. Right now my only code uses OFFTK, and ti will take some work to disentangle an example from OpenFF toolkit code.

  • SB: see if RDKit can support a single SMARTS-matching call that can take multiple SMARTS