[Openchemistry-developers] avogadrolibs UHF calculation representation

[Bryce Anderson]

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.

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
calculations.

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.

 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.

    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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/openchemistry-developers/attachments/20150914/1b0498ab/attachment.html>