Add grompp check that non-excluded atoms are not too close to each other in the starting structure
Topologies using complex features might accidentally place particle sites on top of each other, which can lead to strange numerical issues if they are not excluded from short-range interactions. grompp should check e.g. that no non-excluded atom pairs are at less than (say) 1% of the interaction range. That will require a neighbour search, however.
Justin's original bug report follows
Posted to gmx-developers:
Ligands with virtual sites randomly fail in calculations using Verlet, with or without the free energy code, as I was trying to use. The issue may not be specific to Verlet though, as the group scheme fails when the free energy code is active as well. From my original post, I have tested the following combinations:
1. Free energy + Verlet = immediate seg fault in energy minimization 2. FE off + Verlet = seg fault 3. FE + group = seg fault 4. FE off + group = WORKS 5. Single-point energy (FE off + Verlet) = seg fault (so it is not specific to the minimizer, as I use the md integrator in the .mdp file) 6. Generic kernels seg fault 7. Disabling SIMD (GMX_SIMD=None when running cmake) seg faults 8. Doing an absolute free energy calculation runs fine
I have attached a .tpr file of the minimization that fails using Verlet + free energy code (i.e. the calculation that I actually want to run). It immediately seg faults for me with -nan for Coul(SR).
#3 Updated by Berk Hess about 4 years ago
This is one of the few cases where it's difficult to avoid floating point exceptions or segmentation faults. Maybe we should check that no non-excluded atoms are too close to each other in the starting structure.
PS This case is relatively easy to track down if you run a debug binary through gdb. You need to figure out which variables to print though.
#4 Updated by Mark Abraham about 4 years ago
- Tracker changed from Bug to Feature
- Subject changed from Seg fault in nbnxn grid to Add grompp check that non-excluded atoms are not too close to each other in the starting structure
- Status changed from Closed to Accepted
- Assignee deleted (
- Priority changed from Normal to Low
- Target version deleted (
That check seems like a good idea