[gmx-users] Re: g_mindist on 51-frame trajectory gives 51 minimum distances but <51 atom pairs

[Matthew Zwier]

Hi all,

For posterity, in case someone else searches the list with this problem:

The behavior I described a few days ago appears to be related to a bug
in gmx_mindist.c related to the precedence of the ternary "?:"
operator.  g_mindist will fail to emit (to the -o file) an atom pair
of minimum/maximum distance when the first atom involved happens to be
the first atom of the topology.  I've created an issue and submitted a
patch: http://redmine.gromacs.org/issues/872

Cheers,
MZ

On Thu, Jan 26, 2012 at 12:32 PM, Matthew Zwier <mczwier at gmail.com> wrote:
> Hi all,
>
> I'm running g_mindist (from 4.5.5) on a slew of very short
> trajectories (51 frames) in order to obtain both minimum distances and
> the corresponding atom pairs, using
>
> echo 10 11 | g_mindist -nice 10 -f seg.xtc -n $NDX -s $TPR -nopbc -o
> mindist_pairs.out -xvg none
>
> where NDX and TPR are (valid) index and topology files, respectively,
> and nopbc is specified because there is no periodic box (these are
> GB/SA simulations).  This is on a 64-bit Linux box, with GROMACS and
> all dependencies compiled with GCC.  For all trajectories, the
> resulting mindist.xvg always contains 51 entries with reasonable
> values (in the 1.1-1.5 nm range), but for a subset of the
> trajectories, the corresponding mindist_pairs.out contains less than
> 51 entries (as low as ~30 in some cases).
>
> Reading the source for gmx_mindist.c, it appears that this should
> never occur, at least not without giving a nonsense value of the
> minimum distance for that frame in the process (1 mm, it would appear
> from the source!).  I'm either missing something in my reading of
> gmx_mindist.c, I've found a bug (unlikely), or I've managed to
> convince GCC to mis-compile g_mindist somehow (more likely, though
> still somewhat baffling).  Can anyone help me figure out what's going
> on?
>
> Cheers,
> Matt Z.