JC – Is this a parallel way of specifying a FF that runs would be redundant with the SMIRNOFF spec? I’m worried that this could turn into the N+1 format problems.
MH – I have it set up to read this info if an OFFXML is passed in. So if the FF format basically says that this is going to be a harmonic angle, then I’m good with that. But if the information comes from an ambiguous source, I need the user to tell me what the functional form is. Maybe this is overkill right now?
JC – This could make conflict - If you have an AMBER FF, but then you change the bonds to morse, then what do you do with the information? So it becomes complex to think about where different info would get stored/how it would get trransformed..
MH – They’d need to tell us it’s a morse potential at loading-time
JC – I guess this requires us to decide what we want this product to do - Should it be a flexible, general tool for users? Or should it just meet our immediate project requirements?
MH – I’d initially just hoped to cover OpenFF/OMM XML. But it seems like we’ll need to prepare for other FFs as well. So the important thing to do now is to decide the spec/scope for the current work.
JC – Can you provide a concrete example of what we’ll need to support (like, what would users load in and what would they expect to export it to?)
MH – It depends on when the “system” object gets created in the protocol. So I want the imporant FF stuff to be in there somewhere, but I’m not sure where the transformation will happen. It’s not clear where in the process the user would bring in their own FF/other inputs.
JC – Would this be a situation where we store some information that we later feed into an outside typing/parameter assignment engine?
MH – …. There’s no way to tell whether the FF that someone gave us will successfully apply to their input.
DD – One idea we’ve kicked around is, because a protocol has its settings, it has this info hanging off it, and so it would make sense to have a validator that ensures that the inputs (FF+input structure) make sense.
JC – So the object that represents these “level 1” settings would know how/whether it could apply to inputs? So the protocol would know which FF would be used on solvents, which FF on small molecules, which one on proteins/receptors, etc. OMMForcefields can handle some amount of flexibility WRT applying different FFs to different components with some customization.
MH – The protocol will have that info for each edge.
JC – So the FF application machinery will be indepdently implemented in each protocol?
DD – Can probably share a base implementation for the most part.
JC – Does this belong in protocolsettings? To keep things local, you’d think that you’d want a separate object. …
DD – Right now we’re looking at making a pydantic class that does some basic validation, but it doesn’t validate the chemistry/physics. So an edge has a protocol, the protocol has protocolsettings, and that does basic validation.
JC – The idea that we’ll make a universal FF wrapper seems like it would be a useful object outside of its attachment to a protocol.
MH – Then we also need to figure out how Interchange fits into this, since I think we’re talking about something that largely overlaps with its jurisdiction. Because it seems like our shortest path will be contributing to- or wrapping- interchange
RG – Is Interchange limited to OFFXML?
JC – No. Interchange is a general container for parameterized systems.
JC – It seems like this functionality we’re describing could be handled by a series of docker containers. Right now we’re trying to discuss solutions to this using a bunch of new classes that hold external FFs rather than letting the native tools handle those FFs.
RG – I think JC’s right that we’re trying to capture the entire FF, and we’re not doing a great job. There’s two parts: Capturing the entire the FF, and applying the FF, and both of those are hard. So I think this is a bridge too far.
JC – I think we want a nice little API that insulates us from the future. For this case we just need to support OpenFF force fields, which is just a few lines. We can also support GAFF and many of the AMBER FFs using OpenMMForceFields. So that scope should get us to the MVP. Then we can support further things later.