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
Received on Thu Feb 02 2012 - 06:30:03 PST
