AMBER Archive (2009)

Subject: RE: [AMBER] question of ibelly used in pmemd

From: Kristina Furse (Kristina.Furse.1_at_nd.edu)
Date: Tue Jul 21 2009 - 11:27:29 CDT


I'm sure ntr is the better choice in most cases, but I think it's nice to have the belly option for certain specialized research questions. For instance, I'm trying to physically decouple water and DNA dynamics, so I need DNA to do everything it normally does except move. ntr would just give me altered DNA dynamics. As long as the different belly/other flag combo's work in sander, I agree that it's probably not necessary to have the full complement of functionality in pmemd, too. Pretty obscure if it's just coming up now.

Thanks!
Kristina

________________________________________
From: amber-bounces_at_ambermd.org [amber-bounces_at_ambermd.org] On Behalf Of Robert Duke [rduke_at_email.unc.edu]
Sent: Tuesday, July 21, 2009 10:16 AM
To: AMBER Mailing List
Subject: Re: [AMBER] question of ibelly used in pmemd

Hi Kristina,
Yeah, I played around with moving stuff a bit too, and I basically never
found a combo where all the nmr-related lines (3 I think) got read properly
and also didn't in some manner screw up the belly. Screwing up the belly
read seems to be why the job blows up in pmemd. It is something subtle in
the original rgroup/rfree code I ported from amber 6, or perhaps something
that I dropped in a cleanup, but I think basically it has never been tested
before (the combination belly + nmr restraints); given that ntr restraints
+ nmr works fine, I am inclined to just advocate that folks use ntr
restraints instead of belly at this point. I undoubtedly could fix it, but
it could end up eating a day to do it; the rfree/rgroup code is a bit messy.
Thanks for your input on all this; you have really been a key player in
checking out nmr restraint issues.
Regards - Bob

----- Original Message -----
From: "Kristina Furse" <Kristina.Furse.1_at_nd.edu>
To: "AMBER Mailing List" <amber_at_ambermd.org>
Sent: Tuesday, July 21, 2009 9:53 AM
Subject: RE: [AMBER] question of ibelly used in pmemd

I tried several different orders in the input file, and found the following:

Test input #1: For the original version (sander-friendly), pmemd tries to
read the DISANG line as the belly title, and dies trying to interpret the
belly title as the belly input.

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

Relevant portion of pmemd output:

    LOADING THE BELLY ATOMS AS GROUPS

    ----- READING GROUP 1; TITLE:
 DISANG=Dummy.rst

     rfree: Error decoding variable 2 2 from:
Movable belly

Test input #2: If I delete the belly title line, it actually works--I think
this is why Xiaoqin's input worked. pmemd reads the DISANG line as the belly
title, then correctly reads in the belly input. Interestingly, it still uses
the DISANG line for nmr restraint redirection, too, so it must parse the
list twice?

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
 &end
 &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
RES 25 9985
END
END

Relevant portion of pmemd output:

    LOADING THE BELLY ATOMS AS GROUPS

    ----- READING GROUP 1; TITLE:
 DISANG=Dummy.rst
 GRP 1 RES 25 TO 9985
      Number of atoms in this group = 29839
    ----- END OF GROUP READ -----

--------------------------------------------------------------------------------
   3. ATOMIC COORDINATES AND VELOCITIES
--------------------------------------------------------------------------------

 begin time read from input coords = 0.000 ps

           Begin reading energy term weight changes/NMR restraints
 WEIGHT CHANGES:
 TEMP0 0 10000 0.000000 300.000000 0 0
 TEMP0 10000 25000 300.000000 300.000000 0 0

 RESTRAINTS:
 Requested file redirections:
  DISANG = Dummy.rst
 Restraints will be read from file: Dummy.rst
Here are comments from the DISANG input file:
                          ** No restraint defined **

                  Done reading weight changes/NMR restraints

Test input #3: If instead, I keep the belly title line and just move the
DISANG line to the bottom of the input, it correctly reads in the belly and
weight change information and runs, but it doesn't find the DISANG line, so
it misses the file redirection.

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
 &end
 &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',
 /
Movable belly for water and ions
RES 25 9985
END
END
DISANG=Dummy.rst

Relevant portion of output:

    LOADING THE BELLY ATOMS AS GROUPS

    ----- READING GROUP 1; TITLE:
 Movable belly for water and ions
 GRP 1 RES 25 TO 9985
      Number of atoms in this group = 29839
    ----- END OF GROUP READ -----

