2022-04-11 Core Developers meeting notes

General updates

• JW – I’ll be working half days (mornings) today and tomorrow, full time after that

• SB + DN + JW will need to leave for gov board meeting in 30 minutes.

Individual updates

• SB

  • Put in a new proposed change into SMIRNOFF spec, adding details to vsite exclusions. Merged it this morning.

  • Rewrote vsite handler within toolkit, to fix observed bugs and incorporate new exclusion policy per spec update above. opened PR.

    • JW – I’ll run the assignment tests on this branch after this meeting.

  • Hoping to start vsite fits+tests, but need a more bug-free implementation before this can really move forward.

• DN

  • Wanted to ask folks to help build work breakdown structures (WBSes). These let us evaluate whether we’re achieving what we need to make products/finish projects. But doing this right involves talking directly with people who have all the details. This will be a way to consolidate progress/plans so that the PIs and board can just look at a single place to understand progress.

  • JW – DN also added the “How to cite” page to the website, will hopefully get the right people credited.

    • DN – I’ll try making the bibtex functionality soon too

    • JW – When JMitchell is done with his current high-priority work, I could have him take a look at ading the bibtex (probably in a few weeks, I’ll let you know)

• JW

  • Figuring out “medium compute” policy - Planning to use UCI

  • Restarted work on biopolymer refactor.

    • Need to think carefully about residue info in roundtrips, sicne eg in RDKit residues seem to ALWAYS have a number assigned.

    • MDL aromaticity model doesn’t think TRP and HIS sidechains are totally aromatic

      • CC – Will this affect parameter assignment negatively?

      • JW – I don’t think it would be worse than currently - The same assignment machinery is used for fitting

      • CC – Where could this become a problem?

        • JW – Molecule representation and maybe? PTMs?

        • SB – Probably not PTMs, like a post-translationally modified TRP should be handled just fine. Also worth noting that we haven’t his any critical issues with these sorts of rings in small molecules.

  • SB – Currently the Molecule class exposes a getter and setter for aromaticity. These aren’t actually meaningful. Could it be removed in 0.11?

    • JW – The current functionality is really bad, I’d love to pull it out if we had more time to make sure that nothing else broke. But at this point I think we just need to leave it in.

• CC

  • Working to set up sample calculations for peptides and disordered proteins to estimate NMR observables on UCSD resources

    • planning to run benchmarks on multiple GPUs to get estimates on how long it will take each system type to run

    • Short peptide, folded protein, disordered protein simulations, mostly on 1080Ti, 3090, and Titan X

• MT

  • Running regression tests on UCI resources; found and fixed 2 bugs

    • if you had set a per-improper idivf; this is not really done anywhere in the ecosystem

    • tests are passing, putting together tests to cover these cases

    • single molecule tests doing well, having trouble getting consistent values from AM1BCC to 6 sigfigs precision

    • have compute resources, scripts to show that 6 sigfigs isn’t going to be possible, but that distribution produced is the same over time

  • SciPy talk accepted, planning to go and present

    • Owen is also going to SciPy, presenting a poster

    • Aiming to give overview of our infrastructure, exposure to a broader community

  • Will be a 0.10 release of the toolkit, might feature ELF10 difference from previous releases, as in it will actually use ELF10 if OpenEye is installed

• DD

  • Offline 4/2 - 4/6, so plugging back in on all fronts.

  • Protein-Ligand Benchmarks

    1. worked with Richard Gowers and OpenFE to establish gufe, which features the shared data model components for both openfe and fah-alchemy

    2. working to finish initial implementations of edges and whole network: https://github.com/OpenFreeEnergy/gufe/pull/13

    3. working closely with OpenFE, and building on current approach

  • QCArchive

    1. set up qca-dataset-submission-next-test

       • using this repo to make appropriate changes to openff-qcsubmit, automation to test out behavior of new QCArchive server test instance

       • worked with Ben on Friday through initial set of errors from QCSubmit

    2. error cycling looks like it's got too many errors to restart for memory on the worker; will get this past the hump today with a manual kick

  • Industry Benchmarks

    1. worked with Lorenzo late last week through manuscript figure issues

