Adding Avogadro developers list to CC, this is probably most appropriate there.
On Mon, Sep 14, 2015 at 9:14 AM, 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.
It has some beginnings, but it honestly has no exposed support for any
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
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 think there are better solutions in this case. We also have some
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.
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
Agreed, building up examples of both types, and improving verification
(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.
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 remember Albert and I going down a similar path, and becoming
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.
concerned about duplication and questioning if it was worth it. I
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.