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