Avogadrolibs UHF calculation representation

Adding Avogadro developers list to CC, this is probably most appropriate there.

On Mon, Sep 14, 2015 at 9:14 AM, Bryce Anderson
banderson@fas.harvard.edu wrote:

First of all I should state my motivations: what I want is proper plotting
of UHF wave functions including being able to select the spin and get the
correct HOMO/LUMO if that is a ‘automatic’ feature. If things go well, I’d
like to see support for more interesting features (not necessarily UHF
related) such as Charge Decomposition Analysis (CDA) and visualizing the
results of TD-DFT calculations, but those are distant future dreams.

Sounds great.

The current state of avogadrolibs master branch on GitHub (currently at
commit 65141530f6831c6364b71230512097b9d1de95ae) has poor support for
unrestricted (UHF) calculations. My concerns are the lack of plotting
features for UHF (the plotting interface is completely unaware of UHF) and
the partial/broken parsing of quantum output. Functions like lumo() are
completely unaware of UHF and can return incorrect results in UHF

It has some beginnings, but it honestly has no exposed support for any
open shell calculations at this point. There is some API that Albert
added, and we have bounced some ideas around, but it was not completed
and no user interface elements are present so that a user could
visualize the beta MOs.

I have made a PR that is a work in progress, #38 on Github, that more or
less addresses my concerns. Part of it is removing default arguments for
many of the functions that have a different meaning for RHF and UHF
calculations which turns out to be controversial.
A few examples of functions that drop defaults are

virtual unsigned int molecularOrbitalCount(ElectronType type) = 0;
unsigned int electronCount(ElectronType type);
in the BasisSet class.

Not controversial, but we have already thought about some of this and
I think there are better solutions in this case. We also have some
conventions used in the API, and I would like to keep things as
consistent as possible. I think we could verify correctness with some
additional asserts that can be triggered at runtime based upon the
input type for example.

Less controversial (I assume) is correcting a few of the quantumio parsers
(I believe they are corrected: I don’t have first hand experience with many
of the packages that generate the results in the avogadrodata repository, if
the examples exists at all) to either emit the UHF information they already
parsed or to actually parse it. I doubt they are complete but I believe they
are moving in the right direction. They really need examples and testing for
both RHF and UHF calculations.

Agreed, building up examples of both types, and improving verification
of results would be extremely useful for us all. I would really like
to add the capability to display this class of calculations, and am
more actively working on this part of the code now as I have a project
to develop improved integration with NWChem output too.

I have brought up some suggestions as to refining the type model to drop

some of the features from BasisSet that are are not actually basis set
related. I think the current representation would be more aptly named
WaveFunction. I have made an initial attempt to separate the concepts of
’wave function’ and ‘basis set’ but the combinations of Rhf/Uhf with STO/GTO
make that abstraction very repetitive at best. The idea was to create a new
type WaveFunction that contains a basis, the energies and coefficients. It
would have subtypes RhfWaveFunction and UhfWaveFunction. The problem is
that setting the MO coefficients for STO and GTO would require further type
refinement to classes StoRhfWaveFunction etc. or shifting the point of
representation duplication to an even less desirable position. Ultimately,
I’m inclined to abandon this effort unless someone has a good suggestion
about how to avoid the excessive duplication.

I remember Albert and I going down a similar path, and becoming
concerned about duplication and questioning if it was worth it. I
would love to focus on a minimum viable product in terms of user
interface for open shell, and how we expose that in an intuitive way
in the graphical interface. We could then look at what API is missing

  • and you pointed out several bits in the calculation of the cubes for

These classes have undergone some refactoring already, where the data
structure is now (mostly at least) separate from the algorithms that
act upon them. As a first step do we literally just need a drop down
for alpha/beta when the calculation is open shell for example?

Thanks for looking at this, and providing examples.

Best wishes,


As a first step do we literally just need a drop down
for alpha/beta when the calculation is open shell for example?

Yes. Something like this. At some point, adding an “orbital diagram” or porting the Orbital DockWidget from 1.x becomes a useful UI.


I should comment about STO vs. GTO… Since we’re primarily interested in visualization, it may be worthwhile to simply convert all STO wave functions to GTO via STO-3G coefficients.

I don’t have the formulas handy, but this would solve a great many issues. For example GAMESS-US will use STO descriptions for semiempirical calculations. So until you start reading the file, you don’t know if a GAMESS output file really has GTO or STO wave functions.

Similarly, Molden files can incorporate either.

I think it’s something to add to the todo - since STO are not as frequently used.