[gmx-users] mdrun with append option
Sai Pooja
saipooja at gmail.com
Tue Feb 1 18:01:24 CET 2011
I am doing a manual replica exchange(generalized hamiltonian rem) after
every mdrun. If the replica exchange is successful, then I "exchange
checkpoint files". For example, consider the following:
Simulation parameters:....................B1.........B2
Replicas(coordinates and velocities):.R1.........R2
0. Tpbconv to extend simulation time ( using -s, -o and -nsteps ONLY)
1. Mdrun run - 500 steps = 1ps
2. Attempt exchange - NOT SUCCESSFUL
3. Exchange implementation: SKIP
4.Continue to next step
.....
0. Tpbconv to extend simulation time ( using -s, -o and -nsteps ONLY)
1. Mdrun run - 500 steps = 1ps
2. Attempt exchange - If successful, exchange
3. Exchange Implemented by - exchanging checkpointing files
4. Continue to next step
0. Tpbconv to extend simulation time ( using -s, -o and -nsteps ONLY)
1. Mdrun with exchanged .cpt files -NOW this is where the problem shows..
i) The log, xtc files are not appended when beginning after a step
with a successful exchange attempt:*According to Mark's previous mail, this
could be a result of mismatch in ensembles. Which means that the .cpt is
ignored - implying that the mdrun in B1 DOES NOT start from R2.*
Therefore, to make R1 run in B2 and R2 run in B1, do I need to supply .cpt
to tpbconv instead of mdrun after a successful exchange step?
To summarize:
APPENDING HAS NOW BECOME A SECONDARY CONCERN, WHAT I AM INTERESTED IN IS A
SUCCESSFUL MANUAL REPLICA EXCHANGE RUN AS POINTED OUT ABOVE.
I hope my dilemma is clear now.
Pooja
On Tue, Feb 1, 2011 at 11:42 AM, Justin A. Lemkul <jalemkul at vt.edu> wrote:
>
>
> Sai Pooja wrote:
>
>> From the website:
>> "If you change the integrator or ensemble, you should pass the checkpoint
>> file to tpbconv only, not to mdrun, since the state might change and thus
>> output files can not be appended."
>>
>>
>
> Are you changing the integrator, ensemble, and/or other settings? If not,
> this statement does not apply. For a simple -append after extending via
> tpbconv, this is not applicable.
>
>
> So now instead of supplying the checkpoint file to mdrun I supply it to
>> tpbconv... does this assure that the simulations start from the
>> coordinates/velocities specified by the .cpt file?
>>
>>
>
> For a simple extension, you do not pass the .cpt file to tpbconv.
>
>
> http://www.gromacs.org/Documentation/How-tos/Extending_Simulations#Version_4
>
>
> Thanks Mark. So if the simulation doesn't start from the checkpoint
>> file, from where are the initial coordinates velocities etc. taken
>> from?... the trajectory files?
>>
>
> Mark's previous message already answered this.
>
> -Justin
>
> Also, I could not find the environment variable... and I am not
>> sure
>> how to use one.
>> Pooja
>> On Tue, Feb 1, 2011 at 3:03 AM, Mark Abraham
>> <Mark.Abraham at anu.edu.au <mailto:Mark.Abraham at anu.edu.au>> wrote:
>>
>> On 1/02/2011 7:50 AM, Sai Pooja wrote:
>>
>>> I think I have figured out the reason. It is because I am
>>> carrying out replica exchange (manual) after every mdrun. If
>>> the exchange occurs, I exchange the checkpoint files, extend
>>> the simulation by 500 steps and continue. The new simulation
>>> starts from exchanged cptfile. It seems that whenever the
>>> exchange occurs, the earlier log,traj files are not appended.
>>> They are instead overwritten. the obv solution is to save and
>>> index these files with the relevant replicas everytime an
>>> exchange occurs.
>>>
>>
>> This would have been good to know earlier. If replica-exchange
>> leads to the ensemble of the .tpr not matching the ensemble of
>> the .cpt, then IIRC 4.5.3 mdrun will refuse to start from the
>> .cpt, which means the subsequent mdrun will start from the .tpr
>> only. Certainly a non-appending mdrun prints a warning (or
>> error, I forget which) message to the log file, but perhaps the
>> use of -append (erroneously) doesn't do that. Please have a look
>> and see if that is the issue. There is an environment variable
>> that can be set to tell mdrun that you (think you) know what you
>> are doing mismatching .tpr and .cpt.
>>
>> Mark
>>
>>
>> However, i have a more general question. Since mdrun still
>>> runs with the exchanged checkpoint files and starts from the
>>> point where the previous run ended, can I be assured that an
>>> exchange has been affected - since tpr files correspond to the
>>> "replica-box" and cpi to the most recent exchanged replicas?
>>> Pooja
>>>
>>> On Mon, Jan 31, 2011 at 2:33 PM, Sai Pooja <saipooja at gmail.com
>>> <mailto:saipooja at gmail.com>> wrote:
>>>
>>>
>>> I manually index checkpoint files after every mdrun. What
>>> troubles me is the randomness with which -append fails/works.
>>> For eg, I have a simulation which runs from 3ns,
>>> 1ps in 1
>>> mdrun. Now oddly enough, the logfile starts from 1184ps(in
>>> the end, I do remember the one starting from 0 but that
>>> was overwritten it seems) and the rest is appended uptil
>>> the 3000ps step. Why would append work from 1184ps to
>>> 3000ps but not for the previous ones?Could it have
>>> anything to do with the network/cluster? If that is the
>>> case is it safer to create a new file everytime and then
>>> concatenate them after say every 100ps?
>>> Pooja
>>> On Sat, Jan 29, 2011 at 6:52 PM, Mark Abraham
>>> <Mark.Abraham at anu.edu.au <mailto:Mark.Abraham at anu.edu.au>>
>>>
>>> wrote:
>>>
>>> On 30/01/2011 10:39 AM, Sai Pooja wrote:
>>>
>>>> I would be happy to supply more information.. if
>>>> someone could please look into this.. otherwise I
>>>> will have to switch to storing every file and then
>>>> just concatenating them which seems like a rather
>>>> roundabout way of doing it.
>>>>
>>>
>>> As I suggested a few emails ago, are you sure that
>>> -cpi file exists? If your numerical suffixes are
>>> indexing restarts, then unless you've done some manual
>>> copying that you haven't told us about, it won't. Your
>>> filename scheme seems a bit contorted - like you're
>>> trying to do the work that GROMACS 4.5.x will just do
>>> for you if you let it.
>>>
>>> Otherwise, you'll have to do some detective work with
>>> gmxcheck on the -cpi to see what might be the issue.
>>>
>>> In your case, an initial
>>>
>>> mdrun -deffnm rex_3
>>>
>>> (perhaps save some copies while you're experimenting)
>>> and subsequently
>>>
>>> tpbconv -extend <blah> -f rex_3 -o rex_3
>>> mdrun -deffnm rex_3 -append
>>>
>>> will work and be much simpler than whatever you're
>>> trying to do with filenames :-)
>>>
>>> Mark
>>>
>>>
>>>
>>>> On Fri, Jan 28, 2011 at 4:37 PM, Sai Pooja
>>>> <saipooja at gmail.com <mailto:saipooja at gmail.com>> wrote:
>>>>
>>>> This is the command:
>>>> nbs submit -command
>>>> "(/usr/local/gromacs/4.5.1/bin/mdrun_mpi -s
>>>> rex_3.tpr -e rex_3 -c after_rex_3 -cpi restart3
>>>> -cpo restart3 -ap
>>>> pend -g rexlog3 -x rextraj3);" -nproc 1 -name
>>>> "GENHAM-DIHEDRAL-3" -mail start end
>>>> Pooja
>>>>
>>>> On Fri, Jan 28, 2011 at 4:20 PM, Mark Abraham
>>>> <Mark.Abraham at anu.edu.au
>>>> <mailto:Mark.Abraham at anu.edu.au>> wrote:
>>>>
>>>> On 29/01/2011 3:56 AM, Sai Pooja wrote:
>>>>
>>>> Hi,
>>>> I am using tpbconv and mdrun to extend a
>>>> simulation. I use it with the append
>>>> option but the files still get
>>>> overwritten or erased. Can someone help
>>>> me in this regard?
>>>> Pooja
>>>> Commands (in python)
>>>> cmd = '(%s/tpbconv -extend %f -s
>>>> rex_%d.tpr -o rex_%d.tpr)'
>>>> %(GROMPATH,dtstep,i,i)
>>>> os.system(cmd)
>>>> time.sleep(1)
>>>> cmd = 'nbs submit -command "'
>>>> cmd += '(%s/mdrun_mpi -noh
>>>> -noversion -s rex_%d.tpr -e rex_%d -c
>>>> after_rex_%d -cpi restart%d -cpo
>>>> restart%d -append -g rexlog%d -x
>>>> rextraj%d >/dev/null); '
>>>> %(GROMPATH,i,i,i,i,i,i,i)
>>>> cmd += '" '
>>>> cmd += '-nproc 1 '
>>>> cmd += '-name "GENHAM-DIHEDRAL-%d" '%(i)
>>>> cmd += '-mail start end '
>>>> cmd += '-elapsed_limit 16h >> rexid'
>>>> os.system(cmd)
>>>>
>>>>
>>>> More useful for diagnostic and
>>>> record-preservation purposes is to construct
>>>> the cmd string and print it to stdout (or
>>>> something).
>>>>
>>>> At the moment it is far from clear that your
>>>> -cpi file exists for the new run.
>>>>
>>>> Mark
>>>> -- gmx-users mailing list
>>>> gmx-users at gromacs.org
>>>> <mailto:gmx-users at gromacs.org>
>>>>
>>>>
>>>> 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
>>>> gmx-users-request at gromacs.org
>>>> <mailto:gmx-users-request at gromacs.org>.
>>>>
>>>> Can't post? Read
>>>> http://www.gromacs.org/Support/Mailing_Lists
>>>>
>>>>
>>>>
>>>>
>>>> -- Quaerendo Invenietis-Seek and
>>>> you shall discover.
>>>>
>>>>
>>>>
>>>>
>>>> -- Quaerendo Invenietis-Seek and you
>>>> shall discover.
>>>>
>>>
>>>
>>> --
>>> gmx-users mailing list gmx-users at gromacs.org
>>> <mailto:gmx-users at gromacs.org>
>>>
>>> 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
>>> gmx-users-request at gromacs.org
>>> <mailto:gmx-users-request at gromacs.org>.
>>>
>>> Can't post? Read
>>> http://www.gromacs.org/Support/Mailing_Lists
>>>
>>>
>>>
>>>
>>> -- Quaerendo Invenietis-Seek and you shall
>>> discover.
>>>
>>>
>>>
>>>
>>> -- Quaerendo Invenietis-Seek and you shall discover.
>>>
>>
>>
>> --
>> gmx-users mailing list gmx-users at gromacs.org
>> <mailto:gmx-users at gromacs.org>
>>
>> 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 gmx-users-request at gromacs.org
>> <mailto:gmx-users-request at gromacs.org>.
>>
>> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>>
>>
>>
>> -- Quaerendo Invenietis-Seek and you shall discover.
>>
>>
>>
>>
>> --
>> Quaerendo Invenietis-Seek and you shall discover.
>>
>>
> --
> ========================================
>
> 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
>
> ========================================
> --
> gmx-users mailing list gmx-users at gromacs.org
> 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 gmx-users-request at gromacs.org.
> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
--
Quaerendo Invenietis-Seek and you shall discover.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-users/attachments/20110201/78f26788/attachment.html>
More information about the gromacs.org_gmx-users
mailing list