[gmx-users] Periodic Images - clarification

Kavyashree M hmkvsri at gmail.com
Mon Jun 27 05:59:02 CEST 2011 

Sir,

Thank you Sir for your suggestions. Probably the stability of the
protein may be known only after simulation. But actually it from
one of the thermophilic organisms - Thermatoga maritima. So I
did not anticipate unfolding at 300K.

Ur suggestions were very useful. Thanks. :)

With Regards
M. Kavyashree

On Sun, Jun 26, 2011 at 9:11 PM, Justin A. Lemkul <jalemkul at vt.edu> wrote:

>
>
> Kavyashree M wrote:
>
>>
>> Sir,
>>  I would like to thank you for patiently replying for my repeatedly asked
>> question.
>>
>>
>>    For most stable, well-behaved proteins, setting a suitable box size
>>    at the outset of the simulation is sufficient to avoid spurious PBC
>>    interactions.  In your case, there are several possibilities: (1)
>>    the protein is not well-behaved, (2) you didn't set the box you
>>    think you did, (3) the .mdp settings are wrong and lead to
>>    instability, or (4) your pressure coupling settings cause the box to
>>    shrink unreasonably.
>>
>>  1. protein is not well behaved - This point I dont know how to quantify.
>>
>
> It's not necessarily something you can quantify, it's more of a qualitative
> measure in many cases and comes from anticipating what the system may do.
>  Not all proteins are stably folded.  Some may unfold, others may have
> multiple domains that will move along hinge regions, causing the protein to
> expand its size, etc.  The initial box size assumes that large changes in
> the structure will not occur.  Sometimes this assumption is not good.
>
>
>  2. Box dimensions - I repeated from the model, editconf gave the same box
>> dimensions which I had used earlier but did not      repeat the NVT. and the
>> distance -d between wall of box and protein atom was kept as 1.0nm while the
>> max cut of used was
>>   1.4nm.
>> 3. I am attaching the mdp file.
>> 4. I checked the whole trajectory for change in box size with the output
>> of g_energy. But did not find and abrupt deviations
>>
>>
>
> OK.
>
>
>
>>    If you want to use the first 26 ns only, I suppose these data are
>>    legitimate, although then several questions arise.  Why did you run
>>    100 ns in the first place?  Presumably you felt that you needed such
>>    a simulation length to address whatever question you're asking, so
>>    is 26 ns legitimate, or is it simply convenient because you don't
>>    want to run the simulation again?  Also, why trust these results
>>    when you know that just a short time later these dynamics produced
>>    flawed information?  The PBC violation may not have simply happened
>>    suddenly; maybe it was a product of some long-term motion in the
>>    system that was continually trending towards disaster.
>>
>>  I did not anticipate such a violation would as it did not happen in other
>> cases. so I did not check the minimum image violation
>> while running the simulation but caculated after 100ns. I agree it was my
>> stupidity. Because of time constraints and system unavailability now I might
>> not be able to run another simulation. But I will be running it later with
>> corrected parameters for sure.
>>
>> I agree that it is producing flawed results. But My point was if at all it
>> was caused only due to the box dimension being smaller
>> and not due to any wrong parameters used why is that 26ns wrong. Probably
>> if I had selected a bigger box size may be that
>> loop would have continued to move without minimum image violation.
>>
>>    The biggest question is, if you run the simulation again (which you
>>    should, but only after answering the four points above and the
>>    following), how do you know the same thing won't happen again?
>>     You've been asking related questions for weeks and I still do not
>>    know if you have followed my repeated advice to watch the trajectory
>>    with a PBC unit cell enabled in your favorite visualization program
>>    and, in concert with the identified problematic atoms in the
>>    g_mindist output, identify where and why the minimum image violation
>>    occurred.  Doing so should take minutes and you should immediately
>>    see what went wrong, which would be valuable information for
>>    avoiding such behavior in the future.  If you have done this, you've
>>    posted no evidence of your findings and thus just wasted weeks
>>    posting the same (or tangentially related) questions with no answer,
>>    time that could have been spent running a proper simulation to
>>    recover what you lost.
>>
>>
>> If I am running again I would increase the box size and run. I did what
>> you had suggested.  I visualized that part of trajectory
>> in VMD (which I am not very comfortable with ) and could see a loop
>> movement coming closer to it periodic image. but
>> unfortunately because of my lack of know-how I was unable to measure the
>> distance between them in VMD. I could only visualixe the loop movement but I
>> am unable to produce and concrete outputs for my observation.
>>
>>
>
> It seems you have identified the source of the problem then.  If you have a
> large, unpredictable loop region, then you need to account for the fact that
> it might do funny things throughout the simulation.  In this case, maybe
> your 26 ns is useful, but my point is that if you thought 100 ns was needed
> to answer your question of interest, then you still probably need to do a
> new simulation.
>
> Also realize that the results of just a single simulation is usually not
> sufficient to derive converged quantities.  What if your one simulation is
> the outlier in the sample set?  You have no way to know if you've done just
> one simulation.
>
>
> -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<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<http://lists.gromacs.org/mailman/listinfo/gmx-users>
> Please search the archive at http://www.gromacs.org/**
> Support/Mailing_Lists/Search<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<http://www.gromacs.org/Support/Mailing_Lists>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-users/attachments/20110627/3a53b6b8/attachment.html>

More information about the gromacs.org_gmx-users mailing list