Support for openff-bespokefit

[jmichel80]

It would be desirable to make it easier for users to combine molecules parameterised with openff-bespokefit with other system components. This would lower barriers for benchmarking studies with forcefield parameters optimised for each ligand which should be considered the current SOTA for classical force field FEP studies.

This could be done by wrapping around openff code described here and extending the BioSimSpace.Parameters API

At present interchange may be used to export a parameterised molecule into a file format that is compatible with a Sire parser. Longer term a direct openmm->sire conversion may be more robust.

[bcossins]

+1

[lohedges]

I looked at this but there appears to be a mind boggling amount of options etc. for bespoke fit. I imagine we wouldn't need all of these, but it might limit power users.

What's the issue with a user writing their OpenFF object to AMBER format and loading? Is this lossy, in which case direct conversion would be the only route.

[jmichel80]

Maybe that works. Users seem unsure how to implement this feature themselves. Maybe all that is needed is to document a pipeline showing how to run BFE calculations with bespoke ffs.

[lohedges]

Yes, I think some examples would help. I guess people might be unaware that you can mix things in BioSimSpace, i.e. you don't need everything to be in one topology file: you can create multiple molecules in different ways, then add them together.

[bcossins]

That might be one of the reasons to wrap it. Cos it is so complex to work it out. You could parameterise any of the bits of your system outside of BSS but it is convenient to wrap simplified versions.

…

On Sun, Sep 29, 2024, 14:24 Lester Hedges ***@***.***> wrote: Yes, I think some examples would help. I guess people might be unaware that you can mix things in BioSimSpace, i.e. you don't need everything to be in one topology file: you can create multiple molecules in different ways, then add them together. — Reply to this email directly, view it on GitHub <#262 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMPE3E5I6DD3HX7577DGAZTZY75PXAVCNFSM6AAAAABPBP2VO2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBRGM2TMNRQGY> . You are receiving this because you commented.Message ID: ***@***.***>

[lohedges]

I agree with that, my issue was more that there didn't (yet) appear to be a "standard" protocol to follow, so it wasn't clear what options to expose and what generally appropriate settings would be.

[bcossins]

Might be able to come up with a default one soon. Will come back on that.

…

On Sun, Sep 29, 2024, 16:20 Lester Hedges ***@***.***> wrote: I agree with that, my issue was more that there didn't (yet) appear to be a "standard" protocol to follow, so it wasn't clear what options to expose and what generally appropriate settings would be. — Reply to this email directly, view it on GitHub <#262 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMPE3EZRWOJM72KWVSQB2TLZZALEVAVCNFSM6AAAAABPBP2VO2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBRGM4TMMZZGA> . You are receiving this because you commented.Message ID: ***@***.***>

[lohedges]

Great. I haven't looked for quite a while so it might be that things are more standardised now.

[bcossins]

Not sure about that but there is a fast charge aware NNP which makes it easier as things run faster

…

On Sun, Sep 29, 2024, 16:43 Lester Hedges ***@***.***> wrote: Great. I haven't looked for quite a while so it might be that things are more standardised now. — Reply to this email directly, view it on GitHub <#262 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMPE3EZIDVDEZNMPYQROB43ZZANZ5AVCNFSM6AAAAABPBP2VO2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBRGQYDGNBWGQ> . You are receiving this because you commented.Message ID: ***@***.***>