Open Babel and virtual

Development
1

On Aug 21, 2006, at 1:02 PM, Donald Ephraim Curtis wrote:

One suggestion i have is that functions we use from OB should be
virtual. That way we can write an operational library (say FF
calculations) that works on OBMol. If the OBMol functions are virtual
and we pass our Molecule to the operational library it’ll call our
virtual functions. This also means that any operational library we
develop will work with and without avogadro. (like our geometric
optimizaion functions).

Right. As I said, I suspect there will need to be some changes to
Open Babel (e.g., virtual functions) to accommodate such things.
Here’s what comes off the top of my head:

  • Improved “grid” class for electron density, etc. Needs to be part
    of OBBase to allow import/export through OBConversion and rendering.
  • OBGenericData improvements:
    – simple key/value classes for storing arbitrary combinations of
    integers, floats, doubles, GL matrixes, etc.
    – class for handling vibrational calculations (e.g., energies,
    atomic displacements)

I’m trying to think of this now, because it seems like Open Babel
updates are occurring about once per year. Which means that anything
needed for Avogadro must be planned sooner rather than later.

Anything needed for Open Babel in regards to constraints, freezing
atoms, or EFP?

-Geoff

2

(Mon, Aug 21, 2006 at 02:27:05PM -0400) Geoffrey Hutchison geoff.hutchison@gmail.com:

Right. As I said, I suspect there will need to be some changes to
Open Babel (e.g., virtual functions) to accommodate such things.
Here’s what comes off the top of my head:

  • Improved “grid” class for electron density, etc. Needs to be part
    of OBBase to allow import/export through OBConversion and rendering.

Ok sounds good.

  • OBGenericData improvements:
    – simple key/value classes for storing arbitrary combinations of
    integers, floats, doubles, GL matrixes, etc.

I misread this the first time. I assume when you say “storing” you mean
importing and exporting, not for avo runtime use.

– class for handling vibrational calculations (e.g., energies,
atomic displacements)

I think this should be a separate library (external but build on top of
OB).

I’m trying to think of this now, because it seems like Open Babel
updates are occurring about once per year. Which means that anything
needed for Avogadro must be planned sooner rather than later.

Anything needed for Open Babel in regards to constraints, freezing
atoms, or EFP?

I think that EFPs are easily handled by the key/pairs for now. Freezing
should be a flag for atoms. Bond length constraints are also handled by
the key/value pairs.

However, someone commented on the OB list about how doing .Copy or
whatever the duplicate class function is; did not copy this extra data.
That should be put on the list.

I feel like we’re really made some huge progress so far. I know i’m
going to get bogged down here soon updating the OB gamess stuff and my
dissertation stuff.

PS: OpenBabel has an easy acronym; ob. We need something like ag or agd for
avogadro. haha

-Donald

3

On Aug 21, 2006, at 3:02 PM, Donald Ephraim Curtis wrote:

  • OBGenericData improvements:
    – simple key/value classes for storing arbitrary combinations of
    integers, floats, doubles, GL matrixes, etc.

I misread this the first time. I assume when you say “storing” you
mean
importing and exporting, not for avo runtime use.

Both. See, the catch for Avogadro is that it may declare subclasses
of OBMol, OBAtom, etc. But these will need to convert to/from an
OBMol. So there will have to be some code for copying an
Avogadro::Molecule to the OBMol base class via the OBGenericData
interfaces.

(e.g., let’s say Avogadro::Molecule has some private data like color.
This would need to go into OBPairData – which is unfortunately
string-based.)

Hope that makes sense?

However, someone commented on the OB list about how doing .Copy or
whatever the duplicate class function is; did not copy this extra
data.
That should be put on the list.

Definitely. The biggest problem with some of the OBGenericData
classes is that they often include pointers to OBAtom. Well, if you
copy an OBMol, all those pointers need to be updated.

But in OB-2.1, the

I feel like we’re really made some huge progress so far. I know i’m
going to get bogged down here soon updating the OB gamess stuff and my
dissertation stuff.

I think we’re making some great progress too. Progress will
undoubtedly get bogged down for many reasons (e.g., I have to find a
job, finish a pile of papers, OB-2.1, etc.). But it seems like we can
find more contributors to help if we can get some sort of prototype
release at some point.

PS: OpenBabel has an easy acronym; ob. We need something like ag
or agd for
avogadro. haha

Mentally, I’ve been using “Av” or “Avg”. If we wanted to be cute,
there’s “Na” for Avogadro’s number. Not sure if any program can
handle 6e+23 atoms yet.

Cheers,
-Geoff