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 <jalem...@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@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-requ...@gromacs.org. > Can't post? Read > http://www.gromacs.org/**Support/Mailing_Lists<http://www.gromacs.org/Support/Mailing_Lists> >
-- 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
