Hi, Dave
I did use rdparm to check out the built torsions. I was confused because
I thought replacement of a torsion definition will occur if the type
matches. Thanks for clearing this.
Basically what I did is refitting the c3-os-p5-o term in gaff. I
calculated the torsion profile with MP2/6-31+g*//HF/6-31+g*. In
qm_mm.jpg, the black open circle is the QM profile and the red open
square is the MM profile calculated with zeroed c3-os-p5-o term. The MM
profile calculated using gaff only differ by a constant from the profile
calculated with this torsion zeroed. The zeroed c3-os-p5-o term (see
mmp.nox.top) was introduced as a 3-fold term with zero pk in frcmod, and
it did replace the 2-fold generic term in gaff (see mmp.gaff.top). After
fitting the difference, I got the negative 3-fold torsion term with a
phase of pi. It seems the 2-fold term in gaff only introduced a constant
to the profile. So even with dual definition of this torsion in
mmp.new.top, I was still able to see a good match between the QM and MM
profiles (with the new parameters, newfit.jpg). I think this is what I
meant by "this didn't seem to affect anything". Since cos(x)=-cos(x-pi),
I could make it 3-fold term with a phase of 0 and a positive pk by
selecting a different conformer as reference.
Regards,
--
Guanglei
David A. Case wrote:
> 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.)
>
> ...dac
>
Received on Wed Apr 05 2006 - 23:49:55 PDT