> On Feb 5, 2015, at 6:49 AM, Hadeer ELHabashy <hadeer.elhabashi.gmail.com> wrote:
>
> Dear Sir
>
> wish you are fine !
>
> I am running a MDS protocol on a protein in a water box expecting some
> conformational changes. I've got some favorable conformation changes
> started with starting the simulation and continues until 100 ns of
> simulation and beyond . with the following protocol
>
> 1- 800 steps of minimization round 1 with restrains
> &cntrl
> imin=1, nmropt=0,
> ntx=1, irest=0,
> ntxo=1, ntpr=100, ntrx=1, ntwr=100,
> iwrap=0, ntwx=100, ntwv=0, ntwe=0,
> ioutfm=0, ntwprt=0, idecomp=0,
> ntf=2, ntb=1, igb=0, nsnb=1,
> ipol=0, gbsa=0, iesp=0,
> dielc=1.0, cut=10.0, intdiel=1.0,
> maxcyc=800, ncyc=100, ntmin=1,
> dx0=0.0010, drms=0.00010,
> nstlim=0, nscm=2, nrespa=1,
> t=0.0, dt=0.001, vlimit=20.0,
> ntc=2, jfastw=0, tol=0.00001,
> Tempi=0.0, Temp0=0.0, ntt=1, tautp=0.5,
> ntp=0, taup=1.0,
> ibelly=0, ntr=1,
> restraint_wt=5.0, restraintmask=':1-175',
> &end
>
>
> 2- heating up to 100 K
> &cntrl
> imin=0, nmropt=0,
> ntx=1, irest=0,
> ntxo=1, ntpr=100, ntrx=1, ntwr=100,
> iwrap=0, ntwx=100, ntwv=0, ntwe=0,
> ioutfm=0, ntwprt=0, idecomp=0,
> ntf=2, ntb=2, igb=0, nsnb=1,
Why do you set nsnb=1 here? This is a variable best left at its default.
> ipol=0, gbsa=0, iesp=0,
> dielc=1.0, cut=10.0, intdiel=1.0,
> nstlim=50000, nscm=2, nrespa=1,
> t=0.0, dt=0.001, vlimit=20.0,
> ntc=2, jfastw=0, tol=0.00001,
> Tempi=0.0, Temp0=100.0, ntt=3, tautp=0.5, gamma_ln=2.0,
> pres0=1.0, ntp=1, taup=1.0,
> ibelly=0, ntr=1,
> restraint_wt=5.0, restraintmask=':1-175',
> &end
>
>
> 3- 800 steps of minimization round 2 without restrains
> &cntrl
> imin=1, nmropt=0,
> ntx=1, irest=0,
> ntxo=1, ntpr=100, ntrx=1, ntwr=100,
> iwrap=0, ntwx=100, ntwv=0, ntwe=0,
> ioutfm=0, ntwprt=0, idecomp=0,
> ntf=2, ntb=1, igb=0, nsnb=1,
> ipol=0, gbsa=0, iesp=0,
> dielc=1.0, cut=10.0, intdiel=1.0,
> maxcyc=800, ncyc=100, ntmin=1,
> dx0=0.0010, drms=0.00010,
> nstlim=0, nscm=2, nrespa=1,
> t=0.0, dt=0.001, vlimit=20.0,
> ntc=2, jfastw=0, tol=0.00001,
> Tempi=100.0, Temp0=100.0, ntt=1, tautp=0.5,
> ntp=0, taup=1.0,
> ibelly=0, ntr=0,
> &end
>
>
> 4- heating up to 310 (over 9 rounds each of 50 ps and heating upto 25 K
> except the last step) with restrains
> &cntrl
> imin=0, nmropt=0,
> ntx=1, irest=0, ntrx=1,
> ntxo=1, ntpr=100, ntrx=1, ntwr=100,
> iwrap=0, ntwx=100, ntwv=0, ntwe=0,
> ioutfm=0, ntwprt=0, idecomp=0,
> ntf=2, ntb=2, igb=0,
> ipol=0, gbsa=0, iesp=0,
> dielc=1.0, cut=10.0, intdiel=1.0,
> nstlim=50000, nscm=2, nrespa=1,
> t=0.0, dt=0.001, vlimit=20.0,
> ntc=2, jfastw=0, tol=0.00001,
> Tempi=100.0 , Temp0=125.0 , ntt=3, tautp=0.01, gamma_ln=2,
> pres0=1.0, ntp=1, taup=0.05,
> ibelly=0, ntr=1,
> restraint_wt=5.0, restraintmask=':1-175',
> &end
>
> 5- production MD
> &cntrl
> imin=0, nmropt=0,
> ntx=5, irest=1, ntrx=1,
> ntxo=1, ntpr=500, ntwr=500,
> iwrap=1, ntwx=500, ntwv=0, ntwe=0,
> ioutfm=0, ntwprt=0, idecomp=0,
> ntf=2, ntb=2, igb=0,
> ipol=0, gbsa=0, iesp=0,
> dielc=1.0, cut=10.0, intdiel=1.0,
> ibelly=0, ntr=0,
> nstlim=50000, nscm=500, nrespa=1,
> t=0.0, dt=0.002, vlimit=20.0,
> ntc=2, jfastw=0, tol=0.00001,
> Tempi=310.0, Temp0=310.0, ntt=3, tautp=0.5, gamma_ln=2,
> pres0=1.0, ntp=1, taup=2.0,
> &end
>
>
> The question now : depending on the mentioned protocol
> can you see any failure in the pervious protocol ?
Not at quick glance, but these input files are too long to do a careful study of them. You set many variables that you don’t use to their default value (like ntwe=0 and ntwv=0, to name two), along with other variables that I’ve never used before and an unfamiliar with (e.g., iesp=0, t=0.0, and I can never remember the difference between jfastw=0 and jfastw=4), which makes it difficult to grok your input files.
If these input files work for you, that’s great. But if you plan on requesting an audit of your input files -- either from here or someone else -- you should simplify them as much as possible so that every variable that you specify is significant to your simulation. That makes it easier for the people from whom you ask for help and increases the likelihood that they will find a mistake if you made one.
> can I consider these changes in protein conformation as real time events ?
Maybe. It could also be a force field artifact or some other artifact of your system setup. You would know better than us if that was likely or if what you are seeing seems reasonable.
> what are the parameters of the MD control file that can decelerate or
> accelerate a real time event ?
You can *accelerate* stuff using enhanced sampling techniques, like accelerated MD, umbrella sampling, steered MD, or replica exchange (to name a few approaches). These are advanced topics, though, so you would need to invest time into learning the underlying theory behind the methods as well as learning how to run and analyze the simulations in Amber. I’m not sure why anybody would ever want to decelerate sampling, and there’s no way to really do that. You could, of course, drop the temperature very low so everything moves slower, increase the mass of every atom to get a similar effect, or decrease the time step so each *MD* step doesn’t move as far in time (limiting how *far* it can move). But the first two changes the system you’re studying so that the final answers will not necessarily be the same, and the last doesn’t actually make the sampling go any slower per ns of simulation; it just makes each ns of simulation take more steps to complete.
> does the applied shake ,providing that all the bond interaction involving
> hydrogen bonding are omitted, affect the real time event ?
It’s unclear what “effects” you are curious about. It certainly affects any events dependent on H- bond vibrations, but no examples come to my mind. For most events, I don’t think SHAKE has a significant effect (except in cases where it is required, like with the TIPnP rigid water models).
HTH,
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Feb 05 2015 - 05:00:02 PST
