[gmx-users] Problems with XTC Files

[Peter Tieleman]

I think this is what Anton is referring to:

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

void main(int argc,  char *argv[]) {
    int f, out;
    int value;
    int res;
    char buf[1024*32];
    if (argc!=3) {
        fprintf(stderr, "usage: %s <filename> <rescue file>\n", argv[0]);
    }
    f = open(argv[1], O_RDONLY);
    if (f == -1) {
        perror("couldn't open file");
    }
    lseek(f, 2287*66000, SEEK_SET);

    while (read(f, &value, 4) == 4 && value != 1995) {
        ;
    }
    printf("postion %ld \n", (long)tell(f)-4);
    out=open(argv[2], O_WRONLY | O_CREAT, 0666);
    write(out, &value, 4);
    while ((res = read(f, buf, 1024*32)) > 0) {
        write(out, buf, res);
    }
}

I've used it on SGI's but I think there will be endian problems if you use
this on a linux machine. Maybe it's just the value of 1995 that changes?

Peter

-----Original Message-----
From: gmx-users-admin at gromacs.org [mailto:gmx-users-admin at gromacs.org]On
Behalf Of K.A.Feenstra
Sent: Thursday, December 06, 2001 4:45 AM
To: gmx-users at gromacs.org
Cc: David van der Spoel; Christoph Meier
Subject: Re: [gmx-users] Problems with XTC Files



David van der Spoel wrote:
>
> Problem maybe that something went wrong in writing, but not enough wrong
> to crash the simulation. Could be e.g. an NFS disk.

We have seen this error occasionally, and indeed it seems to be due to
a missing nfs buffer write to the file, i.e. there is a small section
of the file missing in the middle.

> We have no tools to repair xtc files. The only thing you could do is try
> to write a program that scans the files for a magic number (the start of
> each xtc frame is an integer with value 1995). You'd have to scan the file
> byte by byte, and then you should do an extra check to see whether this
> really is the start. Maybe it can be built into gmxcheck.

After one of the occasions, we wrote such a small tool, unfortunately
it was used once and then got lost. Simply scanning for the magic
nubmer, which is a long int (32 bits), should be as good as fool-proof,
chances of getting this number in the trajectory are extremely low,
especially since it contains many zero's and xtc is compressed so
shouldn't contain many zero's.

--
Groetjes,

Anton
 _____________ _____________________________________________________
|             | Anton Feenstra       Dept. of Biophysical Chemistry |
|  _   _  ___,| K.A.Feenstra at chem.rug.nl    University of Groningen |
| / \ / \'| | | Tel +31 50 363 4327                    Nijenborgh 4 |
|(   |   )| | | Fax +31 50 363 4800               9747 AG Groningen |
| \_/ \_/ | | | http://md.chem.rug.nl/~anton        The Netherlands |
|             | "It Costs Too Much If It Costs a Lot" (Magnapop)    |
|_____________|_____________________________________________________|
_______________________________________________
gmx-users mailing list
gmx-users at gromacs.org
http://www.gromacs.org/mailman/listinfo/gmx-users
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-request at gromacs.org.