[gmx-users] Re: dihedraltypes funct 4 and 9 in gmx 4.5 amber

[Alan]

Hi there,

Now I have some results that I hope to clear this matter about dihe funct 4
and 9 (specially the latter).

Please see:

http://code.google.com/p/acpype/wiki/TestingAcpypeAmb2gmx

>From my understanding (and results), where dihe funct 4 or 9, replacing both
with 1 changes nothing in tot pot energy for amber force fields.

I don't know about charmm here, but I thought amber dihe parameters were
sort multiple terms and as far as I remember, the need to convert proper
dihe to RBs was necessary for early versions of gromacs 3.x, am I right?

Best,

Alan

On 18 August 2010 22:01, Alan <alanwilter at gmail.com> wrote:

> Hi Berk and Mark,
>
>
>> Erik was too lazy to document this, I now added it to the manual.
>>
>
> Is this manual available even via git? When funct 4 and 9 appeared? in gmx
> 4.5?
>
> Type 4 is identical to type 1, it is only there to distinguish improper
>> from proper dihedrals.
>>
>
> So for amber impr. dih. only, if I put 1 instead of 4 I for my GAFF
> generated ligand it would do the same thing, right? I ask that for the grace
> of compatibility with gmx 4.0.x.
>
> Type 9 is identical to type 1, except that multiple entries in
>> dihedraltypes will lead to
>> multiple functions on one dihedral.
>>
>
> This one is more difficult to get. I know about multiple entries in CNS,
> Charmm and Amber. I was even trying to convert amber99bsc0 new dih
> parameters to gromacs and I was using funct 1. However I didn't have Amber
> to validate, and now I have Amber11, I don't have time for the moment.
>
> Sounds like funct 9 is to not only pave the way for Charmm, but may help to
> address properly the bsc0 parameters, right?
>
> But I need to understand this better. Converting amber's proper dih. param.
> to gromacs 4.0.x was done by making these dih. to be RB. However
> amb2gmx.pl converts everything to proper (using funct 1) -- acpype is
> smarter here. So in gmx 4.0.x proper dih. funct 1 was never able to
> interpret multiple entries on one dihedral?
>
> Now on Mark:
>
>
>> Type 9 was added to facilitate CHARMM's multiple proper dihedrals, in git
>> commit a7c597c778351f by Erik, whose message was
>>
>>    Added support for dihedraltype 9, which allows multiple terms for
>> proper dihedrals.
>>    By listing a dihedral with type 9, grompp will now scan the force field
>> to see if there are
>>    multiple terms on _adjacent_ lines listed in the dihedraltypes section,
>> and in that case add them all.
>>
>> A code snippet in src/kernel/toppush.c reads
>>
>>        if(ft == 9)
>>        {
>>                /* Previously, we have always overwritten parameters if
>> e.g. a torsion
>>                 with the same atomtypes occurs on multiple lines. However,
>> CHARMM and
>>                 some other force fields specify multiple dihedrals over
>> some bonds,
>>                 including cosines with multiplicity 6 and somethimes even
>> higher.
>>                 Thus, they cannot be represented with Ryckaert-Bellemans
>> terms.
>>                 To add support for these force fields, Dihedral type 9 is
>> identical to
>>                 normal proper dihedrals, but repeated entries are allowed.
>>                 */
>>                bAllowRepeat = TRUE;
>>                ft = 1;
>>        }
>>
>
> So amb2gmx.pl never worked properly here? For example, I have this for DNA
> with amber99bsc0:
>
> ; treated as usual propers in GROMACS since Phase angle diff from 0 or 180
> degrees
> ; i   j   k   l func  phase     kd      pn
>   2   3   6  23   1   190.98   4.92892   1 ;    O5'-   C5'-   C4'-   C3'
>   2   3   6  23   1   295.63   0.38535   2 ;    O5'-   C5'-   C4'-   C3'
>   2   3   6  23   1   348.10   4.02848   3 ;    O5'-   C5'-   C4'-   C3'
>  28  29  32  33   1    31.80   0.77480   1 ;    O3'-     P-   O5'-   C5'
>  28  29  32  33   1   351.96   5.25733   2 ;    O3'-     P-   O5'-   C5'
>  28  29  32  33   1   357.25   1.48473   3 ;    O3'-     P-   O5'-   C5'
>
> So, this would only work if funct was 9 and not 1 as above? The way it is,
> the last line of a sequence dih. is overwriting the 2 previous one, ignoring
> them completely?
>
>
>> From src/gmxlib/{ifunc,bondfree}.c and src/kernel/{topdirs,toppush}.c it
>> can be seen that dihedraltypes 4 and 1 call the same evaluation function.
>> Perhaps Erik can confirm this.
>>
>> src/gmxlib/ifunc.c did suggest to me that something is not quite right...
>>
>>  def_bonded  ("PDIHS",    "Proper Dih.",     4, 3, 3,  eNR_PROPER, pdihs
>>       ),
>>  def_bonded  ("RBDIHS",   "Ryckaert-Bell.",  4, 6, 6,  eNR_RB, rbdihs
>>        ),
>>  def_bonded  ("FOURDIHS", "Fourier Dih.",    4, 4, 4,  eNR_FOURDIH, rbdihs
>>       ),
>>  def_bonded  ("IDIHS",    "Improper Dih.",   4, 2, 2,  eNR_IMPROPER,idihs
>>        ),
>>  def_bonded  ("PIDIHS",   "Improper Dih.",   4, 3, 3,  eNR_PROPER, pdihs
>>       ),
>>
>> If PIDIHS is an improper dihedral with the functional form of a proper
>> dihedral, should it not use eNR_IMPROPER?
>>
>
> I definitely need to run my validations myself, but any words here would be
> helpful.
>
> Many thanks you all.
>
> Cheers,
>
> Alan
>
> --
> Alan Wilter S. da Silva, D.Sc. - CCPN Research Associate
> Department of Biochemistry, University of Cambridge.
> 80 Tennis Court Road, Cambridge CB2 1GA, UK.
> >>http://www.bio.cam.ac.uk/~awd28<<
>



-- 
Alan Wilter S. da Silva, D.Sc. - CCPN Research Associate
Department of Biochemistry, University of Cambridge.
80 Tennis Court Road, Cambridge CB2 1GA, UK.
>>http://www.bio.cam.ac.uk/~awd28<<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-users/attachments/20100820/61a1d51d/attachment.html>