Begin forwarded message:
From: Axel Kohlmeyer <[EMAIL PROTECTED]>--
Date: June 18, 2006 6:13:43 PM EDT
To: Pradip Kumar Biswas <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: [gmx-users] Fwd: QMMM calculation
Reply-To: Axel Kohlmeyer <[EMAIL PROTECTED]>
On Sun, 18 Jun 2006, Pradip Kumar Biswas wrote:
hi guys,
PB> Hi Christian,
PB>
PB> Thanks for your comments. I am writing to Axel (he is now in upenn, US)
PB> as he might be having the first hand experience of how CPMD-Gromos
PB> interface manages the issue.
i'd be happy to do so. first off, i am _not_ on the gmx user's list
(i am on too many 'users' lists already, but only on gmx-developers
(since we have some issues getting the current gmx to run on some of
our most important platforms. feel free to forward this mail to
gmx-users, if you think it would be appropriate. so here we go.
first you have to realize, that the gromos/cpmd and the gromacs/cpmd
interface apply two different strategies. the gromos/cpmd uses the
gromos mm code to get the mm-forces and electrostatics and that's
it. the rest is done from within cpmd. the gromacs/cpmd uses cpmd
only as a 'force engine' and does the rest in gromacs. this has
the consequence that gromos/cpmd interface only needs a topology
file for the purely classical part whereas the gromacs/cpmd needs
a topology, where QM atoms can be identified. the gromos interface
is less efficient in handling constraints and propargting the
coordinates, but that is in most cases (i.e. if you are not running
on a BG/L or Cray XT3) not an issue as the QM part dominates the
computational effort.
now please let me comment on the various ways the gromos interface
handles the QM termination, QM box size and united atom cases.
the gromos/cpmd interface is in principle able to handle both
united atom and all-atom force fields. for as long as they can
be mapped on the gromos96/87 functional forms. the gromos code
in the CPMD QM/MM is a severely hacked version of a development
snapshot of a post gromos96 code (i.e. it includes a proper ewald).
it also supports (via a CPMD input flag) the different scaling of
1-4 interactions in amber94. before i left bochum, i started writing
a program, that can convert any gromacs .tpr file into a cpmd compatible
gromos96 format topology and the opls/aa support was almost there
when i left. supposedly some colleages have been working on it.
here at penn we try to get the CP2k QM/MM working (which is far
superior in theory but in practice still alpha quality code). so
i didn't care to put any more effort into it. most people that use
the cpmd QM/MM actually use the amber mode.
terminating the QM system from the MM system can be done in two
ways:
- use a mono (or di-, tri, hepta-valent carbon atom pseudopotential)
those potentials have to be optimized to reproduce the all atom
electron density and forces as close as possible (outside of the
carbon or other atom), but this usually only works well with the
forces (if at all) and then one needs to constrain the c-c bond
to the classical lenght so the electron density and eigenvalues
are reasonably preserved.
- use a capping hydrogen.
the capping hydrogens have to be added to the MM topology, but
explicitely excluded from all bonded interactions and the non-bonded
interactions in the solute. the major problem with those is, that
they can usually move freely (they are 'invisible' to the MM part)
and thus influence with their vibrations the dynamics and worse, due
to effeciency considerations the resulting RESP charges are computed
with rather low accuracy which occasionally leads to unphysical
charges (and the capping hydrogen shoot through the QM box and
the simulation crashed). this also can be made less of a problem
by using constraints.
now for united atoms force fields, of course, you need to add the
missing hydrogens to the topology. here the same rules as for the
capping hydrogens apply. i.e. they have to be made invisible to
the MM system. CPMD supports semi-automatic dealing with that kind
of situation. using an all-atom force field however is usually the
more convenient solution.
as far as the selection of the box size goes, this is determined
by the contraints of the poisson solver used. the poisson solver
is used to decouple the periodic images of the QM system. as in
plane wave pseudopotential calculations, you _always_ have a periodic
system. with the poisson solver, you can however cancel out the
periodic interactions after the fact. there are basically
two options TUCKERMAN and HOCKNEY and they have different requirements.
the HOCKNEY need the charge density to go down to zero at the border
of the box (for a spherical charge distribution) which usually
translates in to 3-4 angstrom at the side. the TUCKERMAN solver
need twice the size of the charge distribution. the latter is,
however, faster, so it is recommended for small QM boxes. the
hockney takes much longer to compute, but needs a smaller box
for a large QM system and is thus preferred in those cases.
the error by using a too small box is usually pretty large with
the hockney solver and sometimes(!) rather small with the tuckerman.
it has to be tested every time.
there are still a bunch of people working on the gromos QM/MM
stuff in bochum (nisanth, gerald, eddi, marcus), so it is probably
a good idea to talk to them.
as far as the gromacs QM/MM goes, i think you could do a similar
approach, i.e. define the additional hydrogens (you _have_ to
specify them) and then exclude them from the MM interactions
(i.e. define a new FF type with charge 0, and vdW interaction 0.0/0.0
and exclude them from all neighbors.
best regards,
axel.
--
=======================================================================
Axel Kohlmeyer [EMAIL PROTECTED] http://www.cmm.upenn.edu
Center for Molecular Modeling -- University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.
Pradip K. Biswas, PhD.
Research Associate, Department of Chemistry;
Cleveland State University, Ohio-44115
Phone: 1-216-875-9723
http://comppsi.csuohio.edu/groups/people/biswas.html
_______________________________________________ gmx-users mailing list [email protected] http://www.gromacs.org/mailman/listinfo/gmx-users Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php
