problem in LJ(SR) with large cutoff using 4.6 with cutoff-scheme=group
On few systems I tried using 4.6 with cutoff-scheme=group, when cutoff is higher than a (not the same for each system) value
the LJ starts to diverge. With Verlet, or with versions 3.3.4, 4.5.6 I get the same results.
With bigger systems the deviation is in some cases 50%.
Here I upload the simplest system : inert gases mixture, no Coulomb etc.
Contents of the tarball :
3 grompp templates for 3, 4.5 and 4.6 with 0 steps.
a perl script that runs all versions - paths should be adjusted
The results obtained by perl script.
#1 Updated by Berk Hess over 7 years ago
- Category set to mdrun
- Status changed from New to In Progress
- Assignee set to Erik Lindahl
- Target version set to 4.6.2
- Affected version - extra info set to 4.6.1
I reproduced the higher energies and noticed forces on some particles are incorrect.
This issue is present for the SIMD group kernels in 4.6 with 4- or 8-way SIMD, SSE or AVX single precision and AVX-256 double precision, not with 2-way SIMD. It happens when the number of pairs is close to INT_MAX. The plain-C kernels work fine. So I guess the issue is in the group SIMD kernels where an integer index might be multiplied by the SIMD width.
The strange thing is that the error gets larger when running 12 MPI tasks iso 1. Running in parallel will lower the local neighborlist size, so this seems to indicate the issue is not in the list itself.
On a single MPI rank we will hit INT_MAX sooner or later, but we should at least be able to run arbitrarily large cut-off's by running more parallel.
#3 Updated by Erik Lindahl over 7 years ago
There is nothing obvious we do with indices in the SIMD kernels (we simply load 4/8 instead of one). However, we don't need padding for the 2-way SIMD kernels, so the first place I would look is the neighbor list generation!
My time is very limited the next week, so it will likely be next weekend before I can have a look!
#6 Updated by Mark Abraham over 6 years ago
It seems possible that https://gerrit.gromacs.org/#q,Ie64ab6c0313a8dc0d3545a5e7d610f24adae4438,n,z fixed this. This will be in GROMACS 4.6.4. If you continue to observe the issue there, Dmitri, we'll try to look at it.