2011/1/22 Marek Maly <marek.maly.ujep.cz>
> Dear Jason,
> first of all thank you very much for your comments !
>
> I apologize for my bad RST format interpretation, I was
> assuming format:
>
> xi yi zi vxi vyi vzi
>
Ah, this explains the line you specified (and is certainly a reasonable way
of formatting the restart file, though it's not the one that's used). In
that case, you were actually looking at the velocities of the atoms that
were failing. Velocities should never overflow the restart file, especially
since the max limit is typically 20 amber units.
If you ever have questions regarding the format of amber files, see
http://ambermd.org/formats.html.
>
> I just quickly verified that there is no NaN in the file and that there is
> the same number of rows as is the number of atoms
> (without two first and one last record) and did not check the formating on
> Amber web page.
>
>
> Your explanation seems to be logic and clear although there are two
> strange things:
>
> a)
> You are right, my MDCRD files are in ASCII format, but as I wrote before,
> the trajectory
> of the 60th part of the simulation prod60_G4malTRI_ANS.mdcrd is OK
> including the last frame.
> At least I was able to load and visualised all 50 frames in UCSF Chimera
> software and
> also VMD did not reported any errors. Moreover I did not find any *
> characters within this file.
> You can download and check it here http://physics.ujep.cz/~mmaly/amber/<http://physics.ujep.cz/%7Emmaly/amber/>
> (prod60_G4malTRI_ANS.mdcrd)
>
Hmm. This is strange... Perhaps visualizing will help (that file is a bit
too large for me to download at home).
>
>
> b)
> I agree with you that just setting ig=-1 should not solve the problem,
> just postpone it.
> That was one reason why I put my question on Amber forum.
> But anyway it is a little surprising that this change (write ig=-1 in my
> *.in file)
> which I did on the start of 60th simulation part (of one of my
> verification run) solved the situation
> for consequent parts 61,62,63,64,65,66,67 (where 67 is actually in
> progress, ig=-1 is valid
> for part 60 and all the consequent sim. parts.) where each part has 250
> 000 1fs time steps.
> I would suppose crash during 61 or 62 part.
>
Hmm. Also strange. But again, visualizing would probably help here. It
could be that (since you're using Langevin dynamics), a random kick was
applied to the offending atom(s) in the *opposite* direction, so it's taking
a bit longer to appear. If you added iwrap, though, this would explain it.
>
> Anyway thanks for your recommendation regarding iwrap=1. As I am not
> interested
> about the diffusion phenomena, it is a good solution. The problem is that
> I newer experienced this type of errors as I was up to "now" using just
> CPUs where the simulations
> were a little shorter :)) so this is a brand new phenomenon for me which
> appeared with
> long simulation times which is in real time possible to achieve with GPUs.
>
Awesome! This was the goal in its implementation in the first place.
> Thanks also for NetCDF MDCRD format recommendation. If standard
> visualisation softwares which I use,
> (UCSF Chimera, VMD) has no problems with this format, there is no reason
> for me to use ASCII anymore.
>
Glad to have convinced you of NetCDF over ASCII trajectories.
All the best,
Jason
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
352-392-4032
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sat Jan 22 2011 - 08:00:02 PST
