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: Can handlers of the same type with different functional forms co-exist? #10

Open
mattwthompson opened this issue Jun 16, 2021 · 2 comments
Labels

Comments

@mattwthompson
Copy link
Member

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

<Bonds version="2.0" potential="harmonic">
    ...
</Bonds>
<Bonds version="2.0" potential="morse">
    ...
</Bonds>

how would parameter precedence be resolved?

This is potentially a headache for implementation, and that's probably where most of the the responsibility lies.

@davidlmobley
Copy link

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...?

@SimonBoothroyd
Copy link
Contributor

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.

@mattwthompson mattwthompson self-assigned this Sep 30, 2021
@mattwthompson mattwthompson removed their assignment Mar 9, 2023
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

3 participants