i've always felt that there should be an "expert" flag that would turn lots
of hard errors into warnings and let you continue anyway...
On Thu, Feb 2, 2012 at 8:53 AM, Jason Swails <jason.swails.gmail.com> wrote:
>
>
> On Feb 2, 2012, at 8:46 AM, Carlos Simmerling <carlos.simmerling.gmail.com>
> wrote:
>
> > 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.
>
> But from a selfish perspective, all of the prmtops that I've been running
> with the latest development version will be useless overnight.
> Non-developers may also find themselves wanting to run new methods on an
> old prmtop to see how that method works compared to what they had done.
> This change would make all that a much harder exercise.
>
> >
> > 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
>
> _______________________________________________
> 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:30:02 PST
