<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 8/05/2012 5:19 AM, Elton Carvalho wrote:
    <blockquote
cite="mid:CAOYvBo+jsO7mrEgr2V5LRRz6k8GPJuePbvEom=j6Npeo6NF8ww@mail.gmail.com"
      type="cite">
      <pre wrap="">Thank you for your reply, Mark,

On Sat, May 5, 2012 at 7:06 AM, Mark Abraham <a class="moz-txt-link-rfc2396E" href="mailto:Mark.Abraham@anu.edu.au">&lt;Mark.Abraham@anu.edu.au&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">
Fundamentally, pdb2gmx is built for fine-grained force fields. I'd have
supposed Martini has some kind of builder program other than pdb2gmx, for
this kind of reason, but I have no idea whether this is true.

</pre>
      </blockquote>
      <pre wrap="">
It kinda does. Not for polymers just yet. I asked part of the people
involved in this before asking here.

</pre>
      <blockquote type="cite">
        <pre wrap="">Setting nrexcl = 1 would exclude such angles and dihedrals, I think, but
would also exclude generating the normal ones. One option is to do that and
explicitly define the relevant angles and dihedrals.

</pre>
      </blockquote>
      <pre wrap="">
nrexcl is already 1, as per MARTINI's defaults and the dihedrals are
built anyway.</pre>
    </blockquote>
    <br>
    Yeah, I was wrong in that speculation. nrexcl pertains only to
    non-bonded interactions.<br>
    <br>
    <blockquote
cite="mid:CAOYvBo+jsO7mrEgr2V5LRRz6k8GPJuePbvEom=j6Npeo6NF8ww@mail.gmail.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">
Code comments are in disagreement about column 8. Looking at the code, I
think the above .rtp comment is how the code works. A specific simple
counter-example (showing how .rtp contents create .itp contents that seem to
breach the above description) would be welcome. I'm not sure if there are
circumstances where impropers are generated automatically, but that could
possibly explain such an observation.

</pre>
      </blockquote>
      <pre wrap="">
I prepared a minimal example and, in doing so, I noticed that the
problem is not removing dihedrals sharing a bond with impropers, but
column 5: all_dihedrals, which is said to generate dihedrals involving
ony "heavy" atoms if set to 0.

When set to 1, pdb2gmx generates the dihedrals CA2 CA1 C9 C91 and CA1
C9 C91 C4 for example (see attached figure, remembering this is a
coarse grained model), which are not generated when all_dihedrals is
zero. &nbsp;Certainly, none of these atoms should be considered "light".

This raises a question about how "heavy" atoms are defined in Gromacs.
I couldn't find it in the PDF manual. Where should I put the
definitions of which atoms are "heavy"?</pre>
    </blockquote>
    <br>
    pdb2gmx looks at whether the atom name starts with 'H' or a digit
    and then 'H', but it turns out not to be relevant.<br>
    <br>
    <blockquote
cite="mid:CAOYvBo+jsO7mrEgr2V5LRRz6k8GPJuePbvEom=j6Npeo6NF8ww@mail.gmail.com"
      type="cite">
      <pre wrap="">

Also, regardless of the value of RemoveDih, dihedrals like CA2 CA1 C9
C91, that shares the central bond with CA2 CA1 C9 CB1, are kept in the
final topology. So apparently RemoveDih doesn't really exclude proper
dihedrals sharing the central bond.</pre>
    </blockquote>
    <br>
    Yeah, that .rtp comment looks totally wrong. After looking at the
    code I think:<br>
    <br>
    &nbsp;&nbsp; * Column 5: 1 means keep all generated dihedrals,<br>
    &nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0 means permit generated dihedrals to have their
    parameters<br>
    &nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; superseded by ones on the same central bond that
    have<br>
    &nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fewer hydrogen atoms.<br>
    <br>
    That's totally different from what the .itp suggests, and does
    explain your observations. <br>
    <br>
    There seems to be no automatic way to treat the issue that you'd
    like addressed. Feel free to make a feature request on
    redmine.gromacs.org, but it likely won't be addressed until GROMACS
    5 (at least).<br>
    <br>
    <blockquote
cite="mid:CAOYvBo+jsO7mrEgr2V5LRRz6k8GPJuePbvEom=j6Npeo6NF8ww@mail.gmail.com"
      type="cite">
      <pre wrap="">

I prepared a minimal structure and a gmxlib tree which includes the
RTP file for clarification, but it exceeds the attachment limit of the
list, I can send it if it&#347; really necessary

</pre>
      <blockquote type="cite">
        <pre wrap="">
</pre>
        <blockquote type="cite">
          <pre wrap="">
Could anyone clarify the role of these extra columns? I think this
also hints for a review in this section of the manual.
</pre>
        </blockquote>
        <pre wrap="">

True. An update is in progress now.

</pre>
      </blockquote>
      <pre wrap="">
That's great news!

In the next days I'll send some questions about the manual to help
guiding that effort! ;)</pre>
    </blockquote>
    <br>
    There have been quite a few manual updates already. For example, <a
      href="http://jenkins.gromacs.org/job/Manual_Gerrit_4_5/15/">http://jenkins.gromacs.org/job/Manual_Gerrit_4_5/15/</a>
    has a link to a current PDF manual ("save as" on the PDF link is
    sometimes necessary). Feedback is welcome, but feedback relative to
    the updated manual is more welcome. :-)<br>
    <br>
    Mark<br>
    <br>
    <blockquote
cite="mid:CAOYvBo+jsO7mrEgr2V5LRRz6k8GPJuePbvEom=j6Npeo6NF8ww@mail.gmail.com"
      type="cite">
      <pre wrap="">

Greetings from a sunny Groningen,
--
Elton Carvalho
Faculty of mathematics and natural sciences
University of Groningen
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
    </blockquote>
    <br>
  </body>
</html>