Hi All,
Recently a user reported an issue with cpptraj reading a topology file
containing CMAP terms. In the course of fixing the issue, I've come
across a curious (and as far as I can tell undocumented) issue: there
are two ways to specify CMAP parameters in the topology file. There is
the documented (
https://ambermd.org/prmtop.pdf, not sure if it is
anywhere else) way:
CHARMM_CMAP_COUNT
CHARMM_CMAP_RESOLUTION
CHARMM_CMAP_PARAMETER_XX
However, files output by Charmm GUI, and leap and parmed in Amber, use
versions of these FLAGs without the leading 'CHARMM_', i.e.
'CMAP_COUNT' etc.
The old 'chamber' tool seems to use the 'CHARMM_' style, and I've
found files in the current GIT repo that use this style of flags (e.g.
AmberTools/src/parmed/test/files/dhfr_cmap_pbc.parm7 among others).
The code seems to support both styles, although detection depends on
different things; in the sander code, flags like CHARMM_CMAP_PARAMETER
are read only if the FORCE_FIELD_TYPE flag is present and contains
CHARMM, while flags like CMAP_PARAMETER are read if CMAP_COUNT is
present. Both read CMAP parameters to the same variables.
My questions are:
1) Which one is currently "correct"? Under what circumstances (if any)
should one be used over the other? Based on parmed/leap, I'm assuming
the CMAP_PARAMETER (i.e. no leading 'CHARMM_') style is the one to
use, and the CHARMM_CMAP_PARAMETER style is retained for backwards
compatibility. If this is the case we need to update our file type
documentation.
2) Out of curiosity, why was this done? I'm assuming it's so force
fields can have CMAP parameters without necessarily having other
Charmm-related terms.
I appreciate any and all insights. Hope everyone is well and safe.
-Dan
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Jan 22 2021 - 07:30:03 PST
