Re: [AMBER] AMBER Autoimage Warning

From: Jason Swails <>
Date: Mon, 24 Aug 2015 13:38:00 -0400

On Mon, Aug 24, 2015 at 12:42 PM, Brittany Boykin <> wrote:

> Hello users,
> Thank you Jason Swails for responding to my question.
> 14 frames 58360-58373 of 60000 frames showed this Warning:
> Frame 58360 imaging failed, box lengths are zero
> Since I now know this happened for whatever reason, the unit cell
> dimensions were set to 0. I did this system no differently than my other
> systems using cpptraj. Also, when I ran the Trajin analysis, it processed
> 60000 frames successfully with no Warnings, do you know why this is?

​I have no idea. I've never seen it happen before. It could be that the
simulation became corrupted, the file itself may have been corrupted, ...
But all of it is speculation.

What format is this trajectory stored in?​

> Also, now the bigger question is how this happened and how I can go about
> fixing the Warning?

​There are number of possible "hows", none particularly likely. But it's
all conjecture (and I can't even say with complete confidence that the
explanations are even *possible*). The disk may be going bad, and data was
corrupted when written to it. There may have been a weird bug either in
Amber or whatever simulation program you were using that caused the unit
cell to get zeroed out right before it was written out (but as your
simulation didn't blow up immediately thereafter, it doesn't seem to have
leaked into the simulation itself). There might be a weird issue with
cpptraj not processing the unit cell dimensions from your file quite right
(you could use another trajectory library to validate this behavior -- but
it's *highly* unlikely with either the mdcrd or NetCDF file formats). It
could be that whatever program you used to generate the trajectory (if it's
not Amber) uses a dialect of, for instance, the DCD file that cpptraj
doesn't recognize by default (but this would show problems *every* frame,
not just <0.1% of them). The file buffer may have been corrupted when
writing the file during the simulation (possible a kernel issue). ...

There are probably a number of other explanations. But to answer your
question directly: I don't know. Many of the explanations means those
frames are corrupt and there *is* no fixing the warning (outside of either
re-running the calculation or discarding the problematic frames).


Jason M. Swails
Rutgers University
Postdoctoral Researcher
AMBER mailing list
Received on Mon Aug 24 2015 - 11:00:04 PDT
Custom Search