I think the proposed _spinmultiplicity on an atom should be seen as an
inherent structural attribute. Without it, radicals are incorrectly
represented in OBMol when the hydrogens are implicit. I doubt it should be
considered as extra data in OBGenericData, or only be present in special
purpose formats, like those for drawing or presentation. Organic radicals
are important in some fields of chemistry and can probably be represented in
any file format if the hydrogens are explicit (although I am familiar with
very few formats). It would be a pity to have a framework which can
sometimes corrupt molecular data, when the solution involves so little
change. Even the formalised and trademarked CML is to have it!
[Without knowing anything about it, is it necessary to have some files in a
separate /math directory? I have found it inconvenient.]
----- Original Message -----
From: "Michael Banck" <mbanck@...>
To: "Geoff Hutchison" <ghutchis@...>
Sent: Wednesday, October 08, 2003 8:52 PM
Subject: Re: 1.100.2 release (was Re: [Open Babel] 1.100.2 and 3rd parties
> (CCing openbabel-discuss since I this brings some new things up)
> On Tue, Oct 07, 2003 at 05:51:48PM -0500, Geoff Hutchison wrote:
> > >I won't have time to hack more on openbabel during the next weeks, so I
> > >propose to release 1.100.2 soonish, in order to fix that serious
> > >installation bug.
> > What bug is that?
> The headers in src/math/ did not get installed in
> $includedir/openbabel/, so building 3rd party stuff like xdrawchem fails
> with errors because mol.h drags some headers from math/ in. At least
> that's how I see the problem, it was my fault of course, I forgot to
> include those when I switched openbabel to automake and you fixed it
> only after the 1.100.1 release, IIRC.
> > The new _spinmultiplicity element can be handled through the
> > OBGenericData class, IMHO.
> For something that makes sense to have for more than one or two file
> formats, it might be nice to have it as a proper attribute. Putting even
> more stuff into OBMol does not seem very wise though.
> As a solution, I once thought about having derived classes off OBMol
> like OBAbInitioMol, OBCrystStrucMol and OBChemDrawMol which include more
> attributes which are exclusive to that class, while OBMol only has the
> common denominator of all (or at least a lot) of file formats, like
> atom names, coordinates and (perhaps) bonds.
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> OpenBabel-discuss mailing list