- an extension which reads some AIM program’s output files and adds the
property to the molecule’s designated generic property storage
Yes. Actually, the advantage of Avogadro is that we also read other
types of output files which can supply the wavefunction on arbitrary
grids (e.g., for MO or ESP surfaces). So we’re not limited to AIM files,
in theory, you could also hook into handling Gaussian fchk files and the
like.
Right now, Eric has stuck to reading WFN files.
Does Open Babel have a wave function format? It seems that the prefered
path for reading files is through Open Babel routines. I think that the
fchk files get read first by OB and then re-read before it generates the
orbitals?
I thought I saw a thread where Marcus and Konstantin were interested in
adding MOs to Open Babel.
The WFN format is the old POLYATOM format. It’s kind of a pain to work
with unless you are using Fortran. You also have to remember to generate
it with the right keyword, and hope that the quantum chemistry program has
the capability.
We’re a stone’s throw away from reading fchk, MOLDEN, etc. It also looks
like Geoff has GAMESS-US almost finished (though GAMESS generates WFN
files, too). For my code, the shells should be unrolled into normalized
Cartesian Gaussian primitives, that is 6D instead of 5D, etc.
- an engine which reads those properties and renders the list of BCPs,
RCPs, CCPs, and NACPs provided * an engine which reads the same
properties and renders bond paths and paths to ring and cage points if
you have them
I believe Eric has done the extension and the rendering engines you
describe. It’s on his GitHub repository:
http://github.com/ecbrown/avogadro
The code definitely generates molecular graphs with Nuclear Critical
Points (NCPS), Bond Critical Points (BCPs) and Bond Paths. It uses the
LSODA integrator, which is capable of switching between non-stiff and
stiff methods automatically.
I’m a big proponent of doing things correctly and with as little user
interaction as possible even if they happen to be more expensive. The
methods now need to be tuned, but they do work and there is no “fiddling”
with parameters.
As for Ring and Cage Critical Points (RCPs and CCPs), they are more
difficult to locate than NCPs and BCPs because the heuristics for locating
them are not as well defined. That is, NCPs are (usually) near nuclear
centers, BCPs are (roughly) between NCPs. If you have a ring of BCPs, then
there must be an RCP somewhere, but it is not necessarily anywhere close
to the geometric center of the three or more BCPs. For CCPs, it seems to
be worse.
Just as an FYI, I am going to get the Charge Integration (Quadrature)
going before I work on RCPs and CCPs. My plan is to use CUBPACK and do
adaptive quadrature.
(Also I should point out that all of the routines run across all
processors using QtConcurrent.)
- a tool which can read the same properties and measure the distances
between CPs if you like that sort of thing
Not a bad idea.
Right, there is tons of stuff to do! :-))))
Adding a demonstrated and intended way to implement these sorts of
custom data sets seems like a good idea to me.
Right, that’s my point – there’s no example code, so Eric has done it
kinda by brute force. (No offense intended.) My idea is to set up some
example code for how to handle custom data without needing to add more
interfaces to the Molecule class.
Adding to the Molecule class just about killed me. I think that I
understand–add “attributes” or something similar to the Molecule object.
I will have to read more about this in the documentation.
It’s true that what I have there now probably can’t stay there. 
P.S. I suspect anyone else interested in AIM analysis in Avogadro might
want to contact Eric (cc’ed) and offer some help testing and/or
reviewing the code. 
Yes, please write me if you would like to help or if you have
comments/criticisms! Thanks especially to Geoff and Marcus for their help
and encouragement getting this subproject started!!!
All the best,
Eric