<div dir="ltr">Hi Marcelo,<div><br></div><div>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 <a href="https://github.com/victorusu/gromacs/tree/nblib">fork of gromacs</a> 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.</div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 30, 2020 at 4:13 PM Justin Lemkul <<a href="mailto:jalemkul@vt.edu">jalemkul@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 1/30/20 9:42 AM, Marcelo Depólo wrote:<br>
> Hi,<br>
><br>
> I've been investigating the implementation of CMAP in GROMACS and, as <br>
> far as I understood, the current CMAP format is based on atomtypes and <br>
> not on function numbers or based on atomnames, as GROMACS normally do.<br>
><br>
> Hence, if one develops two different CMAPs for two different residues <br>
> (say, ALA and LEU), it would lead to the same header for both (such as <br>
> below), which I believe would cause a crash.<br>
><br>
> [ cmaptypes ]<br>
> C N CT C N 1 24 24\<br>
><br>
> Considering that FFSB19 <br>
> (<a href="https://pubs.acs.org/doi/abs/10.1021/acs.jctc.9b00591" rel="noreferrer" target="_blank">https://pubs.acs.org/doi/abs/10.1021/acs.jctc.9b00591</a>) already uses <br>
> residue-specific CMAPs, would it be possible to either:<br>
><br>
> 1 - implement the use of function numbers for CMAPs (that dummy '1' <br>
> could be used as a CMAP ID and called at the .rtp entry) or;<br>
><br>
<br>
Function numbers are used to indicate which potential energy expression <br>
is used. The CMAP form is not used like this so I don't see how this <br>
would help.<br>
<br>
> 2 - make CMAP entry based on atomnames?<br>
><br>
<br>
CMAP affects backbone atoms, the names of which are identical for all <br>
amino acids, so this won't be useful.<br>
<br>
The AMBER approach seems to allow overriding of parameters based on <br>
residue names. The workaround is simply to use "different" atom types <br>
for the alpha carbon, to allow for different CMAP, but this introduces a <br>
lot of redundancy in other bonded parameters.<br>
<br>
-Justin<br>
<br>
-- <br>
==================================================<br>
<br>
Justin A. Lemkul, Ph.D.<br>
Assistant Professor<br>
Office: 301 Fralin Hall<br>
Lab: 303 Engel Hall<br>
<br>
Virginia Tech Department of Biochemistry<br>
340 West Campus Dr.<br>
Blacksburg, VA 24061<br>
<br>
<a href="mailto:jalemkul@vt.edu" target="_blank">jalemkul@vt.edu</a> | (540) 231-3129<br>
<a href="http://www.thelemkullab.com" rel="noreferrer" target="_blank">http://www.thelemkullab.com</a><br>
<br>
==================================================<br>
<br>
-- <br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Joe Jordan<br><div><br></div></div></div></div></div>