Hi Ross
Instead of "patch -p0 <bugfix.all"
you mean "patch -p0 <bugfix.35" right?
Andrew
> 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
Received on Thu Apr 29 2010 - 05:00:03 PDT