• PB

  • Looked back at the WBO work done after Sage release with the ortho-unsubstituted-biphenyls and tried updating some of the WBO meeting notes from last year, made a group meeting presentation on the status. Will work a bit more to document well on confluence.

  • Some fitting experiments with new alkane parameter set from Trevor and benchmarking. Also, had some good discussions with TG

  • Need to work on Sage paper, blog post and FFR meeting this week.

Vsites working session

• Allowed Match values?

  • SB – If coordinates of a vsite don’t depend on the order of the atoms (except for the identity of the main atom), then then once and all_permutations mean the same thing. But for something like divalentlonepair, if it’s in-plane, then it should only occur once, but if it’s out of plane then it should apply multiple times.

  • Bondcharge

    • all_permutations

  • MonovalentLonePair

    • all_permutations

  • DivalentLonePair

    • once (also requires OOP angle is 0)/all_permutations

  • TrivalentLonePair

    • once

  • Disallow match keyword for everything except divalentlonepair?

• Current plans:

  • Assume restrictions above as an implementation detail (don’t worry about updating spec)

• Possible spec changes (We will NOT do this now)

  • Restrict match values to those above

  • Add description of match

  • Explain name thing

  • TrivalentLonePair → redefine to GROMACS 4fdn

• Functionality testing

• PR processing

  • SB – “All geometry defining atoms are now “orientation atoms”, and one special orientation atom is the parent atom”

  • SB – VSites of different types can override

    • JW – That’s new to me, I’ll think about if this would expose any edge cases (for example, overwriting a divalentlonepair with once vs. all permutations)

  • SB – A virtualPARTICLE has an equal number of orientation atoms to the SMARTS, but a virtualSITE (like two monovalents on a carbonyl) would have FOUR orientation atoms. So I’m removing the atoms property of VSites from the API, since they’ll be confusing. Users can still access the

  •  

  • Remove vsites from molecule and topology altogether?

    • JW - Removes (specification)/(contract with users) about final topology particle ordering

    • JW – MT, how is vsite/vparticle indexing handled in interchange?

    • MT – Referring to A) guaranteeing the index of vparticles in all outputs, or b) be in control of possibly-different indexing in exports to different engines.

    • …

    • JW – A user exports a parameterized topology to AMBER format. Particle 1000 is a virtual particle. How does the user know WHICH virtual particle this is? (parent atom, parameters, name?)

      • MT + SB – VSites are clearly in post-parameterization land. They shouldn’t be on pre-parameterization

    • SB – Split user case vsites in two use cases?

      • How users inspect vsites in interchange

      • Inspecting vsites after they’ve been exported to engine X

        • SB – Importantly, do vsites get written out in coordinate files in other engines?

          • MT – (moderate confidence) In GROMACS, I think that vsites DO exist in topology files (NOT gro files).

          • SB – I wonder if if that means that our hands our tied - We would have no way of knowing which particle index the vsites will have. OpenMM is a bit of an outlier in that it exposes programmatic to vsites, which is kinda an internal field, and I wouldn’t expect other engines to expose anything like that.

      • SB – Could we make the statement “we can not guarantee any particular ordering of vsites in an exported representation of a post-parameterized topology, mainly becuase we can’t guarantee that external engines will support it. However we can enforce that, if Interchange has control over this, there’s a preferred way that we’ll export it”

        • For cases where Interchange DOES know the output order, Interchange should offer a reasonable API to inspect that ordering (like, look up vsites based on an atom index, look up parent/orientation atom based on vsite ID/index/name/slot)

        • SB – Unqiue Vsite IDs could be (name, parent atom index)--> (one vparticle) or (vsite parameter)-->(multiple particles)

        • JW – I think one big principle should be that an Interchange export could make a “Record” object, indicating how the components in the Interchange map to components in the output.

        • SB – I think that should be more general than just vsites - Like, energy components could map to different forces during the export, and that would be super helpful to have recorded.

        • MT – Agree, that would be helpful.

        • (We’ll come back to this at a later stage, today’s meeting will focus on this PR specifically)

      • JW – I approve removal of the virtualsite and virtualparticle classes from the Molecule and Topology API in 0.11.0

        • SB – Agree. But leave them in 0.10.X. MT, could I open a PR to port the code to Interchange?

        •  

  • JW

    • Update graphics to show thing that are in/out of plane when there are multiple vsites?

      • SB – Files are SVG, which you should be able to import and edit. Files are made in Gravit - I can send them to you.