Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SMIRNOFF: Clarifying the meaning of switch_width #9

Open
mattwthompson opened this issue Jun 16, 2021 · 5 comments
Open

SMIRNOFF: Clarifying the meaning of switch_width #9

mattwthompson opened this issue Jun 16, 2021 · 5 comments
Assignees
Labels

Comments

@mattwthompson
Copy link
Member

mattwthompson commented Jun 16, 2021

This is a follow-on to openforcefield/openff-toolkit#896, where you'll find some general confusion about what switch_width encodes. In particular, does it define the value of r at which the switching function starts to be applied, or the distance less than the cutoff that it should be applied. For example, the Parsley line of force fields defines switch_width="1.0 * angstrom" cutoff="9.0 * angstrom". Does this mean that the cutoff starts being applied at 1 A or 8 A? Probably 8 A, but it's not clear.

There are also some questions around how different engines apply the switching function. @chodera provided some context and a comparison between OpenMM, Amber, CHARMM, and GROMACS implementations: openforcefield/openff-toolkit#896 (comment). In short, the differences probably don't matter to most users, but every engine seems to implement it a little bit differently. This is an issue if we'd like to define the functional form of the switching function (some polynomial) in the force field and expect precisely matching results in different engines' implementations.

@davidlmobley
Copy link

I suggest we rephrase to say that the potentail begins begin switched off at 9 angstroms (I think that's what's said here) and finishes being switched off over the switch-width, so that it goes to zero at a distance of 10 angstroms.

Note that that's entirely different from EITHER of your interpretations, so we have to check whether it's 9 angstroms or 8 angstroms in the implementation.

In any case, this should be able to be fixed by checking the implementation detail and then clarifying the documentation.

@mattwthompson
Copy link
Member Author

I'm pretty sure, at least in OpenMM's implementation, that the switching distance is applied at distances LESS than the cutoff:

When using a cutoff, by default Lennard-Jones interactions are sharply truncated at the cutoff distance. Optionally you can instead use a switching function to make the interaction smoothly go to zero over a finite distance range. To enable this, call setUseSwitchingFunction(). You must also call setSwitchingDistance() to specify the distance at which the interaction should begin to decrease. The switching distance must be less than the cutoff distance.

This is why I've been thinking that switch_width="1.0 * angstrom" cutoff="9.0 * angstrom" maps on to setSwitchingDistance(8 * unit.angstrom) (and setCutoffDistance(9 * unit.angstrom)). If this was meant to be setSwitchingDistance(9 * unit.angstrom) / setCutoffDistance(9 * unit.angstrom) that might mean everything has been running with slightly different defaults that originally intended. This would only be an issue insofar as there is a difference between an original intent and the implementation so far - I believe the toolkit (despite a silent bug resulting in the switching function never having been applied) has been consistent over the years in applying a 9 Angstrom cutoff.

This is all somewhat confusing to me and I could again be wrong - apologies if I continue to muddy the waters in an effort to tidy things up.

@davidlmobley
Copy link

Ahh OK I agree with your reading of the docs there. This is different than how switch would normally be explained/done in GROMACS. So... let's do it that way and document.

@davidlmobley
Copy link

(That way = "the way OpenMM is doing it" I mean)

@mattwthompson
Copy link
Member Author

It turns out this type of tail correction (applying a switching function to the potential, not force) is not supported by Amber and a little tricky to pull off in LAMMPS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants