[gmx-developers] Making CMAP not atomtype dependent
Justin Lemkul
jalemkul at vt.edu
Thu Jan 30 16:13:25 CET 2020
On 1/30/20 9:42 AM, Marcelo Depólo wrote:
> Hi,
>
> I've been investigating the implementation of CMAP in GROMACS and, as
> far as I understood, the current CMAP format is based on atomtypes and
> not on function numbers or based on atomnames, as GROMACS normally do.
>
> Hence, if one develops two different CMAPs for two different residues
> (say, ALA and LEU), it would lead to the same header for both (such as
> below), which I believe would cause a crash.
>
> [ cmaptypes ]
> C N CT C N 1 24 24\
>
> Considering that FFSB19
> (https://pubs.acs.org/doi/abs/10.1021/acs.jctc.9b00591) already uses
> residue-specific CMAPs, would it be possible to either:
>
> 1 - implement the use of function numbers for CMAPs (that dummy '1'
> could be used as a CMAP ID and called at the .rtp entry) or;
>
Function numbers are used to indicate which potential energy expression
is used. The CMAP form is not used like this so I don't see how this
would help.
> 2 - make CMAP entry based on atomnames?
>
CMAP affects backbone atoms, the names of which are identical for all
amino acids, so this won't be useful.
The AMBER approach seems to allow overriding of parameters based on
residue names. The workaround is simply to use "different" atom types
for the alpha carbon, to allow for different CMAP, but this introduces a
lot of redundancy in other bonded parameters.
-Justin
--
==================================================
Justin A. Lemkul, Ph.D.
Assistant Professor
Office: 301 Fralin Hall
Lab: 303 Engel Hall
Virginia Tech Department of Biochemistry
340 West Campus Dr.
Blacksburg, VA 24061
jalemkul at vt.edu | (540) 231-3129
http://www.thelemkullab.com
==================================================
More information about the gromacs.org_gmx-developers
mailing list