Re: [AMBER-Developers] Proposed parm top addition

From: B. Lachele Foley <lfoley.uga.edu>
Date: Wed, 1 Feb 2012 02:13:25 +0000

I like both. I agree about being conservative, but I can see uses for both.

Regarding hybridization...

The hybridization tells the electronic geometry, which is not the same as the number of bonds. It could be used to help ensure sane geometry. Beyond that, though, I can't say I know enough about sander or pmemd to guess what it would be used for, but that seems useful.

On that note, while compiling the types table, I was reminded of something that has long puzzled me. Why are hydrogen atoms given sp3 hybridization? Why aren't they s? I've never heard of anyone calling them sp3, and I don't think that's even something they can do even in really weird conditions. The only result of this seems to be that leap will occasionally bond two or more things to a hydrogen if the user makes an input error.

In gmml/gems, we plan to keep up with hybridization for sanity checks on geometry, and record the expected number of bonds as a separate field.

:-) Lachele

Dr. B. Lachele Foley
Complex Carbohydrate Research Center
The University of Georgia
Athens, GA USA
lfoley.uga.edu
http://glycam.ccrc.uga.edu

________________________________________
From: Jason Swails [jason.swails.gmail.com]
Sent: Tuesday, January 31, 2012 3:43 PM
To: AMBER Developers Mailing List
Subject: Re: [AMBER-Developers] Proposed parm top addition

My 2c and comments:

On Tue, Jan 31, 2012 at 2:47 PM, James Maier <jimbo.maier.gmail.com> wrote:

> %FLAG ATOMIC_NUMBER
> %FORMAT(10I8)
> 7 1 1 1 6 1 6 1 1
> 6
> 1 1 6 1 1 6 1 1 7
> 1
> 1 1 6 8 7 1 6 1 6
> 1
> 6 1 1 1 6 1 1 1 6
> 8
> 7 1 6 1 6 1 1 6 6
> 1
>

This would be dramatically useful for QM/MM as well, as well as other
things that need atomic number. But what is the proposed behavior for
sander/pmemd? Will they just choke and fail if these sections are not
present? I'd lean against that, both for my sake and for others' sake that
want to upgrade -- since they will now face the situation that they must
redo all of their topology files in order to take advantage of new upgrades
to sander and pmemd. (Not to mention the need to remake all of the tests...)

My suggestion would be to have sander/pmemd default to sqm's method of
determining atomic number (but print a helpful warning about what is
happening). If you know general atomic masses, you can assign every atom,
including its isotopes, by just selecting the element that has the smallest
atomic mass difference with the mass of the atom you're trying to identify.

%FLAG HYBRIDIZATION
> %FORMAT(10I8)
> 3 3 3 3 3 3 3 3 3
> 3
> 3 3 3 3 3 3 3 3 3
> 3
> 3 3 2 2 2 3 3 3 3
> 3
> 3 3 3 3 3 3 3 3 2
> 2
> 2 3 3 3 3 3 3 2 2
> 3
>

Is this really more flexible than just counting the number of atoms bonded
to your atom of interest? Also, what does the number mean? The number of
P-orbitals in the hybridization? What about spd hybridization schemes? I
also don't think hybridization is even important in leap (it's used for
some minimizations?), so I think it's best to _not_ trust that information
to be accurate, anyway -- but I could be mistaken on this point.

...
>
> We modified sander and pmemd to read these sections and use the information
> for parameter assignment. As one might expect, with the new code, the GB
> results are the same whether using CT, CX, or 2C.
>
> We wanted to present this to the developer's list for two reasons. First,
> we'd like everyone else to know about this development and have a chance to
> discuss before we think about pushing the changes.


I like the idea of ATOMIC_NUMBER, because it removes ambiguity and adds
something substantial to the topology file. I don't like the idea of
hybridization because I don't see it adding any new information to the
topology file and just causing a potential source of ambiguity in the
future. (We also don't want to push the notion that hybridization is part
of the underlying force field, do we?)


> Second, while we're
> proposing an addition to the parm top specification, we'd like to invite
> everyone to think about other information that could be useful in our
> topology files.
>

IMO, we should be conservative with the information we add to the prmtop
(it's already large). If the information is well-defined in another form,
we should convert it to the form we want in code (sander/pmemd), rather
than adding another section to the topology.

+1 for ATOMIC_NUMBER, though :).

Sorry for the monologue,

All the best,
Jason

--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
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 Tue Jan 31 2012 - 18:30:03 PST
Custom Search