[Openchemistry-developers] avogadrolibs UHF calculation representation

[Marcus D. Hanwell]

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

On Mon, Sep 14, 2015 at 9:14 AM, Bryce Anderson
<banderson at 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
> calculations.

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

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,

Marcus