<div dir="ltr">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.<br><br>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.<br><br>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. <br>A few examples of functions that drop defaults are<div><br>`virtual unsigned int molecularOrbitalCount(ElectronType type) = 0;`<br>`unsigned int electronCount(ElectronType type);`<br>in the `BasisSet` class.<br><br> 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.<br><br>    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.<br></div></div>