[gmx-users] Re: segmentation fault while running eneconv
Justin A. Lemkul
jalemkul at vt.edu
Tue Jan 25 19:21:54 CET 2011
anna.marabotti at isa.cnr.it wrote:
> Dear Justin,
> thank you for your answer. I'm currently using Gromacs version 4.0.7
> which was compiled in double precision, therefore I strongly suspect
> that this is a problem linked to the old bug. It seems to me that I used
> eneconv previously on this machine to concatenate .edr files, but I
> cannot be sure. However, before writing you I copied the .edr files on
> another machine, which still has Gromacs 4.0.7 installed, but compiled
> in single precision, and still I found the same error Segmentation fault.
>
I don't believe you have a problem related to the bug; it was introduced in the
4.5 series, so 4.0.7 should be unaffected. Since gmxcheck seems to have worked,
that's more evidence that there is no bug. The problem was in the .edr
formating, causing all Gromacs utilities to stop reading double-precision .edr
files.
> Concerning the name of the files, when I described the commands in my
> previous message I used a "simplified" version of their names in order
> to avoid writing the long 2GH9openmod4_pH...blabla, but I checked
> several times the names I used and I can assure you that I tried to
> concatenate the correct file names. Therefore, the problem is not a
> typo. Sorry for not explaining it before.
>
OK. Literal is always better, and often requires a simple cut and paste from
the terminal, rather than any manual typing at all :)
> I made a check wit gmxcheck on 2 files: the .edr and .xtc files from the
> MD of 5 ns and the .edr and .xtc files from the MD of 50 ns (started
> immediately after the 5ns using tpbconv): these are the results:
> Checking file 2GH9openmod4_pH10_5ns.xtc
> Reading frame 0 time 0.000
> # Atoms 40139
> Precision 0.001 (nm)
> Last frame 1000 time 5000.000
> Item #frames Timestep (ps)
> Step 1001 5
> Time 1001 5
> Lambda 0
> Coords 1001 5
> Velocities 0
> Forces 0
> Box 1001 5
>
> Checking energy file 2GH9openmod4_pH10_5ns.edr
> Opened 2GH9openmod4_pH10_5ns.edr as double precision energy file
> frame: 0 (index 0), t: 0.000
> Last energy frame read 50 time 5000.000
> Found 51 frames with a timestep of 100 ps.
>
> Checking file 2GH9openmod4_pH10_50ns.xtc
> Reading frame 0 time 0.000
> # Atoms 40139
> Precision 0.001 (nm)
> Reading frame 2000 time 10000.000
> Item #frames Timestep (ps)
> Step 2981 5
> Time 2981 5
> Lambda 0
> Coords 2981 5
> Velocities 0
> Forces 0
> Box 2981 5
>
> Checking energy file 2GH9openmod4_pH10_50ns.edr
> Opened 2GH9openmod4_pH10_50ns.edr as double precision energy file
> frame: 0 (index 0), t: 0.000
> Last energy frame read 149 time 14900.000
> Found 150 frames with a timestep of 100 ps.
>
> It seems to me that all is regular; the only strange thing is that both
> start at time 0, despite I used tpbconv+mdrun with cpi to continue the
> MD after the first 5 ns.
>
What does the log file tell you regarding the outset of the second job? It
should say that it's starting from a checkpoint, and the first interval written
should have a time of 5000 ps. If not, then the checkpoint file was not
properly used. If both .edr files start at the same point, that could be a
reason for the seg fault, but that's a bit of a guess.
From the gmxcheck output, it appears that your _50ns.edr file does indeed start
from 0 instead of 5000, as you would hope.
> I return with my previous question: how can I manage this problem,
> especially if I have the version 4.0.7? Do I have to ask administrators
> to fix the bug? Do I have to restart all my simulations?
>
If the "continuation" instead started from t=0, then you don't have to re-do
anything, just don't use the _5ns.* information (.xtc, .edr, etc) since you
basically did that portion of the simulation over. The log files will tell you
what's going on.
-Justin
> Thank you very much and best regards
> Anna
>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 25 Jan 2011 09:43:20 -0500
>> From: "Justin A. Lemkul" <jalemkul at vt.edu>
>> Subject: Re: [gmx-users] segmentation fault while running eneconv
>> To: Discussion list for GROMACS users <gmx-users at gromacs.org>
>> Message-ID: <4D3EE188.7000405 at vt.edu>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>>
>>
>> Anna Marabotti wrote:
>>> Dear all,
>>>
>>> I launched on my system a first simulation of 5 ns, then I prolonged it
>>> to 50 ns using
>>> tpbconv -s tpr1_5ns.tpr -until 50000 -o tpr2_50ns.tpr
>>> and then
>>> mdrun -s tpr2_50ns.tpr -deffnm md2_50ns -cpi md1_5ns.cpt
>>> Since my simulation was interrupted several times, every time I
>>> relaunched it simply doing:
>>> mdrun -s tpr2_50ns.tpr -cpi md2_50ns.cpt -deffnm md2_50ns_2/3/4
>>>
>>> At the end of these simulations I obtained the following files:
>>> - md1_5ns.xtc and .edr: files obtained from the first MD of 5 ns long
>>> - md2_50ns.xtc and .edr: files obtained by prolonging the first MD until
>>> 50ns
>>> - md2_50ns_2.xtc and .edr: files obtained by restarting the previous
>>> dynamics that was interrupted before 50 ns
>>> - md2_50ns_3.xtc and .edr: same as before
>>> - md2_50ns_4.xtc and .edr: same as before
>>>
>>> After all these runs, I want to concatenate all the dynamics in order to
>>> have a single .xtc file md_50ns_tot and a single .edr file
>>> md_50ns_tot.edr. For the first, I used:
>>> trjcat -f md1_5ns.xtc md2_50ns.xtc md2_50ns_2.xtc md2_50ns_3.xtc
>>> md2_50ns_4.xtc -o md_50ns_tot.xtc
>>> and all worked fine: I obtained the output file with no errors (there
>>> are no errors also in the .log files)
>>>
>>> On the contrary, when I tried to do the same with eneconv:
>>> eneconv -f md1_5ns.edr md2_50ns.edr md2_50ns_2.edr md2_50ns_3.edr
>>> md2_50ns_4.edr -o md_50ns_tot.edr
>>> I obtained the following output:
>>>
>>> Opened 2GH9openmod4_pH10_5ns.edr as double precision energy file
>>> Reading energy frame 1 time 100.000
>>> Opened 2GH9openmod4_pH10_50ns.edr as double precision energy file
>>> Reading energy frame 0 time 0.000
>>> Opened 2GH9openmod4_pH10_50ns_2.part0002.edr as double precision energy file
>>> Reading energy frame 0 time 14900.000
>>> Opened 2GH9openmod4_pH10_50ns_3.part0003.edr as double precision energy file
>>> Reading energy frame 0 time 27800.000
>>> Opened 2GH9openmod4_pH10_50ns_4.part0004.edr as double precision energy file
>>> Reading energy frame 0 time 38800.000
>>>
>>> Summary of files and start times used:
>>>
>>> File Start time
>>> -----------------------------------------
>>> 2GH9openmod4_pH10_5ns.edr 0.000
>>> 2GH9openmod4_pH10_50ns.edr 0.000
>>> 2GH9openmod4_pH10_50ns_2.part0002.edr 14900.000
>>> 2GH9openmod4_pH10_50ns_3.part0003.edr 27800.000
>>> 2GH9openmod4_pH10_50ns_4.part0004.edr 38800.000
>>>
>>> Opened 2GH9openmod4_pH10_5ns.edr as double precision energy file
>>> Segmentation fault
>>> Looking for some hints in the gmx-users list the only thing I found that
>>> could be similar to my problem is this old message:
>>> http://lists.gromacs.org/pipermail/gmx-users/2007-January/025657.html
>>>
>> What Gromacs version are you using? If it is not 4.5.3, then you're probably
>> running into a bug regarding double precision .edr files that was fixed some
>> time ago.
>>
>>> I see in the output error message that the start time for the first two
>>> simulations is the same: could be this one the problem for my system?
>>> However, I did use tpbconv each time to make restarts of my simulations,
>>> I really don't know why the start time is 0.000 in the first two cases.
>> Well, your commands don't agree with the output of eneconv. The names are
>> different. Perhaps you've confused what files you think you're using, or
>> otherwise attempted to append to a file and then gave it a new name. In any
>> case, gmxcheck is your friend here.
>>
>>> Is there a problem in the results of simulations if these two
>>> simulations have the same start time? Practically, what can I do to
>>> concatenate my .edr files?
>>>
>> Presumably, yes. As long as the .edr files have no internal corruptions (which,
>> unfortunately, is quite possible if the job frequently went down), then you
>> should be able to concatenate them. That also depends on the version of Gromacs
>> you're using, if you're running into the old bug. It's always helpful to state
>> right up front which version you're using when reporting a problem.
>>
>> -Justin
>>
>>> Many thanks in advance and best regards
>>> Anna Marabotti
>>>
>>> ____________________________________________________
>>> Anna Marabotti, Ph.D.
>>> Laboratory of Bioinformatics and Computational Biology
>>> Institute of Food Science, CNR
>>> Via Roma, 64
>>> 83100 Avellino (Italy)
>>> Phone: +39 0825 299651
>>> Fax: +39 0825 781585
>>> Email: anna.marabotti at isa.cnr.it <mailto:anna.marabotti at isa.cnr.it>
>>> Skype account: annam1972
>>> Web page: http://bioinformatica.isa.cnr.it/anna/anna.htm
>>>
>>> "When a man with a gun meets a man with a pen, the man with a gun is a
>>> dead man"
>>>
>>>
>> --
>> ========================================
>>
>> Justin A. Lemkul
>> Ph.D. Candidate
>> ICTAS Doctoral Scholar
>> MILES-IGERT Trainee
>> Department of Biochemistry
>> Virginia Tech
>> Blacksburg, VA
>> jalemkul[at]vt.edu | (540) 231-9080
>> http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
>>
>> ========================================
--
========================================
Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
MILES-IGERT Trainee
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
========================================
More information about the gromacs.org_gmx-users
mailing list