You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't know the best language to use here, but I think I can get the message across with an example. Assume some future version of the SMIRNOFF spec allows for morse bond potentials, and a force field would like to use harmonic potentials for most bonds but morse potentials for other bonds. (Torsions are probably a more realistic example.) How should this be encoded, and should there be any restrictions? If split out, like
My first reaction is that this seems so painful/dangerous/confusing that we might want to insist all instances of a parameter type have the same functional form. But... maybe there are cases where we really really want different forms...?
But... maybe there are cases where we really really want different forms...?
My +1 would be to start restrictive (i.e. forbid mixing of FF forms), and loosen the restrictions when / if someone does eventually want this supported, with the caveat that the lobbying person should have a clear use case for enabling this. Otherwise you're building in complexity that will probably never be touched.
I don't know the best language to use here, but I think I can get the message across with an example. Assume some future version of the SMIRNOFF spec allows for morse bond potentials, and a force field would like to use harmonic potentials for most bonds but morse potentials for other bonds. (Torsions are probably a more realistic example.) How should this be encoded, and should there be any restrictions? If split out, like
how would parameter precedence be resolved?
This is potentially a headache for implementation, and that's probably where most of the the responsibility lies.
The text was updated successfully, but these errors were encountered: