<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br><br>> Date: Fri, 29 May 2009 16:52:50 +1000<br>> From: Mark.Abraham@anu.edu.au<br>> To: gmx-users@gromacs.org<br>> Subject: Re: [gmx-users] constant term in dihedral potential function<br>> <br>> Kukol, Andreas wrote:<br>> > Many thanks for your help.<br>> > <br>> > As for the 1-4 interactions, I am using the Gromos53a6 forcefield for everything apart from this particular dihedral.<br>> > <br>> > I did not exclude 1-4 interactions previously with the multiple dihedral terms. Does this mean, if I use Ryckaert-Bellemans now (yielding the same potential function), I don't need to make any changes to 1-4 interactions ?<br>> > <br>> > Note that the previous method has been validated (with Gromacs 3.3), the problem is that it doesn't work with Gromacs 4 anymore. So I am trying to achieve the same result with Ryckaert-Bellemans instead of multiple periodic dihedrals.<br>> <br>> My earlier side point was that you can use multiple periodic dihedrals <br>> of type 9 if those dihedrals follow each other directly. Such dihedrals <br>> are effectively of type 1 (see code fragment below).<br>> <br>> You still won't get one of multiplicity 0, but such a function doesn't <br>> influence the dynamics (dV/dr = 0) and would always cancel out of any <br>> energy comparisons you might do. So I don't think it serves a purpose.<br>> <br>> >> I don't believe this works in the way you might expect. Page 109 of the<br>> >> manual contradicts me, but (undocumented) dihedral type 9 was added<br>> >> recently to allow multiple strictly-consecutive dihedrals of type "1" to<br>> >> be accumulated on the same atoms. Anyway, this can readily be checked by<br>> >> comparing 0-step EM runs, before and after commenting out the last of<br>> >> the multiple dihedrals pre-grompp. Also, you can look at a gmxdump of<br>> >> the .tpr.<br>> > <br>> > This works fine.<br>> <br>> I was looking at (4.0.5) src/kernel/toppush.c today for something else, <br>> and there's a comment in support of my statement above:<br>> <br>> if(ft == 9)<br>> {<br>> /* Previously, we have always overwritten parameters if e.g. a torsion<br>> with the same atomtypes occurs on multiple lines. However, CHARMM and<br>> some other force fields specify multiple dihedrals over some bonds,<br>> including cosines with multiplicity 6 and somethimes even higher.<br>> Thus, they cannot be represented with Ryckaert-Bellemans terms.<br>> To add support for these force fields, Dihedral type 4 is identical to<br>> normal proper dihedrals, but repeated entries are allowed.<br>> */<br>> bAllowRepeat = TRUE;<br>> ft = 1;<br>> }<br>> else<br>> {<br>> bAllowRepeat = FALSE;<br>> }<br>> <br>> The comment should refer to type 9 iso type 4, of course (and again in <br>> the warning text in push_bondtype() in the same source file). Further, <br>> push_bondtype() produces a grompp warning about overriding parameters in <br>> the other cases. So I think Berk is wrong here. Andreas should have a <br>> look at his grompp warnings, perhaps.<br>> <br>> Mark<br><br>Indeed the number should be 9 iso 4.<br><br>But this is a different issue.<br>These changes are to enable automatic parameter settings based on atomtypes<br>for multiple dihedrals over the same bonds.<br>Andreas specifies the parameters on the same line in the [ dihedrals ] section.<br>In that case every works (and has alwats worked) fine.<br><br>Berk<br><br><br /><hr />Express yourself instantly with MSN Messenger! <a href='http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/' target='_new'>MSN Messenger</a></body>
</html>