--------------------------------------------------------------------------------
   3. ATOMIC COORDINATES AND VELOCITIES
--------------------------------------------------------------------------------

 begin time read from input coords = 0.000 ps

           Begin reading energy term weight changes/NMR restraints
 WEIGHT CHANGES:
 TEMP0 0 10000 0.000000 300.000000 0 0
 TEMP0 10000 25000 300.000000 300.000000 0 0

 RESTRAINTS:
  No valid redirection requests found
                          ** No restraint defined **

                  Done reading weight changes/NMR restraints

Test input #4: If I move the belly input above the weight change
information, it doesn't run.

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
 &end
Movable belly for water and ions
RES 25 9985
END
END
 &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

Relevant output:

    LOADING THE BELLY ATOMS AS GROUPS

    ----- READING GROUP 1; TITLE:
 DISANG=Dummy.rst

     rfree: End of file on unit 5

Anyway, hope that helps figuring out what's up with ibelly plus nmr
restraints!

Kristina

--
Kristina Furse
Postdoctoral Research Associate
260B Stepan Chemistry Hall
Notre Dame, IN 46556
(574)631-3904
________________________________________
From: amber-bounces_at_ambermd.org [amber-bounces_at_ambermd.org] On Behalf Of
Robert Duke [rduke_at_email.unc.edu]
Sent: Tuesday, July 21, 2009 9:15 AM
To: AMBER Mailing List
Subject: Re: [AMBER] question of ibelly used in pmemd

Hi Xiaoqin, Okay, here's what is happening. It appears that somewhere in the group-reading code, when using belly, there is a problem with skipping over nmr restraint lines in pmemd. Interestingly, this problem does not exist if you use ntr-based restraints combined with nmr restraints. So I have an old problem from Kristina that uses ntr + nmr restraints, it worked for amber 9, and it still works for amber 10. Her mdin looks like:

Test using nmropt and ntr together &cntrl

nmropt = 1, ntx = 1, irest = 0, ntrx = 1, ntxo = 1, ntpr = 10, ntwx = 100, ntwv = 0, ntwe = 100,

ntf = 1, ntb = 1, cut = 9.0,

ibelly = 0, ntr = 1,

imin = 0, nstlim = 100, nscm = 0, t = 0.0, dt = 0.001,

temp0 = 298.0, tempi = 100.0, ig = 71277, heat = 0.0, ntt = 1, tautp = 0.2, vlimit = 20.0,

ntc = 2, tol = 0.00001, watnam = 'SPC ', jfastw = 0,

&end

&wt type='TEMP0', istep1=0, istep2=500, value1=100.0, value2=298.0, &end &wt type='TEMP0', istep1=500, istep2=20000, value1=298.0, value2=298.0, &end &wt type='END', &end DISANG=nmropt.rest Hold stuff fixed 50.0 RES 10 20 END END

SO while I will look into what is broken about using belly + nmr restraints, you would probably be better off moving to ntr + nmr restraints. Note also, that in some senses using ntr restraints is a bit easier, as you only have to specify the stuff you want to restrain, not the stuff you want to move (in your case I suspect a shorter list). You do have to remember to specify the reference coordinates (-ref on input line), usually the same as the -c (coordinates) file. I am guessing we have never seen this bug before, simply because no one has been using this combination...

Regards - Bob Duke

----- Original Message ----- From: "xiaoqin huang" <xqhuang1018_at_msn.com> To: <amber_at_ambermd.org> Sent: Monday, July 20, 2009 1:20 PM Subject: RE: [AMBER] question of ibelly used in pmemd

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_at_nd.edu > To: amber_at_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_at_email.unc.edu > > To: amber_at_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_at_msn.com> > > To: <amber_at_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_at_email.unc.edu > > > To: amber_at_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_at_msn.com> > > > To: <amber_at_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_at_email.unc.edu > > > > To: amber_at_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_at_msn.com> > > > > To: <amber_at_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_at_email.unc.edu > > > > > To: amber_at_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_at_msn.com> > > > > > To: <amber_at_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_at_email.unc.edu > > > > > > To: amber_at_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_at_msn.com> > > > > > > To: <amber_at_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 > > > > > > > > > > > > > > > > _________________________________________________________________

_______________________________________________ AMBER mailing list AMBER_at_ambermd.org http://lists.ambermd.org/mailman/listinfo/amber