On Wed, Mar 27, 2013 at 10:35 AM, Geoffrey Hutchison <
geoff.hutchi...@gmail.com> wrote:
> > Maybe a proposed simplification of the valence system
> > http://forums.openbabel.org/ImplicitH-failures-td2990439.html
> > should be looked at again.
>
>
> Copy/paste from Chris's earlier message:
> > A simpler and more obvious model for this purpose has essentially a
> > single IMPVAL for each charge state of the molecule. (Only if you are
> > interested in radicals or hydrogen on the higher valency states of
> > second row elements do you need another rule for each higher valence.)
> > There is no need for any skilful fine tuning. It is more maintainable
> > and will be faster because not so many SMARTS patterns need to be
> > matched. Up to now, It has worked for everything I've tried (although
> > this not very extensive), except with test_formula, where the fault is
> > in a couple of erroneous results in formularesults.txt, which at least
> > shows the old model was error-prone and needs some more tweaking of
> > phosphate structures.
>
>
> I would be strongly in favor of implementing such a change now.
> Performance testing has suggested that we perform way too many SMARTS
> matching when doing typical things like parsing SDF or aromaticity
> detection.
>
> Chris, do you think your revised model can be integrated now? Based on my
> schedule, I think a v2.4 release would be mid-summer. I would like to
> finish my distance geometry implementation for coordinate generation and
> conformer sampling and I think there would be plenty for a new release.
>
> It seems like Craig and Noel are strongly in support of this too.
>
Yes, and additionally (with the caveat that I'm not a chemist) ...
I'd like to see a clearly written English-language description of the terms
we're going to use for an atom's electronic state, and how they relate and
overlap:
number of bonds
bond order
H-count (implicit/explicit)
charge
valence
hybridization
spin multiplicity
radical
Once the concepts and relations are clearly defined, I think we should
select a smaller number of "editable" parameters, and then define the
remaining in terms of the editable parameters. For example, I'd probably
select:
add bond, set bond order
set implicit H count
set charge
Then I'd probably want a method like this (sort of a property, but depends
on the specific configuration of the atom, and avoiding the word "valence"
for now due to conflicts with how that term is currently used):
atom->GetNaturalTotalBondOrder();
atom->GetNaturalTotalBondOrder("sp3");
The "natural" total bond order: the sum of the bond orders of all bonds to
this atom, including implicit and explicit H atoms, for this element in
this configuration. This function would have an optional hybridization
parameter that would default to a predefined value for each element.
Examples:
F would be 1, the S in sulfur dioxide O-S-O would be 2, and the S in
sulfuric acid O=S(=O)(O)O would be 6.
Finally, the following would be derived properties (i.e. no "SetXXX()
funciton):
total bond order (sum of actual individual bond orders including H)
hybridization
total H count
spin multiplicity
radical (?)
I put a (?) after "radical" because I don't understand it well. It might
be that a SetRadical() function is needed ... and if so, then the concept
of what "radical" means needs to be thoroughly explained.
The particular choice of which properties are primary and which are derived
is surely a topic for discussion. However, it's really important to avoid
overlap. For example, if we decide that we need a set-hybridization
function, then we probably can't have both set-implicit-H and set-charge
functions.
Craig
------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel
