[gmx-developers] Making CMAP not atomtype dependent

[Joe Jordan]

Hi Marcelo,

There is an ongoing project called nb-lib (because we are developing a
non-bonded library) that is currently working on implementing more generic
topology setup functionality that can be used by gromacs. Currently it is
just a fork of gromacs <https://github.com/victorusu/gromacs/tree/nblib> on
github, but we hope to have it in the master branch well before the
deadline for the next release. One thing we are shooting for is to have the
ability to add arbitrary interactions to particles of arbitrary types. What
I mean is that we hope to allow the creation of topologies with n-ary
interactions (short-range, long-range, bonds, angle, etc) between
particles. I should caution that we are only developing a front end that
has a translation layer to gromacs, so anything that you can't do in
gromacs you would not be able to do in nb-lib. At any rate, it would be
quite beneficial to us to have some concrete use cases to demonstrate
things that can be done easily in nb-lib that would take a lot of work in
gromacs, so it could be worth discussing further what your goals and
timelines are.

I agree with Justin that CMAPs are really just a complicated kludge to make
the parameters work, but nb-lib is targeting usability of such overwrought
parameterizations, so feel free to reach out.

On Thu, Jan 30, 2020 at 4:13 PM Justin Lemkul <jalemkul at vt.edu> wrote:

>
>
> 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
>
> ==================================================
>
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.



-- 
Joe Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20200130/8da3de8e/attachment-0001.html>