Custom Search
-- 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-developersReceived on Thu Feb 02 2012 - 06:30:04 PST