[gmx-developers] tpbconv

[David van der Spoel]

On Tue, 2002-12-10 at 11:51, Berk Hess wrote:
> > > 
> > > Actually all Gromacs programs, including tpbconv and gmxcheck now use the
> > > same io routines and the same error checking, so there is no use in running
> > > gmxcheck. After mailing with Bert I assume there are very large numbers
> > > for coordinates or velocities in his trr or nan's or inf's.
> > > But this is expensive to check and also checking for nan is very tricky
> > > and system dependent.
> > I think it is still useful to use gmxcheck, e.g. when you have merged
> > two files (with trjcat). I found errors in xtc files with it which were
> > due to flaky hardware, so before throwing away you old files, use
> > gmxcheck to check the new ones, best to do it on another machine.
> > 
> 
> You mean trjcat produced incorrect xtc output from correct xtc input?
Yes. Due to flaky hardware.

> The reading routines will not return a frame with an error in it.
> So if any program could read your trajectory, gmxcheck will not provide
> additional information, except for the timestep checks and the statistics.
I only tried gmxcheck, but found the errors with it. That's all.
> 
> > trr is harder to check though.
> 
> Checking is not harder, but I think that the xtc writing routines already
> complain when trying to write nan's. Thus xtc never contains nan's.
> 
> But should we implement some check on the size of the coordinates and/or
> velocities in trajectories? This could be done in gmxcheck. Although I
> don't know if the results of comparisions with nan's are defined uniquely.
> Such a check might be so slow that we do not want to do it by default
> in tpbconv or grompp.
In principle you can check for NaN by testing 
if (x != x) {
/* x = NaN */
}
however, i've tried that in the past without success, that is the NaN's
weren't caught by this. Checking whether something is more than one box
length away from the box might be useful in some cases.

David.