Re: [AMBER-Developers] Proposed parm top addition

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

i guess we need to think about what kind of "bad" behavior we aren't going
to allow.
if users can take the new force field (free) and run it with older Amber
(not wanting to pay for upgrade), then the results will be incorrect
(unless I misunderstand something). I don't see any way around this unless
we create patches for older amber to support the new force fields, or make
it clear somehow that new Amber is required even though it will appear to
work properly with older amber.

the above is separate from whether in the new MD codes we force the users
to use newer leap, which seems pretty easy to do from a technical
standpoint.

On Thu, Feb 2, 2012 at 8:43 AM, Jason Swails <jason.swails.gmail.com> wrote:

>
>
> On Feb 2, 2012, at 8:32 AM, Carlos Simmerling <carlos.simmerling.gmail.com>
> wrote:
>
> > 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.
>
> Then perhaps we can make the default behavior be " more right" by doing
> the suggested element matching based on atomic masses.
>
> Alternatively I could add a command in parmed to add the atomic number
> section so people can easily adapt their prmtops to the new standard. That
> would make it less painful to make Amber 12 backwards incompatible.
>
> Thoughts?
>
> >
> >
> > 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
>
> _______________________________________________
> 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:03 PST
Custom Search