Closed josephburkhart closed 1 month ago
For future reference, there is make_example_simulation
which can make these MWE's easier to write.
HOOMD has rich Python abstractions for validating parameters. Here is an example: https://github.com/glotzerlab/hoomd-blue/blob/04c6c71d1263b3616227e429963e1c2f64404b5f/hoomd/md/minimize/fire.py#L220-L224 https://github.com/glotzerlab/hoomd-blue/blob/04c6c71d1263b3616227e429963e1c2f64404b5f/hoomd/data/typeconverter.py#L82-L91
You can apply positive_real
in the same way to sigma
in the Gaussian
and ExpandedGaussian
potentials here:
https://github.com/glotzerlab/hoomd-blue/blob/04c6c71d1263b3616227e429963e1c2f64404b5f/hoomd/md/pair/pair.py#L274-L279
https://github.com/glotzerlab/hoomd-blue/blob/04c6c71d1263b3616227e429963e1c2f64404b5f/hoomd/md/pair/pair.py#L331-L337
Description
When assigning parameters for pairwise forces, it is currently possible to assign values that will cause critical errors such as divide-by-zero in the simulation's execution. It would be beneficial to detect these cases prior to simulation execution and either warn the user about them or throw an error. An example is given below.
In the following MWE, I create a binary ("A" and "B") system of particles that interact with Gaussian pairwise forces. "A" particles are cores, "B" particles are constituents. I only want interactions to happen for B particles, so I set the parameters for A-A and A-B pairs to zero. This should cause an error, since σ is in the denominator in the force's definition.
Indeed, the simulation does throw an error:
RuntimeError: Particle with unique tag 17 has NaN for its position.
. Within this MWE, the cause of the problem is pretty clear, but when working with systems that are more complex, this problem can be much more difficult to diagnose - this is evidenced by the fact that it took me, @tcmoore3 and @joaander multiple meetings and many hours to figure out that this was causing fatal errors in my simulations.Proposed solution
I am not yet familiar enough with Hoomd's architecture to directly propose a solution, but I would expect that the value check should happen in the same place where types are checked at simulation execution. With some assistance/direction from @joaander, this issue may offer a good opportunity for me to make my first pull request in this repo.
Additional context
No response