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 <[email protected]> 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<<
-- gmx-users mailing list [email protected] http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [email protected]. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
