Re: [AMBER-Developers] Proposed parm top addition

From: Carlos Simmerling <carlos.simmerling.gmail.com>
Date: Thu, 2 Feb 2012 08:32:48 -0500

I worry about this- if we know the behavior may be incorrect, giving a
warning isn't very strong. i think the reality is that most users assume
all is well as long as the MD runs. In my experience most do not read the
output files in detail.


On Wed, Feb 1, 2012 at 12:52 PM, James Maier <jimbo.maier.gmail.com> wrote:

> >
> > > [Presumably, all prmtop files that have ff12SB
> > > atom types will have been created by Amber12 tleap....how can we
> enforce
> > > that?]
> >
> > It'll be released with Amber 12. The only way that will be circumvented
> is
> > if someone steals the ff12 file and uses it with an older leap rather
> than
> > just building the (free and easy to install) AmberTools 12. I don't think
> > this is likely to happen, especially when we stop supporting old
> AmberTools
> > immediately after a new release. Is this good enough, though?
> >
>
> I think it's reasonable to expect that one would use the latest AmberTools
> with ff12SB, but I donít know if that should be counted on. Unfortunately,
> leap glosses over undefined commands so putting a version "require" command
> in the leaprc file won't help to enforce, unless such a command actually
> already exists and somehow escaped my attention.
>
> Short of that, I think printing a warning if assigning GB (or other)
> parameters without atomic numbers, as Jason suggested, is probably the best
> option. Something like: "WARNING: Assigning GB parameters based on atom
> types. This will lead to incorrect results if using later than ff10.
> Rebuild topology file with AmberTools 12 to remove this warning." At
> least sander/pmemd will tell users what's happening.
>
> The list of atom types in the GB parameter assignment code should then stop
> at CI (bsc0) and CX (ff10).
>
> To answer Jason's previous question about what the hybridization numbers
> mean and possibly shed some light as to why H are sp3:
>
> The values that I had leap print for hybridization were the integers that
> leap used to store this information. This turned out to be 1 for sp1, 2
> for sp2, and 3 for sp3---the number of p orbitals, as was suggested.
> Taking a second look, leap does not appear to recognize any other
> hybridizations. If the hybridization information cannot be trusted, and
> wonít be made accurate any time soon, it probably shouldn't be used to
> assign parameters.
>
> I was looking to hybridization because GBSA parameters were assigned based
> on comparisons, for example, to CT---which I saw as the de facto sp3
> carbon. I was thinking of the possibility of carbanions and other such
> things, but perhaps they wouldn't be CT, anyway.
>
> James
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Feb 02 2012 - 06:00:02 PST
Custom Search