Hi Andrew,
Can you try applying the attached bugfix.35 to your AMBER 10 and see if it
fixes your problem. Make sure you first apply bugfix.all and then copy
bugfix.35 to $AMBERHOME/src/sander/ and
patch -p0 <bugfix.all
Recompile and run the tests and then try it with your system. I think this
should address the problem. It shifts the QM region by the center of
coordinates of the QM atoms rather than just shifting the first QM atom to
be at the origin. I have not had time to rigorously test this though so if
you could try it with several different QM setups it would be really
helpful.
All the best
Ross
> -----Original Message-----
> From: amber-bounces.ambermd.org [mailto:amber-bounces.ambermd.org] On
> Behalf Of aapeters.ncsu.edu
> Sent: Tuesday, April 20, 2010 11:28 AM
> To: AMBER Mailing List
> Subject: RE: [AMBER] QM/MM cut problem
>
>
> Hi Ross
>
> Thanks for your response. The junk in my input file is evolutionary
> leftovers from previous runs. I used a small system and a small cutoff
> because I'm trying to hone in on the problem. I have done several
> dozens
> of picoseconds of qmmm with this system, gradually ramping up from 0K
> to
> 16K at constant pressure. So I don't think that the evolutionary
> leftovers in the input file are causing the problem.
>
> I want to draw your attention to the following:
>
> According to the attached output file (and the qm_region.pdb file), the
> min and max Z are -5.884 and 5.884, which gives a size of 11.76. So
> the z
> size + 2*cutoff is 19.76Ang. But then later in the same output file,
> it
> says the QM Z size is 29.962Ang. Isn't this a conflict? The system
> only
> moved one step. I set it up this way to hone in on the problem.
>
>
> Andrew
>
>
>
> > Hi Andrew,
> >
> > The bounds for QMMM calculations are slightly different than the
> bounds
> > for
> > regular MM calculations. The MM pairlist is separate for each atom.
> Thus
> > with an 8A cutoff each atom is surrounded by a sphere of 8 angstroms
> > radius
> > which should not extend across two boxes. For the QM region, for
> stability
> > reasons since having different charges in the Fock matrix for
> different QM
> > atoms can cause problems, each atom shares the same non-bond list.
> Thus
> > each
> > QM atom interacts with MM atoms that are within qmcut of ANY QM atom.
> This
> > means that your QM region is effectively surrounded by a MM region of
> size
> > QMcut. In order to not violate the minimum image convention this
> means
> > that
> > your box must be at least the largest dimension of the QM region +
> the
> > cutoff.
> >
> > This should be what the message below is telling you. Your box can
> contain
> > a
> > sphere of 11.146 angstroms radius But the QM dimensions plus the
> cutoff
> > are
> > larger than this. Solution = use a much larger water box.
> >
> > With regards to the difference in the absolute values of the bounding
> box:
> >
> > ERROR: QM region + cutoff larger than box dimension:
> > QM-MM Cutoff = 4.0000
> > Coord Lower Upper Size Radius of largest sphere inside
> unit
> > cell
> > X -5.632 13.150 18.782 11.146
> > Y -5.431 13.671 19.102 11.146
> > Z -15.168 14.794 29.962 11.146
> >
> > One needs to consider the coordinates to simply be relative here. For
> > simplicity inside the QM routines the QM region is extracted from the
> > main,
> > unimaged, coordinate array. It is then imaged and centered. Then the
> MM
> > atoms that fall within the cutoff are also rebased to be within the
> QM
> > calculations central QM region origin setup. Hence the coordinates
> written
> > from within the QM region will not have the same origin as the inpcrd
> > file.
> >
> > Note, looking at your system:
> >
> > 1) NATOM = 1280
> >
> > This is VERY small, especially since you have some 160 QM atoms.
> Likely
> > you
> > have nowhere near enough water.
> >
> > 2) cut=4.0
> >
> > I assume you just made this smaller in order to see if you could get
> the
> > calculation to run, rather than actually intending to run simulations
> with
> > a
> > 4 angstrom cutoff. This should NEVER be reduced below 8.0. In fact I
> vouch
> > that the sander code be modified to refuse to run with cutoffs of
> less
> > than
> > 8.0.
> >
> > 3) Your mdin file appears to be full of lots of junk and strange
> settings.
> >
> > imin=0, maxcyc =1000,
> >
> > You specify maxcyc even though imin=0. This just leads to confusion.
> > You set tempi=1.0 even though you have irest=1. Again just confusion.
> > You specify tautp=0.1 even though you have ntt=3 which does not use
> tautp.
> > temp0=16.0 = You really want to run at just 16K? Scaling from 14
> kelvin to
> > 16 kelvin over 2000 steps?
> > You try to do NTP (ntb=2,ntp=1) at VERY low temperature. Use of
> constant
> > pressure at low temperatures will undoubtedly lead to instabilities.
> > You set offset=0.09 but are running PME. Again confusing.
> > You set clambda even though you are not running thermodynamic
> integration.
> >
> > Good luck,
> > Ross
> >
> > /\
> > \/
> > |\oss Walker
> >
> > | Assistant Research Professor |
> > | San Diego Supercomputer Center |
> > | Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
> > | http://www.rosswalker.co.uk | http://www.wmd-lab.org/ |
> >
> > Note: Electronic Mail is not secure, has no guarantee of delivery,
> may not
> > be read every day, and should not be used for urgent or sensitive
> issues.
> >
> >
> >
> >
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: amber-bounces.ambermd.org [mailto:amber-bounces.ambermd.org]
> On
> >> Behalf Of aapeters.ncsu.edu
> >> Sent: Tuesday, April 20, 2010 9:36 AM
> >> To: amber.ambermd.org
> >> Subject: [AMBER] QM/MM cut problem
> >>
> >> Hello users
> >>
> >> When using Amber10 QM/MM I get errors complaining my box is too
> small.
> >>
> >> But when I look at the structure and at the QM region coordinates,
> >> there
> >> seems to be enough space. There seems to be a conflict between the
> >> coordinate extremes written out in the first part of the output file
> >> (or
> >> the qmmm_region.pdb file), and the bounds written out in the latter
> >> part
> >> of the output file:
> >>
> >> ERROR: QM region + cutoff larger than box dimension:
> >> QM-MM Cutoff = 4.0000
> >> Coord Lower Upper Size Radius of largest sphere
> inside
> >> unit
> >> cell
> >> X -5.632 13.150 18.782 11.146
> >> Y -5.431 13.671 19.102 11.146
> >> Z -15.168 14.794 29.962 11.146
> >>
> >> To hone in on the problem, I set up a run that crashes on the second
> >> step.
> >> So
> >> 1) the initial qm region positions are written in the output file
> >> 2) the system takes one step, and writes "qmmm_region.pdb", the
> >> corresponding pdb file
> >> 3) the system crashes on the 2nd step, writing the bounds violation
> in
> >> the
> >> output file.
> >>
> >> Assuming positions barely change in one step, there seems to be a
> >> significant conflict within the code about where it thinks the
> bounds
> >> are?
> >>
> >> I attached the output files
> >>
> >> Thanks in advance for any help.
> >>
> >> Andrew Petersen
> >
> >
> > _______________________________________________
> > 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
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
- application/octet-stream attachment: bugfix.35
Received on Thu Apr 29 2010 - 02:30:03 PDT
