MT – Looking for guidance on what to do with ML interfaces in general/SMIRNOFFEE specifically. I’m not sure what we’re after/there isn’t a firm spec for what we want. Also it seems like a lot of what I’d build is… already built in smirnoffee. There’s also a lot of details that will depend on the fitting team’s requirements/specific implementation.
MT – Some concrete directions are:
SB – I originally intended smirnoffee to
be a mechanism to give you some feedback / show an example of what sorts of vectorized outputs are needed.
quickly answer is “what happens if I tweak the FF in this way?”, which is cumbersome in openmm systems.
look into what a FB replacement would look like.
SB – Looks like JC will be pushing for espaloma integration. Also making my own library to fit to internal coordinates/hessians, and generally I’m making a modular family of libaries that can plug into calculation of a larger loss function. So hopefully these can guide a bit the direction for vectorized/ML output.
MT – I’m curious about how/whether a lack of features in Interchange is blocking any of your objectives.
SB – Interchange currently supports the science I want to do, and the needs of other people in the consortium. Though if we commit to the espaloma route, then we would need to do some extra engineering to interface with an intermediate output from espaloma (we could interface with its fully vectorized representation/output, but we will need to do some extra work to deal with richer objects).
SB – Re: vectorization - there may be some slight changes needed to plug cleanly into my libraries/smirnoffee.
MT – Are there concrete things that I can make now that would help?
SB – I’m not sure that there’s anything hugely valuable. I could spin some work off to you (eg my pytorch reimplementation of some geomeTRIC functionality). Could also spin off some work on the recharge vsite interface.
eg line 55-77 in
Other changes needed in charges/vsites and optimize/optimize
In recharge, we have continuously differentiable ways to get out vsite geometry parameters - These are somewhat subtle because the toolkit default output representation isn’t suitable for backpropagation.