[gmx-users] solvent change-reg.
chandran karunakaran
ckaru2000 at yahoo.com
Thu Feb 3 14:49:59 CET 2011
Dear GMX-users,
I am not able to run the GMX molecular dynamics simulation of proteins
in DMSO solvent. It is not accepting the DMSO solvent and gives error. I would be happy if
GMX users help in running for solvents other than water.
with thanks
*******************************+
Dr.Karunakaran Chandran +
Biophysics Department +
Medical College of Wisconsin +
Milwaukee, WI-53226 +
Resi.: 414-443-0085 +
Off : 414-456-4034 +
********************************
--- On Thu, 3/2/11, gmx-users-request at gromacs.org <gmx-users-request at gromacs.org> wrote:
From: gmx-users-request at gromacs.org <gmx-users-request at gromacs.org>
Subject: gmx-users Digest, Vol 82, Issue 29
To: gmx-users at gromacs.org
Date: Thursday, 3 February, 2011, 5:43 AM
Send gmx-users mailing list submissions to
gmx-users at gromacs.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.gromacs.org/mailman/listinfo/gmx-users
or, via email, send a message with subject or body 'help' to
gmx-users-request at gromacs.org
You can reach the person managing the list at
gmx-users-owner at gromacs.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of gmx-users digest..."
Today's Topics:
1. Re: mdrun with append option (Sai Pooja)
2. Re: mdrun with append option (Sai Pooja)
----------------------------------------------------------------------
Message: 1
Date: Wed, 2 Feb 2011 18:49:28 -0500
From: Sai Pooja <saipooja at gmail.com>
Subject: Re: [gmx-users] mdrun with append option
To: jalemkul at vt.edu, Discussion list for GROMACS users
<gmx-users at gromacs.org>
Message-ID:
<AANLkTinLd+ewQJOapkAC_gEGo7Y72h1YqAFvp-O3YnSh at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks Justin for being so patient. I have understood almost everything and
I hope this is the last question on this thread.
See inline ...
On Wed, Feb 2, 2011 at 5:53 PM, Justin A. Lemkul <jalemkul at vt.edu> wrote:
>
>
> Sai Pooja wrote:
>
> On Wed, Feb 2, 2011 at 3:15 PM, Mark Abraham <Mark.Abraham at anu.edu.au<mailto:
>> Mark.Abraham at anu.edu.au>> wrote:
>>
>> On 3/02/2011 6:15 AM, Sai Pooja wrote:
>>
>> The problem is solved with grompp i.e. I use the -t .cpt option.
>> However, now appending does not work. I remember Mark said in a
>> previous mail that a certain environment variable can allow
>> appending to happen even in such cases. I would liek to try that
>> out.
>>
>> No, I said that an environment variable can override the mechanism
>> that blocks ensemble changes in mdrun.
>>
>> So how can I use this environment variable.. I might be asking an absurd
>> question since I don't really understand what an environment variable is.
>> But I would definitely liek to experiment with it, since I am in the process
>> of trying out these different options and figuring out which would be the
>> best.
>>
>>
>
> http://en.wikipedia.org/wiki/Environment_variable
>
> I think the pertinent one in this case is GMX_ALLOW_CPT_MISMATCH. There is
> a reason these aren't well-documented; they probably shouldn't be used in
> most cases. You should have seen a very specific error message in your .log
> file or screen output indicating that this situation was relevant
> (src/gmxlib/checkpoint.c, around line 1606).
>
>
> I also need to understand something. What exactly does the tpbconv do when
>> only -s and -nsteps or -extend options are supplied - it seems that it takes
>> all the information(mass, topology, restraints) from the previous tpr file
>> and just changes the init_step parameter and the number of steps till which
>> the simulation should run.
>>
>>
>
> All it does is modify the number of steps specified in the input file;
> init_step should be untouched. The step from which the simulation is
> continued is in the .cpt file.
>
>
> Now if that is the case, I am still unable to understand that if the cpt
>> file is NOT provided to mdrun (or a mismatched one is provided), how does
>> mdrun obtain the coordinates, velocities, box-dimensions of the last frame.
>> If it doesn't use the ones of the last frame, what does it really use?
>>
>>
>
> These are two cases. If (1) an invalid .cpt file is provided, the
> simulation should stop with a fatal error (in checkpoint.c, described
> above); if (2) a checkpoint is not provided at all, then a completely new
> simulation is started, and the "last frame" is non-existent. The simulation
> begins at time zero.
>
>
> If it gets them from the new_tpr file, and the new_tpr file gets it from
>> previous_tpr file via tpbconv, then how does that ensure continuation from
>> the last frame, because the previous_tpr file might have been compiled even
>> before the simulation started. And as far as I know, it is purely an input
>> file to mdrun and has no information on the last coordinates/velocities of
>> the mdrun.
>>
>
> If you provide a .tpr file to mdrun and the checkpoint file is invalid, the
> simulation should have stopped, per the fatal error given in checkpoint.c
> (described above). The contents of your .log file should make clear exactly
> what mdrun is doing and where it's starting.
>
In my case, I use tpbconv with just nsteps and old_tpr and supply the
exchanged .cpt file. Mdrun does not crash, but none of the files get
appended. All files start from the first continuation step. The logfile has
no error. Same is the case with the #rexlog0.log# file which is the logfile
which gets overwritten. I don't know what conclusion to draw - would it make
sense to compare the last frame in the .cpt file and the first frame in the
new xtc file? Should they match if the cpt file has infact been used by
mdrun?
Pooja
>
> In the case you describe, "new.tpr" and "previous.tpr" differ only in the
> number of steps, therefore the state contained therein corresponds to the
> beginning of the simulation, i.e. time zero.
>
> -Justin
>
>
> You may have answered this before but I have tried and failed in
>> understanding. I would request you to help me in understanding the above. I
>> would really appreciate it.
>> Regards
>> Pooja
>>
>>
> --
> ========================================
>
> 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://lists.gromacs.org/pipermail/gmx-users/attachments/20110202/0d6a7220/attachment-0001.html
------------------------------
Message: 2
Date: Wed, 2 Feb 2011 19:13:21 -0500
From: Sai Pooja <saipooja at gmail.com>
Subject: Re: [gmx-users] mdrun with append option
To: jalemkul at vt.edu, Discussion list for GROMACS users
<gmx-users at gromacs.org>
Message-ID:
<AANLkTimt2Hosa=91CxM+LituXqdn3-V9phO9wibRE7fA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Feb 2, 2011 at 6:49 PM, Sai Pooja <saipooja at gmail.com> wrote:
> Thanks Justin for being so patient. I have understood almost everything and
> I hope this is the last question on this thread.
>
> See inline ...
> On Wed, Feb 2, 2011 at 5:53 PM, Justin A. Lemkul <jalemkul at vt.edu> wrote:
>
>>
>>
>> Sai Pooja wrote:
>>
>> On Wed, Feb 2, 2011 at 3:15 PM, Mark Abraham <Mark.Abraham at anu.edu.au<mailto:
>>> Mark.Abraham at anu.edu.au>> wrote:
>>>
>>> On 3/02/2011 6:15 AM, Sai Pooja wrote:
>>>
>>> The problem is solved with grompp i.e. I use the -t .cpt option.
>>> However, now appending does not work. I remember Mark said in a
>>> previous mail that a certain environment variable can allow
>>> appending to happen even in such cases. I would liek to try that
>>> out.
>>>
>>> No, I said that an environment variable can override the mechanism
>>> that blocks ensemble changes in mdrun.
>>>
>>> So how can I use this environment variable.. I might be asking an absurd
>>> question since I don't really understand what an environment variable is.
>>> But I would definitely liek to experiment with it, since I am in the process
>>> of trying out these different options and figuring out which would be the
>>> best.
>>>
>>>
>>
>> http://en.wikipedia.org/wiki/Environment_variable
>>
>> I think the pertinent one in this case is GMX_ALLOW_CPT_MISMATCH. There
>> is a reason these aren't well-documented; they probably shouldn't be used in
>> most cases. You should have seen a very specific error message in your .log
>> file or screen output indicating that this situation was relevant
>> (src/gmxlib/checkpoint.c, around line 1606).
>>
>>
>> I also need to understand something. What exactly does the tpbconv do when
>>> only -s and -nsteps or -extend options are supplied - it seems that it takes
>>> all the information(mass, topology, restraints) from the previous tpr file
>>> and just changes the init_step parameter and the number of steps till which
>>> the simulation should run.
>>>
>>>
>>
>> All it does is modify the number of steps specified in the input file;
>> init_step should be untouched. The step from which the simulation is
>> continued is in the .cpt file.
>>
>>
>> Now if that is the case, I am still unable to understand that if the cpt
>>> file is NOT provided to mdrun (or a mismatched one is provided), how does
>>> mdrun obtain the coordinates, velocities, box-dimensions of the last frame.
>>> If it doesn't use the ones of the last frame, what does it really use?
>>>
>>>
>>
>> These are two cases. If (1) an invalid .cpt file is provided, the
>> simulation should stop with a fatal error (in checkpoint.c, described
>> above); if (2) a checkpoint is not provided at all, then a completely new
>> simulation is started, and the "last frame" is non-existent. The simulation
>> begins at time zero.
>>
>>
>> If it gets them from the new_tpr file, and the new_tpr file gets it from
>>> previous_tpr file via tpbconv, then how does that ensure continuation from
>>> the last frame, because the previous_tpr file might have been compiled even
>>> before the simulation started. And as far as I know, it is purely an input
>>> file to mdrun and has no information on the last coordinates/velocities of
>>> the mdrun.
>>>
>>
>> If you provide a .tpr file to mdrun and the checkpoint file is invalid,
>> the simulation should have stopped, per the fatal error given in
>> checkpoint.c (described above). The contents of your .log file should make
>> clear exactly what mdrun is doing and where it's starting.
>>
>
They do infact match! So mdrun starts from the checkpoint file provided!
Files do not get appended but runs are in continuation.
Thanks!
Pooja
>
>
> In my case, I use tpbconv with just nsteps and old_tpr and supply the
> exchanged .cpt file. Mdrun does not crash, but none of the files get
> appended. All files start from the first continuation step. The logfile has
> no error. Same is the case with the #rexlog0.log# file which is the logfile
> which gets overwritten. I don't know what conclusion to draw - would it make
> sense to compare the last frame in the .cpt file and the first frame in the
> new xtc file? Should they match if the cpt file has infact been used by
> mdrun?
>
> Pooja
>
>
>>
>> In the case you describe, "new.tpr" and "previous.tpr" differ only in the
>> number of steps, therefore the state contained therein corresponds to the
>> beginning of the simulation, i.e. time zero.
>>
>> -Justin
>>
>>
>> You may have answered this before but I have tried and failed in
>>> understanding. I would request you to help me in understanding the above. I
>>> would really appreciate it.
>>> Regards
>>> Pooja
>>>
>>>
>> --
>> ========================================
>>
>> 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.
>
--
Quaerendo Invenietis-Seek and you shall discover.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.gromacs.org/pipermail/gmx-users/attachments/20110202/ad84be0a/attachment.html
------------------------------
--
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!
End of gmx-users Digest, Vol 82, Issue 29
*****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-users/attachments/20110203/bb0c9beb/attachment.html>
More information about the gromacs.org_gmx-users
mailing list