MT JW Great job on the demo! Any followups needed? Only thing I can think of might be install instructions in the README and pinning some key versions in env yaml for longevity. MT – Nothing needed from you right now. Talked with ZB yesterday, we’re going to put joint demo in the back seat for a bit. Plan is to not actively maintain or instigate a monthly meeting on this or anything. But every month, possibly in the OMSF staff meeting, I’ll listed in on the project updates and think about whether new things intersect with the demo. This wouldn’t be my responsibility, but I’d think through it a bit and make some noise if something seems breaking. But it’s nobody responsibility to maintain or own it. JW – Great. I’d like the projects to explicitly agree on expectations here, otherwise it could become unmonitored work or unclear ownership. So if this becomes a nontrivial amount of work (or you just don’t want to touch it for any reason) I’d recommend you NOT fix things and we instead first get buy-in from everyone. JW – To memorialize the version that was presented last week, maybe we pin some stuff in the env yaml and make a release with the date it was presented? MT – Good idea, will do today.
Remind me why units 0.3.1 with python 3.10 was necessary? Was it just to handle one build in the OpenFE build matrix, or is there a part of their stack that only works with py3.10? I think I have your USB-C charger (black with a mac-sized brick at the wall plug, left in room 14 at essex). Want it back? Click had a breaking change (--help output is now stderr instead of stdout), which breaks a bespokefit test that checks the help output. Might make a release to make deployment tests happy, or a build to downpin click. Batted around ideas a bit with IA about what OpenFE would need to use Interchange, which in turn would add support for SMIRNOFF protein FFs in OpenFE. A lot of it is just around replacing OMMFFs' SystemGenerator. I told him that making a new thing that matches SystemGenerator is all cases is our of bounds and he agreed. I’m speaking with him more about this next week. Big questions we’ll discuss are around detailed behavior and ownership. MT – We should give this thing a name since it’s been talked about so much. I have the same assessment, will be fun technically and fairly straightforward, but the behavior definition/organizational ownership will be the hard part. MT – Chokepoint of their usage is https://github.com/OpenFreeEnergy/openfe/blob/d21f7360e125a286ca9ce501d44ebd92313bc740/openfe/protocols/openmm_utils/system_creation.py#L120-L128 OpenFE has a design where they define things in FF settings that we would put in the FF itself OpenFE has a concept of a small molecule FF as opposed to a general FF, which we don’t I don’t know where in args the protein FF is selected (maybe in settings?) Solvation is handled using OpenMM Modeller, which will limit the scope of this tool since it won’t handle PTMs. GAFF stuff will need consideration… SystemGenerator is based on OMM objects - takes a list FFs and Topology. This is a big incongruity between our worlds. JW – Each chemical component could be passed in as a tuple of (component, [ffs])? MT – Pretty messy but might end up being the best choice. Would be simpler if only SMIRNOFF FFs were supported. JW – They’ll need some way of using atom typed FFs for eg. lipids. So the openmm/openmmforcefields classes would be used deep down for the forseeable future. MT – Basically in agreement. So the templategenerators would continue being necessary for GAFF support and maybe other small mol FFs.
MT – First hurdles will be Solvation breadth of FF support
MT – Those are easy code-wise, but the big hurdles will be around getting behavior/science set up correctly. JW – I’m very open to expanding our scope (eg. wrapping OpenMM solvation) if it helps us get SMIRNOFF protein support in openfe
|