Ross Walker wrote:
> 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.
>
That was my plan, but it never gets far enough to do that. It bombs
before the QM region pdb write occurs.
> 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
Well, the active site should be near the center of the box (in the
familiar view). I've selected waters with the oxygen closer than 5A to
an atom close to the center of the active site. With a rectangular box
~70A on a side and given the DNA and protein residues in the active site
are close, I don't see how the box could be too small (unless something
is going on I don't understand). I think my water selection algorithm
must be bogus.
I'll try to simplify it (my water selection algorithm). There are some
relics from my first set of attempts in there. For example, I don't
think I need to image the system and write it to a new restart file. I
should just let it image when calculating the closest waters (which is
the default).
Unfortunately, I'm leaving tomorrow morning to go to the US Grand Prix.
I'll be back in a week. Meanwhile, if anyone else wants to comment
further, please do so, I just won't be able to answer. Particularly I'm
looking procedures for selecting waters that meet some specific
(distance) criteria. Not enumerating them, rather identifying them.
Thanks,
Bud
>> -----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
-----------------------------------------------------------------------
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:38 PDT
