Thanks for the reply Chris :). It is not possible to get the data with -b option, since trjconv crashes when it meets the corrupted frame.
I never had corruption issues in the past and thereby didn't use gmxcheck early enough to avoid the second corruption. The problems should have occurred in runtime and I strongly suspect they took place at continuation points. I used Gromacs 4.5.6. If .trr formatted frames start with a specific number, I would be grateful if anyone of the developers of Gromacs could share it. Otherwise, I will contact the developers of gmx_rescue. Best, Yiannis If the corrupted frame is at 1000 ps, and you can not get at the data after the corrupted frame by using: trjconv -b 1100 , then I suspect that you don't have any good solution here, unless the developers put in some type of magic number at the start of each frame that you could search for with a c program (perhaps contact the developers of gmx_rescue for advice?) A related question is how you ended up with a long .trr file that has corruption in the middle. Did that corruption happen at runtime or later due to a filesystem problem? If it was a later filesystem problem, then you might look into backup solutions. If it happened at runtime, then it would be useful to figure out what happened because ideally gromacs would not forever append to corrupted files since many of us don't look at information in the .trr files until very late in the analysis and an optional 0.1% loss in efficiency might be reasonable to ensure that this doesn't happen (at least our system admins would tell us so). For that, you'll probably need to provide details, including what version of gromacs you used. Chris. -- original message -- I have some corrupted frames in different trajectories. gmxcheck with .trr trajectories gives extraordinary positions or velocities and with .xtc trajectories gives rise to the magic number error. I am aware of the program gmx_rescue kindly offered to us by its developers. However, this program can only work with .xtc files. It is possible to rescue .trr files when there is a maximum of one corrupted frame by checking the size of healthy frames, chopping the parts of the trajectory before and after, using e.g. programs head and tail with the corresponding integer multiples of one healthy frame in bytes and stitching them together. However, when there is two or more corrupted frames in different locations, although it is not hard to spot the exact locations, it is no longer possible to remove the problematic frames size-wise (or at least it is less likely to succeed than winning the lottery) , since the size of each corrupted frame is non-standard. Is there any corresponding s oftware to gmx_rescue that can be used with .trr files? Is there any other recent program or any other way of coping with the problem? I did not post any details of my systems or the specific error messages I get because I believe my question is clear. Thank you in advance! Best, Yiannis -- gmx-users mailing list [email protected] http://lists.gromacs.org/mailman/listinfo/gmx-users * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/Search before posting! * Please don't post (un)subscribe requests to the list. Use the www interface or send it to [email protected]. * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
