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

Hard-coded Ewald tolerance #824

Closed
SimonBoothroyd opened this issue Oct 9, 2023 · 2 comments
Closed

Hard-coded Ewald tolerance #824

SimonBoothroyd opened this issue Oct 9, 2023 · 2 comments

Comments

@SimonBoothroyd
Copy link
Contributor

Description

It looks like the Ewald tolerance is hardcoded to a 'magic' number. I'm guessing this is legacy from the toolkit, but it would be good if this number was made available somewhere (either in the FF or via a global constant)

Reproduction

Please include a minimally reproducing example of this bug.

Output

Please include the output, including full tracebacks of any errors, resulting from the reproduction.

Software versions

  • Which operating system and version are you using?
  • How did you install Interchange?
  • What is the output of running conda list?
@mattwthompson
Copy link
Member

I'm guessing this is legacy from the toolkit

Right you are! I wasn't a fan of it being set away from OpenMM's default, but I think @j-wags would have been even less of a fan of that (subtle) behavior change while switching the backend over.

it would be good if this number was made available somewhere (either in the FF

Agreed, and I'm not alone openforcefield/standards#50

or via a global constant

I hadn't really considered this, and I see the utility is not having it be a number tucked away 8 files deep that the user can't change. I'm not sure exactly where it would go ... maybe there's nothing better than shoving it under the rug using keyword arguments. But that's an implementation detail.

This gets into murky territory of what is and is not a part of a force field - my first impression is that exposing it but maintaining the legacy default is still "within" the spec, in some sense. 99.9% of users would be unaffected, and if somebody wanted to go by the strictest letter of the law, I don't know how one could say that 1e-4 is more or less valid than any other value fitting the current description which says nothing more than

Ewald3D-ConductingBoundary (default) denotes that a method like particle mesh Ewald should be used.

Does this sounds reasonable, are there other details I'm unaware of here?

@mattwthompson
Copy link
Member

Should be snuck into the next release (probably by early next week?) which I think makes 0.3.15

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

No branches or pull requests

2 participants