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
Received on Tue Jan 31 2012 - 13:00:02 PST
