[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