openforcefield / openff-toolkit

The Open Forcefield Toolkit provides implementations of the SMIRNOFF format, parameterization engine, and other tools. Documentation available at http://open-forcefield-toolkit.readthedocs.io
http://openforcefield.org
MIT License
303 stars 89 forks source link

Multi-conformer WBO Support #792

Open SimonBoothroyd opened 3 years ago

SimonBoothroyd commented 3 years ago

Is your feature request related to a problem? Please describe.

Currently both the AT and OE backends only use a single conformer to compute the Wiberg bond orders (WBOs). Should multiple conformers be used to compute the WBOs, and if so, how should the WBOs of multiple conformers be pooled / averaged.

This is a question which has been mentioned in several code comments and PR comments, but I think it's worth having a single issue to track this.

Given that Sage is slated to be the first OpenFF to include WBO interpolated parameters it is probably good to start revisiting this and thinking what the 'recommended approach' should be (both for fitting and for the end user).

Related comments this PR:

@j-wags

I think conformer averaging would be a nice thing to do. But, like ELF10, it's not clear that there's a single common-sense way to do it. So, I'd like to leave conformer averaging algorithms as something for the community to experiment with. Once someone wants to try it, they can invent a new keyword for bond_order_model, and implement support for it in a ToolkitWrapper.

@davidlmobley:

Definitely seems like a thing to do separately/unresolved science.

Describe the solution you'd like

Some possible solutions would be to:

  1. Just use a single conformer (current default). This would either be the first conformer provided by a user if multiple conformers are passed to use_conformers, or a single conformer generated in-place in assign_partial_charges. This would likely be the 'most' conformer dependant and input specific approach to computing the WBOs.

  2. Take a simple average of the WBOs for each provided (or in-place generated) conformer.

    a. Take the Boltzmann average of the WBOs for each provided (or in-place generated) conformer as is implemented in fragmenter.

j-wags commented 3 years ago

I like the possible solutions listed above, and don't think they're mutually exclusive.

Option 1 is already in-place, and is triggered by the fractional_bondorder_method="AM1-Wiberg" attribute in the ProperTorsions or Bonds element of a SMIRNOFF force field. As you mention, it has a major shortcoming which is that it's heavily conformer-dependent.

Option 2 could be triggered by specifying fractional_bondorder_method="AM1-Wiberg-ELF10", which would need to be recognized by at least one ToolkitWrapper in a ToolkitRegistry. Ultimately it would need to be resolved in something like this if statement in the ToolkitWrapper stack.

The important decisions that we'll need to make are:

thinking what the 'recommended approach' should be (both for fitting and for the end user).

I would think that the first generation of fitting and application will be single-conformer, since we're aiming for an early-2021 release. Once implemented and used in a fit, we could include multi-conformer averaging in a production FF whenever the data shows it's ready.

It's also worth mentioning that graph-based charge and partial bond order assignment is on the distant horizon, eg from espaloma, and I don't know that we've made a decision on how those will get merged into the main line of FFs.

ChayaSt commented 3 years ago

@SimonBoothroyd and @j-wags, I'm just chiming in here to say that openeye used to store the ELF10 WBOs in the bond data. That is what was used in fragmenter. Right now, fragmenter will only work as intended with older versions of openeye.

j-wags commented 3 years ago

Thanks, @ChayaSt. Do you know the last version of OpenEye Toolkits that supported ELF10 WBOs? In the short term we can update the fragmenter conda package to ensure that it gets paired with a compatible version of OpenEye toolkits.

j-wags commented 3 years ago

@ChayaSt Bumping this topic again -- it'll be super helpful if you have a record of any versions which did/didn't have ELF10 WBO capabilities so we can pin a good version range.