Item | Presenter | Notes |
|---|
Current development status, blockers, next priorities | David Dotson | | Github link macro |
|---|
| link | https://github.com/OpenFreeEnergy/gufe/pull/13 |
|---|
|
|
Backlog population, system of record for coordinating effort on work units (issues, PRs) | Diego Nolasco (Deactivated) | DN – I like working with work breakdown structures (WBSes). This will help keep things in scope and prevent late items from creeping on to the backlog. Each item would be described as “must” “could” “should” or “want/won’t” DD and DN will meet to make a WBS, send JW an optional invite
|
Needs for protein representation | Richard Gowers | Needs for gufe::ProteinComponent protein representation, identify gaps in using OpenFF Toolkit Molecule Current status of reading in PDB files Storage of “protein” contents within Molecule JW RG: most interested in protein representation, not necessarily force field application at this time; do want to know what changes are coming JC: can you describe what you’re trying to accomplish first? RG: would like to ultimately have the OpenFF Molecule as the molecular representation; working on the path to getting there from a PDB JC: what is the state of reading in protein details from a PDB, in particular getting chemical information out of it (nontrivial)? JW: at this time, working to preserve residue and chain info from PDB; need to do three things JW: zoom out though; current release can’t read protein PDBs at all RG: does OpenFF Molecules data structure change significantly? JC: having users for this functionality can be useful positive pressure JW: don’t want to cause friction for OpenFE; is this a problem? RG: one way we can use current stable release is to patch in PDB perception code in our ProteinComponent, then use current stable version of toolkit; basically hanging this information on the side until we have the new release? JW: problem is you’ll have a mol where you don’t know bond orders, formal charges JC: wouldn’t it make sense to invest the effort to fix issues in the toolkit itself? RG: sure if it’s pretty close to 90% there, we can go that route MH: agree, if it’s pretty close then good approach JW: agree, and think it would be great to have users banging on it RG: in terms of exporters, just need to be able to export to an OpenMM Topology; status? need to be able to export with an Amber FF for a start JW: yes can do that already, so aiming to be able to do that
IA: how likely would OpenFF 0.11.0 be in the next month, 2 months? JW: aiming for alpha release in next month having this project as a consumer helps justify higher prioritization, faster release aiming by May 12; does this work? MH: can also commit patches where we see issues directly, too, if that’s okay
JW: DN, prioritizing effort to biopolymer PR, since this is blocking for this project JC: is there basic documentation for getting started with the branch?
|
protein-ligand-benchmark advancement, LiveCOMS revision
| David Dotson | DD – RG, IA, as I understand it, OpenFE is looking to coordinate activities on the protein-ligand-benchmark repo. | Github link macro |
|---|
| link | https://github.com/openforcefield/protein-ligand-benchmark |
|---|
| extended | false |
|---|
|
JC – This repo needs cleanup. I’ve opened issues about the specific aspects that need work. Contributors will be credited in future publications. JW – In theory this repo is owned by the Science team, but we are low on personnel resources there, so doesn’t explicitly have an owner JC: the LiveCOMS repo (https://github.com/openforcefield/FE-Benchmarks-Best-Practices) RG: OpenFE can take over maintenance (part of remit from board) want to coordinate with existing players where possible DD: intention was to have Lorenzo heavily involved; will work with JW to get LD what he needs to engage, including discussion with GT to get at least 80% of his time
IA https://docs.google.com/presentation/d/1qvE8qgWIr33BY-jA0X4DEkflLHSvdYPH/edit#slide=id.p1 (not mentioned in slides) – Needs reference to paper JC – Could explicitly specify requirements for inclusion (like, metals? and other stuff) IA: taking less of a gromacs-first approach might be better; e.g. just switching to PDB-oriented approach IA: consistency issues RG: in terms of representation of the protein, would it make more sense to serialize an OpenFF Molecule? PDB has a lot of ambiguity IA: yes, that would make sense JW: so idea is that you would load an OpenFF Molecule from a serialized representation RG: wouldn’t be hard to crank out a stable format JC: would be a worthwhile use of engineering effort JW: with the upcoming release we’re gaining residue fields and losing virtualsites frankly way we’re doing aromaticity doesn’t make sense, so that may change in a future release one-time upconverters would be possible to read old serialized versions
MH: do want to version the output format; that way upconverting is possible IA: I realize we want to move away from PDBs, but ideally going forward we don’t have to change our representation in this repo RG: if you start from PDB, changes to the perception of the PDB would impact results JC: in the short term need “well-prepared” PDBs with explicit protonation, missing residues built in, at least conformant with PDB spec, etc.; too early for standardization of serialized format for Toolkit Molecule given data model is changing so much currently RG – Maybe mmcif? JC – Short-term, I could use OE Spruce to clean up many structures. But some structures still aren’t going to be acceptable because of their resolution and other factors JC – It’d be great if IA could open issues on the repo for these discrete points:
|
Additional topics | | JC: would like to think about using the objects in gufe, from perses end could create Protocols in that can be tossed DD – So perhaps Perses could use gufe objects in constructing protocols.
|