On Sat, 2014-02-01 at 23:57 -0500, James Maier wrote:
> On Sat, Feb 1, 2014 at 11:27 AM, David A Case <case.biomaps.rutgers.edu>wrote:
> >
> > I wonder if we (i.e. James) can add another column in the MASS section for
> > hybridization.
>
>
> Done, in the same branch. (accepts sp3, sp2, sp1, and sp0~ corresponding to
> the "0" hybridization)
>
> A potential caveat:
> LEaP might confuse the comment line with the hybridization, if the first
> word matches a valid hybridization... so if you specify atomic number,
> ensure the next string is the correct hybridization or gibberish
> ('aliphatic' would be fine, for instance).
>
> As a bonus, many comments actually start with the hybridization of the atom
> type, anyway.
>
> Then we would not need to have the addAtomTypes section of the
> > leaprc files
> >
>
> I made a leaprc.ff13SB sans addAtomTypes in the AtomicNumberAtomTypes
> branch, as a proof of principle. It seems to work, though I've only tested
> it on a few proteins familiar to me, so far.
>
>
> > This may be a bit tricky: one has to be sure that any side effects of the
> > "addAtomTypes" command are also done when the MASS section of the
> > parm.dat file is read.
>
>
> I haven't found any such side effects. Though given my limited
> understanding of LEaP, that's not _necessarily_ a good sign...
>
> I'll summarize my thoughts and code changes. If anything sounds suspect, I
> invite whomever knows better to please chime in:
>
> 1. My understanding is that the sole purpose of addAtomTypes is to populate
> vaAtomTypes (an array of atom type, element, and hybridization)
>
> 2. Information was previously taken from vaAtomTypes to complement the
> information in Amber ParmSets via commands starting with iAtomType
>
> 3. grep tells me that the vaAtomTypes array and related iAtomType commands
> are only used within amber.c ; my understanding is that their only purpose
> is to populate GplAllParameters (which is referenced throughout LEaP).
>
> 4. I made the ...AmberReadParmSet... routines just bypass the iAtomType
> commands that extract information from the vaAtomTypes array, whenever the
> information is available from the MASS section.
Good work! I checked this branch (ANAT) out and tried it locally on one
of my protein systems (implicit and explicit solvent, with counterions)
and RNA systems (implicit and explicit solvent, with counterions), with
different sets of GB radii.
The topologies generated with master tleap and ANAT tleap are almost
identical. All differences are in (some of) the ions' GB radii and
screening parameters. The good news here is that not only are these
numbers wholly unimportant, but master tleap was getting them 'wrong' by
assigning C radii to the Cl ions instead of the "dac's arbitrary choice"
for the meaningless filler values.
I couldn't find any issue in your tleap additions and playing with
various force fields (some leaprcs that _did_ have the addAtomTypes and
your ff13SB leaprc that did not). In my opinion, this is ready to merge
into master.
Even if there are some corner cases where this gives
unexpected/undesirable behavior, it should be localized to the atomic
number and things related to it (GB parameters). That said, it looks
clean and robust.
Thanks!
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Feb 04 2014 - 09:30:03 PST
