RE: AMBER: box size bomb in QMMM calculation

From: Ross Walker <ross.rosswalker.co.uk>
Date: Tue, 12 Jun 2007 15:29:26 -0700

Hi Bud,

It is possible that what you are seeing could one of two things

1) As you say you may have chosen incorrect waters. Try setting nstlim=1 and
add writepdb=1 to the qmmm namelist. Then run the QMMM calculation again and
you should get a pdb file (called qmmm_region.pdb) which represents the QM
region as seen by the QM part of the code. If you visualize this you should
be able to measure the distance of the waters from the QM region and see if
they are the closest. Note because of point 2 below you may need to set the
cut off unreasonably small for this, say 0.1 A just to force it to get to
the pdb writing stage.

2) More likely you are seeing a problem related to the way the cut off is
treated with QM/MM. Unlike MM-MM pairs which are a pair wise based cut off
QM/MM effectively uses a group based cutoff where the QM region represents 1
group. Hence any atom that is within cut of any QM atom gets included for
ALL QM atoms. This is done for convergence reasons, the QM calcs are much
more stable when all QM atoms see the same net total charge. Hence the cut
off for the QM region looks like this cut sized bubble around the QM region.
What this means is that for periodic boundaries you need a bigger buffer
space between the QM region and the box edges. For regular MM the minimimum
image convention means the smallest box dimension must be at least twice the
size of the cut off. However for the QM region this translates to the
smallest box dimension must be larger than twice the QM cut off + the
largest dimension of the QM region. This is what is being violated and why
you see the error message. However, your box looks to be pretty big so
either your QM region is highly extended or as you say you may have picked
the wrong water molecules. Try idea 1 above to see.

In terms of the functioning of the closest waters command I'd have to look
more closely but I would start by ruling out that your box isn't just too
small first of all.

All the best
Ross

/\
\/
|\oss Walker

| HPC Consultant and Staff Scientist |
| San Diego Supercomputer Center |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
| http://www.rosswalker.co.uk | PGP Key available on request |

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: owner-amber.scripps.edu
> [mailto:owner-amber.scripps.edu] On Behalf Of M. L. Dodson
> Sent: Tuesday, June 12, 2007 12:46
> To: amber.scripps.edu
> Subject: AMBER: box size bomb in QMMM calculation
>
> Hi Ambers!
>
> I have a problem, possibly conceptual.
>
> I want to do QMMM and include in the QM region 5 waters close
> (within 5
> A) to a key atom in the active site of an enzyme. I did 1.2ns of
> completely standard classical MD, then determined to closest
> 5 waters to
> the key atom (rectangular box of dimensions indicated below).
> But when
> I used the last restart file of the classical MD run as the beginning
> state of my QMMM run, I got the following error:
>
> .
> .
> .
> | CHECK switch(x): max rel err = 0.2738E-14 at 2.422500
> | CHECK d/dx switch(x): max rel err = 0.8314E-11 at 2.736960
> ---------------------------------------------------
> | Local SIZE OF NONBOND LIST = 10918606
> | TOTAL SIZE OF NONBOND LIST = 10918606
> ****************************************************
> ERROR: QM region + cutoff larger than box dimension:
> QM-MM Cutoff = 9.0000
> Coord Lower Upper Size Box(a,b,c)
> X 13.439 109.822 96.383 73.890
> Y 21.807 127.606 105.799 78.442
> Z 20.002 117.176 97.174 70.617
> ****************************************************
> SANDER BOMB in subroutine QM_CHECK_PERIODIC<qm_mm.f>
> QM region + cutoff larger than box
> cannot continue, need larger box.
>
> See the enclosed .out file for the whole story (including the input).
> Now the only thing I can see is that my method of determining
> the water
> atoms to include in the QM region is wrong. Here is what I did:
>
> 1. imaged the restart file to the original cell, generating another
> restart file (with ptraj):
>
> center :1-${proteinl} mass origin
> image origin
> center :1-${protein1D} mass origin
> image origin
> center :1-${length} mass origin
> image origin familiar
>
> where proteinl, protein1D, and length are the number of
> residues in the
> protein, protein + first DNA strand, and protein + both DNA strands
>
> 2. generated a pdb file from the restart file generated in 1
> using ambpdb
>
> 3. generated a pdb file with the closest waters (using ptraj, and the
> imaged restart file generated in step 1 as input):
>
> closestwater 5 ":TT5\.C1'" oxygen noimage
> (this is in a perl script, hence the \. instead of just @)
>
> 4. Used grep to locate the Cartesian coordinates (oxygen) of these
> closest waters in the pdb file generated with ambpdb in step 2.
>
> 5. Used the oxygen atom numbers identified in 4 + the succeeding two
> numbers (Hydrogens) as the QM water atoms
>
> This bombed as indicated above and in the attached output file.
>
> Any comments would be appreciated.
>
> My conceptual question is whether imaging renumbers the atoms? My
> method assumes it does not. That is all I have been able to come up
> with so far.
>
> Thanks,
> Bud Dodson
>
> PS, this was run with a development version of the Amber10 sander
> obtained from Ross.
> --
> M. L. Dodson
> Email: mldodson-at-houston-dot-rr-dot-com
> Phone: eight_three_two-56_three-386_one
>


-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Wed Jun 13 2007 - 06:07:37 PDT
Custom Search