RE: [AMBER] QM/MM cut problem

From: Ross Walker <>
Date: Tue, 20 Apr 2010 10:20:07 -0700

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

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
     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

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,

|\oss Walker

| Assistant Research Professor |
| San Diego Supercomputer Center |
| Tel: +1 858 822 0854 | EMail:- |
| | |

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: [] On
> Behalf Of
> Sent: Tuesday, April 20, 2010 9:36 AM
> To:
> 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
Received on Tue Apr 20 2010 - 10:30:05 PDT
Custom Search