[gmx-developers] Bug in g_hbond
Michael Patra
patra at lorentz.leidenuniv.nl
Thu Mar 3 11:53:22 CET 2005
Dear all,
I want to report what I believe to be a bug in g_hbond, leading to a
segmentation violation in build_grid(). The relevant parts of the source
code are as follows:
invdelta[m]=ngrid[m]/box[m][m];
/* put atom in the box */
if( x[ad[i]][m] < 0 )
rvec_inc(x[ad[i]],box[m]);
if( x[ad[i]][m] >= box[m][m] )
rvec_dec(x[ad[i]],box[m]);
/* determine grid index of atom */
grididx[m]=x[ad[i]][m]*invdelta[m];
newgrid=&(grid[grididx[ZZ]][grididx[YY]][grididx[XX]].d[gr]);
The particles are put onto a grid containing ngrid[] elements. The conditional
statements make sure that coordinate x[] of the particle is inside the box. At
first sight, this should give a grid index 0<=grididx[]<ngrid[] such that the
indices into the array grid[] are well-defined.
Unfortunately this is not the case due to the finite precision of invdelta when
single precision floating-point numbers are used. If x[] is close to box[], the
grid index actually can be too large:
(gdb) print x[ad[i]][1]
$1 = 7.91944504
(gdb) print box[1][1]
$2 = 7.91944551
(gdb) print ngrid[1]
$3 = 18
(gdb) print grididx[1]
$4 = 18
The solution to the problem is obvious:
grididx[m]=x[ad[i]][m]/box[m][m]*ngrid[m];
In addition, I wonder why x[] can be outside the box by at most a single
box size - especially if trjconv -pbc nojump is used. Perhaps there is some
pre-processing of the input data done somewhere in one of the library functions
(I didn't check it). If not, perhaps one should replace the if-statements
by while-statements.
while( x[ad[i]][m] < 0 )
rvec_inc(x[ad[i]],box[m]);
while( x[ad[i]][m] >= box[m][m] )
rvec_dec(x[ad[i]],box[m]);
Greetings,
- Michael Patra
More information about the gromacs.org_gmx-developers
mailing list