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
========================================
--
gmx-users mailing list gmx-users@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-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
