- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

From: David A. Case <case.scripps.edu>

Date: Tue, 28 Jun 2005 16:26:48 -0700

On Tue, Jun 28, 2005, Guanglei Cui wrote:

*>
*

*> I just want to add something related to what Ross is seeing here. I
*

*> created a topology file for methylmonophosphate with gaff with a
*

*> recalculated dihedral profile for dihedral type X -os-p5-X . The
*

*> definition in gaff.dat for this term is,
*

*>
*

*> 3 2.400(pk) 0.00(phase) 2.0(pn)
*

*>
*

*> First, it's not clear to me why the periodicity is 2 here. I decide to
*

*> overwrite the gaff definition with my own parameters (defined in frcmod
*

*> as X -os-p5-X ). But what I found in the resulted pmftop (see
*

*> attachement), this term was defined twice, one with the gaff term and
*

*> another with my parameters. But this didn't seem to affect anything.
*

*> This topology file (mmp.new.top) gave a good match with the enery
*

*> profile calculated with QM, so I assume my definition was used. But it's
*

*> confusing though.
*

You can reduce the confusion by using the rdparm program to print out

things explicitly. For your topologies:

--------------------------------------------------------------------------

Date: Tue, 28 Jun 2005 16:26:48 -0700

On Tue, Jun 28, 2005, Guanglei Cui wrote:

You can reduce the confusion by using the rdparm program to print out

things explicitly. For your topologies:

--------------------------------------------------------------------------

-- quine% rdparm mmp.gaff.top RDPARM MENU: printdihedrals Dihedral pk phase pn atoms 1: 0.383 0.00 3.0 :1.H1 :1.C1 :1.O1 :1.P1 (2,1,5,9) 2: 0.383 0.00 3.0 :1.H2 :1.C1 :1.O1 :1.P1 (3,1,5,9) 3: 0.383 0.00 3.0 :1.H3 :1.C1 :1.O1 :1.P1 (4,1,5,9) 4: 0.800 0.00 2.0 :1.C1 :1.O1 :1.P1 :1.O2 (1,5,9,6) 5: 0.800 0.00 2.0 :1.C1 :1.O1 :1.P1 :1.O3 (1,5,9,7) 6: 0.800 0.00 2.0 :1.C1 :1.O1 :1.P1 :1.O4 (1,5,9,8) -------------------------------------------------------------------------- -- quine% rdparm mmp.new.top RDPARM MENU: printdihedrals Dihedral pk phase pn atoms 1: 0.383 0.00 3.0 :1.H1 :1.C1 :1.O1 :1.P1 (2,1,5,9) 2: 0.383 0.00 3.0 :1.H2 :1.C1 :1.O1 :1.P1 (3,1,5,9) 3: 0.383 0.00 3.0 :1.H3 :1.C1 :1.O1 :1.P1 (4,1,5,9) 4: 0.800 0.00 2.0 :1.C1 :1.O1 :1.P1 :1.O2 (1,5,9,6) E 5: -0.143 3.14 3.0 :1.C1 :1.O1 :1.P1 :1.O2 (1,5,9,6) 6: 0.800 0.00 2.0 :1.C1 :1.O1 :1.P1 :1.O3 (1,5,9,7) E 7: -0.143 3.14 3.0 :1.C1 :1.O1 :1.P1 :1.O3 (1,5,9,7) 8: 0.800 0.00 2.0 :1.C1 :1.O1 :1.P1 :1.O4 (1,5,9,8) E 9: -0.143 3.14 3.0 :1.C1 :1.O1 :1.P1 :1.O4 (1,5,9,8) -------------------------------------------------------------------------- -- If you add (via frcmod) a torsion that has a *different pn* than the one in the standard gaff.dat file, your torsion will be added to the torsion in the standard force field. This is what you see above: the "mmp.new.top" has both the original 2-fold gaff term and your added 3-fold term. On the other hand, if the frcmod torsion exactly matches both the atoms and the pn of the original file, then your term would overwrite the original one. Hence if you wanted to remove the original 2-fold term and add your 3-fold term, your frcmod file would have to have a 2-fold term with 0.0 for pk (to effectively remove this term), and a 3-fold term (to add in what you want). Your message says "this didn't seem to affect anything"; I'm not sure what you mean there: your "new" topology file definitely seems to still have the 2-fold torsion term. Try adding a 2-fold term with zero pk value in your frcmod file to see what happens. [Incidentally, it is very unusual to have a 3-fold term with a phase of pi, and with a negative pk! Are you sure this is what you want?] The rules for replacing torsions listed above make sense to me, and I think(?) they are correctly implemented in LEaP. The problems seem to arise from a similar question about whether a specific torsion should override a wild-card torsion or not. Here, it currently looks like LEaP does not do such comparisons in a consistent fashion (cf. recent posting by Ross Walker.) ...dacReceived on Wed Apr 05 2006 - 23:49:55 PDT

Custom Search