1)thanks Kristina, for your sharing of these information.
since ibelly=1, works in your NVE MD by pmemd, and works in my NTP MD by sander, but why not work in my NTP MD by pmemd?
2)in your nmropt=1 and ibelly=1 input file, try to put another "&end" or "/" just after your line of "DISANG=Dummy.rst", then possibly will read in all your input.
3)I am gzipping my files, and I will send to you: Bob Duke.
all the best
xiaoqin
07/20/2009
> From: Kristina.Furse.1.nd.edu
> To: amber.ambermd.org
> Date: Mon, 20 Jul 2009 12:56:26 -0400
> Subject: RE: [AMBER] question of ibelly used in pmemd
>
>
> > what I doubt now is not the nmropt=1 in pmemd, I doubt ibelly=1 can be used in pmemd or not.
>
> This is not the case--I am running pmemd w/belly as we speak, with the following input:
>
> DNA/counarin: 100ps NVE MD belly
> &cntrl
> imin = 0, irest = 1, ntx = 7,
> ntb = 1,
> ntt = 0,
> cut = 10,
> ntc = 2, ntf = 2,
> tol = 0.0000001,
> ntr = 0,
> ibelly = 1,
> iwrap = 1,
> nstlim = 50000, dt = 0.002,
> ntpr = 100, ntwx = 50, ntwr = 1000
> /
> Movable belly for water and ions
> RES 25 9985
> END
> END
>
> Works just fine. I did run into a problem when I tried to run ibelly=1 and nmropt=1, though. Unlike Xiaoqin, it was a problem reading in the input, not with the simulation itself. I wasn't using any actual nmr distance restraints, I just wanted a temperature ramp so I used the nmr weights with a dummy (empty) DISANG file, as follows:
>
> DNA: 50ps NVT MD with temperature ramp
> &cntrl
> imin = 0, irest = 0, ntx = 1,
> ntb = 1,
> ntt = 1, tautp = 0.2,
> tempi = 0.0, temp0 = 300.0, nmropt = 1,
> cut = 10,
> ntc = 2, ntf = 2,
> ibelly = 1,
> iwrap = 1,
> nstlim = 25000, dt = 0.002,
> ntpr = 100, ntwx = 100, ntwr = 1000
> /
> &wt
> type='TEMP0', istep1=0, istep2=10000,
> value1=0.0, value2=300.0,
> /
> &wt
> type='TEMP0', istep1=10000, istep2=25000,
> value1=300.0, value2=300.0,
> /
> &wt
> type='END',
> /
> DISANG=Dummy.rst
> Movable belly for water and ions
> RES 25 9985
> END
> END
>
> This input file works fine in sander, but pmemd did not parse it correctly. Unfortunately, I deleted the output file a couple of days ago, and can't run another test right now b/c of issues with our cluster, but I believe it was trying to interpret the "DISANG=Dummy.rst" line as belly group input, and never read in the weight changes. I can re-run the test as soon as our cluster problems are resolved. Bob--I'm not sure why Xiaoqin's input was read in and mine wasn't, but I can look into that too.
>
> Kristina
>
>
>
> > From: rduke.email.unc.edu
> > To: amber.ambermd.org
> > Subject: Re: [AMBER] question of ibelly used in pmemd
> > Date: Mon, 20 Jul 2009 11:53:50 -0400
> >
> > Well, okay, but I then can't verify/identify/fix the problem if you don't
> > send me the system. Also, I find a 140K temperature drop in one step to be
> > a little strange... As I say, it is possible that all aspects of the nmr
> > restraints have not been checked out in the pmemd code, simply because I
> > don't have test cases (this is a complaint I have had about our test suites
> > for some time; since I don't use nmr restraints myself, I am not going to
> > develop test cases). I would appreciate it if other folks who actually work
> > with nmr restraints look at this system and see if they notice anything a
> > bit unusual about it, or if some rarely tested code is being run here. I
> > would also note that the minute you use nmropt = 1, pmemd speedup is reduced
> > because I don't do the standard pmemd system decomposition, but instead
> > behave more like sander. This was done precisely because I did not have
> > test cases... I have modified the (ancient) nmr code to the minimum extent
> > possible.
> > Regards - Bob Duke
> > ----- Original Message -----
> > From: "xiaoqin huang" <xqhuang1018.msn.com>
> > To: <amber.ambermd.org>
> > Sent: Monday, July 20, 2009 11:20 AM
> > Subject: RE: [AMBER] question of ibelly used in pmemd
> >
> >
> >
> > I first used sander for the same system, it has run well. Actually I used
> > sander routinely with the same input file, i.e NMR restratint, ibelly
> > groups.
> >
> > I tried to switch from sander to pmemd is that it is said pmemd is better
> > paralleled and faster than sander, so I hoped that I would get the same
> > output within much less time. but now I wasted so much time.
> >
> > so I tested pmemd, and at the same time keep running sander for the same
> > system, and I already got what I want from running sander.
> >
> > p.s. the T=444.30 at the fist step (NSTEP=0) of output by pmemd is the same
> > as that of the output by sander as I set ntx=1, irest=0,ig=2858, then sander
> > outputs:
> > NSTEP = 2 TIME(PS) = 200.002 TEMP(K) = 298.08
> >
> > please see the attached file for the output of pmemd.
> >
> >
> >
> >
> > > From: rduke.email.unc.edu
> > > To: amber.ambermd.org
> > > Subject: Re: [AMBER] question of ibelly used in pmemd
> > > Date: Mon, 20 Jul 2009 10:42:15 -0400
> > >
> > > The IMPORTANT question is: Does sander work, or not, in the same
> > > situation?
> > > The distinction we are looking for is whether or not there is a possible
> > > bug
> > > in pmemd. Given your initial conditions, with the temperature at 444 or
> > > whatever it is, and a rapid rise in one step, there is a very high
> > > probability that there is a problem not with pmemd, but with your model
> > > system. The only reason I am marginally unsure is there is some
> > > possibility
> > > in some untested aspect of the nmr code in pmemd. If that is the case,
> > > sander would work, and pmemd wouldn't. So if you want help, either do the
> > > test I am asking you to do, or send me the system...
> > > Regards - Bob Duke
> > > ----- Original Message -----
> > > From: "xiaoqin huang" <xqhuang1018.msn.com>
> > > To: <amber.ambermd.org>
> > > Sent: Monday, July 20, 2009 10:21 AM
> > > Subject: RE: [AMBER] question of ibelly used in pmemd
> > >
> > >
> > >
> > > thanks for your reply for so much detail!
> > >
> > > actually, the pmemd (amber 9), DOES NOT work (MD simulations) with
> > > ibelly=1.
> > >
> > > When only ibelly=1, without any other restraints (no NMR restraints), it
> > > read in correctly all the information of input file, but the MD simulation
> > > started with big fluctuations of Etot in the output, and then died.
> > >
> > > other information about my previous email
> > > 1) "533-150000" equals "533-100441" (actual number of residues of the
> > > system), as the code can read in and reset the NRES;
> > > 2) I changed cutoff=15, into es_cutoff=8.0, and vdw_cutoff=9.0, things
> > > came
> > > out the same, i.e. after 16 steps with big fluctuations in Etot, then
> > > died;
> > > 3) the starting 444K was because I set ntx=1, irest=0,ig=2858, ie. no
> > > initial velocity in inte input coordinate file.
> > > 4) the number of processors I used was 8.
> > >
> > >
> > > xiaoqin
> > > 07/20/2009
> > >
> > >
> > >
> > >
> > > > From: rduke.email.unc.edu
> > > > To: amber.ambermd.org
> > > > Subject: Re: [AMBER] question of ibelly used in pmemd
> > > > Date: Fri, 17 Jul 2009 11:48:41 -0400
> > > >
> > > > Okay, there is an &end on line 23 of tus1.in that I believe is
> > > > unnecessary,
> > > > but I don't think it is causing any problems. However I notice that the
> > > > last
> > > > entry in your "belly group" residue listing, on line 49, specifies
> > > > residues
> > > > 533-150000. That happens to be roughly 49,000 more residues than your
> > > > system has... (the NRES printed out in your mdout says your system has
> > > > 100,441 residues and 308,147 atoms). I would suspect that the group
> > > > reading
> > > > code in pmemd as well as sander may have a bit of trouble with this,
> > > > though
> > > > maybe I am wrong (well I looked, and it seems the code can, at least on
> > > > a
> > > > quick read, reset any excessive residue numbers to nres; I would still
> > > > not
> > > > do this) Another point, you specify a cutoff of 15 in your mdin for an
> > > > ewald
> > > > run. This should work, but has no benefit whatsoever. In fact, you are
> > > > probably running about six times slower than you really need to because
> > > > of
> > > > this large cutoff, and consuming 6x as much memory in the pairlists.
> > > > The
> > > > whole idea of particle mesh ewald, the default electrostatics method in
> > > > pmemd or sander, is to combine a small direct space calc (ie., a short
> > > > default direct space cutoff) with a reciprocal space calc on the rest of
> > > > the
> > > > unit cell in order to get an electrostatics calc fully representing the
> > > > system with no effective cutoff, accurate to 4-5 decimal places, and
> > > > more
> > > > efficient (and accurate) than a pure cutoff system with a longer cutoff.
> > > > Here, specifying a 15 angstrom cutoff, you are pretty much shooting
> > > > yourself
> > > > in the foot and wasting computer time. If you want better vdw numbers
> > > > than
> > > > provided by the 8 angstrom default, you can specify a longer cutoff of
> > > > say
> > > > 9
> > > > angstroms; that combined with the default analytic vdw correction
> > > > (vdwmeth
> > > > 1) will give you reasonable accuracy for your vdw numbers. So looking
> > > > at
> > > > the output, you start hot (~444K) and quickly are heating further, I
> > > > really
> > > > don't know what may be wrong with the system, and would have to do a
> > > > bunch
> > > > more work with the whole system to know whether what you are
> > > > experiencing
> > > > is
> > > > caused by a bad system, bad input, or a bug. Once again, what happens
> > > > with
> > > > sander? The output on group reads, nmr redirs, etc. looks like
> > > > everything
> > > > was read fine in pmemd, but I really can't be sure based on the info I
> > > > have.
> > > > I would try the smaller cutoff (just remove cut = 15 and you will
> > > > default
> > > > to
> > > > 8) on a whim; it will greatly reduce your memory usage, and if you are
> > > > running this on 8 cpu's in one box with limited memory (it is a big
> > > > system),
> > > > that could help. But I still think that given that you start at 444K
> > > > for
> > > > a
> > > > temp, you may have a basic system problem here, that will have to be
> > > > fixed
> > > > by starting over and very carefully considering what you are doing.
> > > > - Bob Duke
> > > > ----- Original Message -----
> > > > From: "xiaoqin huang" <xqhuang1018.msn.com>
> > > > To: <amber.ambermd.org>
> > > > Sent: Friday, July 17, 2009 10:54 AM
> > > > Subject: RE: [AMBER] question of ibelly used in pmemd
> > > >
> > > >
> > > >
> > > > thanks, but I still have question about pmemd run
> > > > here I attached again the modified input and output of pmemd (amber 9),
> > > > please help me to figure out what is wrong over there.
> > > > >From the output file, I found that the ibelly groups were read in, and
> > > > >the
> > > > >MD got started, but still something is wrong over there when compare
> > > > >the
> > > > >energy terms of the first step in output file with those in the output
> > > > >of
> > > > >sander runs for the same system.
> > > > and after several steps, it stoped.
> > > >
> > > > so even the ibeely group was read in, but I donot know how it was
> > > > parsed.
> > > >
> > > >
> > > >
> > > >
> > > > > From: rduke.email.unc.edu
> > > > > To: amber.ambermd.org
> > > > > Subject: Re: [AMBER] question of ibelly used in pmemd
> > > > > Date: Wed, 15 Jul 2009 17:56:00 -0400
> > > > >
> > > > > You have to use the group format like it says. I believe you need to
> > > > > put
> > > > > the
> > > > > nmr redirection stuff after the last namelist, and then list your
> > > > > belly
> > > > > restraints. The *.in you gave in your earlier mail does not look
> > > > > correct
> > > > > to
> > > > > me, in that the group input does not start with a comment card; you
> > > > > may
> > > > > have
> > > > > to look at the doc on GROUP input again.
> > > > > Regards - Bob Duke
> > > > > ----- Original Message -----
> > > > > From: "xiaoqin huang" <xqhuang1018.msn.com>
> > > > > To: <amber.ambermd.org>
> > > > > Sent: Wednesday, July 15, 2009 5:28 PM
> > > > > Subject: RE: [AMBER] question of ibelly used in pmemd
> > > > >
> > > > >
> > > > >
> > > > > thanks for reply, and I tested:
> > > > > 1) without nmropt=1, without ibelly=1, i.e. no restraints, no
> > > > > freezing,
> > > > > just
> > > > > regular MD.
> > > > > the outputs of both sander and pmemd are the same;
> > > > > 2) with nmropt=1, but without ibelly=1, i.e. restraints, but no
> > > > > freezing,
> > > > > the restrained MD.
> > > > > the outputs of both sander and pmemd are the same;
> > > > > 3) with nmropt=1, with ibelly=1, i.e. restraints, and freezing, do
> > > > > the
> > > > > MD
> > > > > again,
> > > > > when bellymask used, the error message is:
> > > > > "ERROR: PMEMD 9 does not support bellymask option! Please use
> > > > > Amber
> > > > > 6/7 GROUP format instead".
> > > > > when the Amber 6/7 GROUP format is used, i.e. the input file I
> > > > > attached in the previous email, the same error as described in my
> > > > > previous
> > > > > email happened.
> > > > > -------------------------------------------------------------
> > > > > so, how to put ibelly=1 (group list or bellymask) in the input file
> > > > > that
> > > > > can
> > > > > be read in correctly by pmemd?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > From: rduke.email.unc.edu
> > > > > > To: amber.ambermd.org
> > > > > > Subject: Re: [AMBER] question of ibelly used in pmemd
> > > > > > Date: Wed, 15 Jul 2009 14:22:23 -0400
> > > > > >
> > > > > > If you take the exact same system, run it in sander, and run it in
> > > > > > pmemd,
> > > > > > it
> > > > > > should do the exact same thing for about 300-500 steps; then the
> > > > > > systems
> > > > > > will diverge due to rounding errors in the algorithms (which is of
> > > > > > no
> > > > > > concern - just different regions in phase space). So, is this what
> > > > > > you
> > > > > > are
> > > > > > doing? If so, then it is likely their is some software installation
> > > > > > problem
> > > > > > or hardware problem. Did pmemd pass the amber test suite on your
> > > > > > machine?
> > > > > > It should. Okay, all that said, I looked at your mdin, and you have
> > > > > > a
> > > > > > pretty complex setup, involving both belly and nmr restraints.
> > > > > > There
> > > > > > is
> > > > > > some possibility this is not being parsed exactly correctly in
> > > > > > pmemd,
> > > > > > but
> > > > > > I
> > > > > > think it is probably okay (I hardly ever use nmr restraints, so
> > > > > > someone
> > > > > > more
> > > > > > familiar may want to look at how that is being used here). Looking
> > > > > > at
> > > > > > the
> > > > > > output, what I see primarily is that the run goes for over 10 steps,
> > > > > > but
> > > > > > then there is an end-of-file on the restrt file; I am wondering if
> > > > > > you
> > > > > > had
> > > > > > a
> > > > > > hardware issue of some sort here... I would retry with both sander
> > > > > > and
> > > > > > pmemd, but for 10 steps, dumping output with each step (ntpr = 1),
> > > > > > and
> > > > > > see
> > > > > > if there are any differences between pmemd and sander.
> > > > > > Regards - Bob Duke
> > > > > > ----- Original Message -----
> > > > > > From: "xiaoqin huang" <xqhuang1018.msn.com>
> > > > > > To: <amber.ambermd.org>
> > > > > > Sent: Wednesday, July 15, 2009 1:34 PM
> > > > > > Subject: [AMBER] question of ibelly used in pmemd
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi, users,
> > > > > > I have a question about ibelly=1 used in pmemd simulations.
> > > > > > the situation is that I want to freeze some part of residues/atoms
> > > > > > of
> > > > > > the
> > > > > > system, so I used the ibelly=1 in the sander, it works well no
> > > > > > matter
> > > > > > which
> > > > > > version (8, 9, 10).
> > > > > > when I used the same ibelly=1 in the pmemd (amber 9), the MD runs
> > > > > > and
> > > > > > then
> > > > > > stopped with the message as vlimit exceeded for step 1...
> > > > > > here attached is the input file, output file and the error message.
> > > > > > any suggestions or comments? thanks!
> > > > > >
> > > > > > xiaoqin
> > > > > >
> > > > > > 09/15/2009
> > > > > >
> > > > >
> > > > > _________________________________________________________________
> > > > > Insert movie times and more without leaving Hotmail®.
> > > > > http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd_062009_______________________________________________
> > > > > AMBER mailing list
> > > > > AMBER.ambermd.org
> > > > > http://lists.ambermd.org/mailman/listinfo/amber
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > AMBER mailing list
> > > > > AMBER.ambermd.org
> > > > > http://lists.ambermd.org/mailman/listinfo/amber
> > > >
> > > > _________________________________________________________________
> > > > Windows Live™: Keep your life in sync.
> > > > http://windowslive.com/explore?ocid=TXT_TAGLM_WL_BR_life_in_synch_062009
> > > >
> > > >
> > > > --------------------------------------------------------------------------------
> > > >
> > > >
> > > > > _______________________________________________
> > > > > AMBER mailing list
> > > > > AMBER.ambermd.org
> > > > > http://lists.ambermd.org/mailman/listinfo/amber
> > > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > AMBER mailing list
> > > > AMBER.ambermd.org
> > > > http://lists.ambermd.org/mailman/listinfo/amber
> > >
> > > _________________________________________________________________
> > > Windows Live™ Hotmail®: Celebrate the moment with your favorite sports
> > > pics.
> > > Check it out.
> > > http://www.windowslive.com/Online/Hotmail/Campaign/QuickAdd?ocid=TXT_TAGLM_WL_QA_HM_sports_photos_072009&cat=sports_______________________________________________
> > > AMBER mailing list
> > > AMBER.ambermd.org
> > > http://lists.ambermd.org/mailman/listinfo/amber
> > >
> > >
> > >
> > > _______________________________________________
> > > AMBER mailing list
> > > AMBER.ambermd.org
> > > http://lists.ambermd.org/mailman/listinfo/amber
> >
> > _________________________________________________________________
> > Windows Live™ Hotmail®: Celebrate the moment with your favorite sports pics.
> > Check it out.
> > http://www.windowslive.com/Online/Hotmail/Campaign/QuickAdd?ocid=TXT_TAGLM_WL_QA_HM_sports_photos_072009&cat=sports
> >
> >
> > --------------------------------------------------------------------------------
> >
> >
> > > _______________________________________________
> > > AMBER mailing list
> > > AMBER.ambermd.org
> > > http://lists.ambermd.org/mailman/listinfo/amber
> > >
> >
> >
> >
> > _______________________________________________
> > AMBER mailing list
> > AMBER.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
>
> _________________________________________________________________
> Windows Live™ Hotmail®: Celebrate the moment with your favorite sports pics. Check it out.
> http://www.windowslive.com/Online/Hotmail/Campaign/QuickAdd?ocid=TXT_TAGLM_WL_QA_HM_sports_photos_072009&cat=sports_______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
_________________________________________________________________
Windows Live™ Hotmail®: Search, add, and share the web’s latest sports videos. Check it out.
http://www.windowslive.com/Online/Hotmail/Campaign/QuickAdd?ocid=TXT_TAGLM_WL_QA_HM_sports_videos_072009&cat=sports_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Jul 20 2009 - 18:07:10 PDT
