[gmx-users] Fwd: Comments from Axel on QMMM calculation with Gromos FF

Pradip Kumar Biswas p.biswas at csuohio.edu
Mon Jun 19 00:27:11 CEST 2006

Begin forwarded message:

> From: Axel Kohlmeyer <akohlmey at cmm.chem.upenn.edu>
> Date: June 18, 2006 6:13:43 PM EDT
> To: Pradip Kumar Biswas <p.biswas at csuohio.edu>
> Cc: burisch at bph.rub.de
> Subject: Re: [gmx-users] Fwd: QMMM calculation
> Reply-To: Axel Kohlmeyer <akohlmey at cmm.chem.upenn.edu>
> 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   akohlmey at cmm.chem.upenn.edu   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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 6916 bytes
Desc: not available
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-users/attachments/20060618/6430220f/attachment.bin>

More information about the gromacs.org_gmx-users mailing list