Re: [AMBER-Developers] Proposed parm top addition

From: Brent Krueger <kruegerb.hope.edu>
Date: Thu, 2 Feb 2012 10:19:18 -0500

As someone who follows this list mostly as a user, I would like to second
Carlos's observation that a warning in the output file is probably not
sufficient.

I will make a naive suggestion that y'all can shoot down. My understanding
is that the current topology file format is quite flexible. Couldn't it be
the case that there is a field there that might indicate something about
both the version of leap and the force field that were used to create the
topology file? For instance, maybe the %VERSION field reports that AT12
and parm99sb were used to generate the file. I suppose identifying a single
version of a FF is not well-defined. Maybe all parm and frcmod files that
were loaded could be identified (yuck)? At any rate, certainly AT12 leap
could put some flag there to reassure pmemd/sander that everything is
kosher for the particular combination of leap and FF that this particular
discussion has focused on. Then pmemd/sander could choke if such a flag
were missing.


On a related note, as someone who uses different FFs and works with
residues that require custom frcmod files essentially 100% of the time, I
would really love to have some information in the topology file itself
about the parameters that were used to make it. So, if such information
aided the original problem of this discussion, how nice that would be.


Cheers,
Brent



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

> Unless that "expert" flag is just commenting out the mexits and
> recompiling :)
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Candidate
> 352-392-4032
>
> On Feb 2, 2012, at 9:12 AM, Adrian Roitberg <roitberg.ufl.edu> wrote:
>
> > While an interesting idea, you might end up with a Lake Wobegon slant,
> > where everyone thinks they are expert...
> >
> > On 2/2/12 9:11 AM, Carlos Simmerling wrote:
> >> 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
> >
> > --
> > Dr. Adrian E. Roitberg
> > Professor
> > Quantum Theory Project, Department of Chemistry
> > University of Florida
> > roitberg.ufl.edu
> >
> > _______________________________________________
> > 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
>



-- 
_______________________________________________
Brent P. Krueger.....................phone:   616 395 7629
Associate Professor................fax:       616 395 7118
Hope College..........................Schaap Hall 2120
Department of Chemistry
Holland, MI     49423
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Feb 02 2012 - 07:30:02 PST
Custom Search