Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Participants

...

Discussion topics

Item

Notes

General updates

  • JW – Sprint planning moved to every other wednesday

  • JW – OpenFE is opting not to be an approver for F@H project

Roundtable updates

  • DN

    • Working on work breakdown structure. It’s quite complex, OpenFF already has a lot of stuff in progress, and figuring out the structure of it is pretty hard. Working with OpenFE I’m optimistic that this will be more straightforward since we can begin with this structure.

  • CC

    • I’m working in MGilson’s lab at UCSD, focusing on making the biopolymer FF

    • Made a poster for BPS conference, I’m really happy with how it turned out. Thanks MT+PB+JW.

    • I’ve been submitting qc datasets, 22/26 amino acid torsiondrives have finished, the last few are just waiting on a handful of optimization. To ensure we’re using our compute well, I’ll submit scans that will scan sidechain angles.

      • JW – In the long term, will it be possible/useful to pull down incomplete torsiondrives?

      • CC – I think so, and I’d expect that we may see this with larger/higher dimensional torsiondrive sets.

    • Working on benchmarking review paper. Currently trying to make it read in the same “voice”, since it was contributed by several different authors.

    • DN – Did you get all the figures you wanted for the poster?

      • CC – Yes, I did. I still need to go back and ensure that all the figures made it into the shared figure folder.

      • CC – Preferred file formats for figures?

        • JW – Original google drawing if possible, then svg, then ???

      • DN – Not sure if it’s a good idea to keep figures in an editable form. It may make it possible to not credit the original author or to unintentionally change the meaning of the figure

        • CC – I think it’s probably a good idea to keep it in an editable format. But not for data-driven figures.

        • JW – Agree

  • MT

    • I’m the “second Jeff” at OpenFF, more on the technical side than the meetings side. Currently working in Michael Shirts' group at U Colorado Boulder, but will be an OMSF employee soon

    • Most of my effort last week was on interchange regression tests (in preparation for tying it into the OpenFF toolkit)

    • Also worked a lot on wrangling issues and PRs in the OpenFF toolkit and elsewhere in the ecosystem.

    • I was supposed to get a set of molecules for wiberg bond order interpolation test cases, but I didn’t before SBoothroyd went on vacation, so I took some examples from another repo and things look good for torsions. Still need to test for bonds.

    • Worked on virtualsite test cases as well. JW will provide me the final test set for molecules+force fields to test for these. But initial tests/work is moving forward, expecting this to be quite complex because the toolkit code is complex.

      • JW – Sorry I didn’t get the test cases to you last week, this is on my mind.

    • Planning to run a feasibility study to ensure that our supported vsite styles can be consistently exported to OpenMM, GROMACS, and AMBER.

    • Lots of activity in openFF toolkit, coordinating all the moving pieces for the 0.11.0 release

    • DN – Do you see Interchange as part of the delivery of Rosemary?

      • MT – Yes, but implicitly so. So it’s part of delivering a new version of the OpenFF toolkit. So I’d like interchange to be of the code path where we make OpenMM systems. For CREATING the Rosemary force field, I don’t know. The forcefield fitting team may choose to use it, depending on its status/readiness during the FF fitting process.

      • CC – I agree with MT - I’d be interested if Interchange is in a state where it can be used for benchmarking the FF release. But it will depend on the features/maturity of interchange at that time.

    • MT – Should I be setting aside bandwidth to help with biopolymer benchmarking calculations? Or adding features to interchange to support this?

      • JW – I think the implementation seems well specced out, and CC’s initial prototype is likely to be quick and successful. Though I’m going to keep some of our time set aside this summer to help support anything that CC needs in case there are unexpected complexities.

      • CC – That agrees with my view. Some of the things, like NOE couplings, could be a lot more sophisticated, but I don’t plan on those being required for the delivery of the first version of Rosemary

      • MT – Sounds good, mostly wanted to make sure that I have bandwidth in case interchange features/changes are expected. Would anticipate issues around things like residue info, etc.

  • DD

    • Protein-ligand benchmarks on Folding@Home

      • Met with OpenFE folks with Jeff and Diego; became clear that we have more to gain from them on this project than they do from us, so planning to engage more directly with them as a consumer of the libraries they are building; we want to use their data models and tools where possible

    • QCArchive

      • assisted Ben on remaining PRs for QCFractal release

      • worked with him on right-sizing new hardware for the QCArchive server at MolSSI, storage configurations

      • working with Pavan to reduce size of qca-dataset-submission repo via git-lfs; aiming to get out another attempt this week

    • CLI tooling

      • discussed approach with industry benchmarking group for CLI development later this year, starting with openff-gopt; still preliminary, no formal project spun up yet

      • CC – More details on this?

        • DD – This came out of two discussions at the openff benchmarking call (every other wednesday). Basically, in season 1, we agreed that we’d do geometry optimizations, comparing openff, GAFF, schrodinger, etc. And we built this workflow with a CLI frontend, with a very narrow scope that basically makes it so they only make sense in the context of the benchmarking workflow (though industry folks are trying to use components elsewhere). Since benchmarking season 1 was such a positive effort, we’re looking into doing a season 2 later this year, with a more advanced/relevant benchmarking workflow. And instead of having the tools be hyper purpose-build just for the benchmarking workflow, we’d like to design them to be more broadly usable, and form the basis of a more general CLI. This sort of CLI frontend will help us get our tools incorporated into industry workflows.

        • CC – I see, so the goal is to expand the tooling offered for the industry benchmarks, and make it a more broadly useful CLI.

        • JW – And to clarify, the overall CLI effort isn’t immediately underway, this current push is to polish up openff-gopt, which is nearly done, and get it into users hands.

  • PB

    • I’m a postdoc with OpenFF, working from David Mobley’s lab. I generally work on FF improvements and QM dataset generation.

    • Mostly improper parameter fitting experiments.

    • Meetings and some qca work. (thanks DD for checking on the git LFS PR)

      • DD – Thanks for trying things out for the first time. I’m going to try a different approach and ask for your thoughts.

  • JW

    • Worked on OE/OMM/RDKit interface for residue/hierarchy info, making tests.

    • Working with DN to prepare for all-hands presentation

      • DN – People frequently have a misconception that OpenFF has one “project”, with subprojects and submodules, and I’m coming to see that this really isn’t just one big project, but it’s several smaller projects that are related, and their relationships are complex.

    • Announced OpenFF TK biopolymer release delay

    • Prepping for bespokefit testing at Genentech. I’m going to see if I can coordinate Josh Mitchell working with him to get started on this.

      • DD – BSwope is great to work with, this should go well.

  • IA

    • I’m an RSE in Phil Biggin’s group at Oxford. I’m split 50% with openFE and MDAnalysis.

    • We’re currently building a minimal tutorial for doing relative binding free energy calculations using OpenFE tooling. Basing it off T4 lysozyme. Because we’re using OpenMM as our engine, we are using hybrid topologies. In picking a tool/standardizing on a solution, we’re looking at something like perses, but we’re curious how you do hybrid topologies.

      • DD – Evaluator may just be HFE and solvation free enrgy stuff now

      • JW – I think it’s more generalizable

      • PB – MPitman has a pmx workflow that’s being used for RBFE calcs

      • IA – We’re not doing GROMACS this year, choosing to restrict complexities

    • IA – Are you planning to do absolute binding FE, or also relative?

      • DD – We’re looking to ingest the openforcefield/protein-ligand-benchmarks repo. So this is set up for relative binding free energies.

      • IA – Is there a workflow for doing it in OpenMM?

      • DD – No, we’ve just been using PMX

      • JW – There’s a chance that SBoothroyd/the FF team has a RBFE solution for OpenMM that we’re not aware of just now, it would be good to confirm with him directly when he’s back from vacation.

    • JW – We’re looking at storing non-chemical topologies, and possibly also applying parameters (though the latter is unlikely). This ins’t slated for the initial biopolymer toolkit release but we’ll make a callf or feedback later this year

  • DS

    • I’ve been working with OpenFE for two weeks. Basically getting repose and basic stuff set up for our simulations. Not much to report on now, happy to take questions.

  • RG

    • I’m the technical lead of OpenFE. Currently planning the sprint for this week, trying to get deliverables in line for March deadline.

    • Doing lots of work on planning networks that we’ll be calculating. A lot of work has been dealing with sweeping changes in the LOMAP codebase recently, where the API changes but the tests didn’t come along.

    • JW – Is there a major use case you’re looking at addressing initially?

      • RG – Take PDB and multiple docked ligands as input, and return final energies for each.

    • RG – looking at how to handle differnt cheminformatics backends. Planning on providing a few built-in things like LOMAP, and having a plugin interface for people who want particular workflows/cheminformatics backends

      • JW – Good call.

      • IA – Biggest consumer of oechem stuff right now is perses

Action items

  •  

Decisions