Re: [AMBER-Developers] Proposed parm top addition

From: Jason Swails <>
Date: Thu, 2 Feb 2012 08:53:11 -0500

On Feb 2, 2012, at 8:46 AM, Carlos Simmerling <> 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 <> wrote:
>> On Feb 2, 2012, at 8:32 AM, Carlos Simmerling <>
>> 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 <>
>> wrote:
>>>>>> [Presumably, all prmtop files that have ff12SB
>>>>>> atom types will have been created by Amber12 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 mailing list
>> _______________________________________________
>> AMBER-Developers mailing list
> _______________________________________________
> AMBER-Developers mailing list

AMBER-Developers mailing list
Received on Thu Feb 02 2012 - 06:00:04 PST
Custom Search