Still needs some work and testing, but it’s coming along
One key question is whether to keep the header / MO index column (e.g., MO 5 is the HOMO). Thoughts?
2 Likes
Fantastic!
I’ll see if I can give it a spin in the next few days.
Personally I’d prefer simply listing the occupancies of the orbitals rather than trying to assign HOMO/LUMO descriptions to them, as I find that when doing open-shell calculations, especially unrestricted ones, the description often ends up being misleading or confusing or inaccurate.
(Partly because of alpha/beta having different occupancies, partly because people understand “HOMO” to mean different things in an odd-electron system, partly because the alpha and beta orbitals can’t always be trivially and automatically paired up.)
Right now, it works only for closed-shell (which was Avo 1.2) and I’d like to keep HOMO / LUMO for that common case.
I’m inclined to merge that for 1.100 even if it doesn’t fully handle unrestricted cases.
We have to think carefully about how the “table” should work for open-shell systems.
My gut tells me there should be a column for alpha and a column for beta and you have to click on a cell (rather than a row) for a given spin orbital. So there would be four columns and probably no “status” column.
But yes, the labels would be different for an open-shell calculation. Probably something like “α MO 5 •” or “β MO 10 o”
Definitely open to suggestions for those labels / emoji. Should we use ↿ ⇂ or ↑ ↓ instead to show occupancies?
- α MO 5 ↑
- β MO 5 ↓
- β MO 10 - no arrow = unoccupied
Ok I’ve had a chance to look at the new window now so I have some more fully-formed thoughts. Great work on getting it ported, looks like it wasn’t trivial 
Firstly, the rendering status indicator:
- I find that when the label is just “Status”, it is not clear that it refers to rendering as opposed to something chemical
- The rendering status indicator says
0when nothing is loaded –0%would be better - The status is rendered with a space in
100 %which most people will find weird - I’m not sure that a percentage indicator is really necessary. Maybe a simple on/off indicator, or a traffic light with orange for loading, would be easier and clearer? Just an idea
Something else is that I can’t tell from the code how the HOMO is being determined. Is it based on orbitals.electronCount in the CJSON representation? Because this has the issue that the labels are wrong if the orbital set is not complete.
For example, I’ve attached a CJSON produced by xtb and my plugin for acetone. Since xtb only returns (and calculates too?) the “valence” orbitals, there are only 22 MOs with 22 electrons, even though the electron count is 72. This results in Avogadro labelling all the MOs as being way below the HOMO, which is incorrect.
Is there a orbitals.occupancies field in CJSON that should be used?
acetone.cjson (204.9 KB)
But it did work for open-shell too? I used it for years for precisely that.
IIRC, it only shows the alpha orbitals. Which should be what the current code does.
I’m open to better ideas. Before there was a little progress bar, but that particular feature wasn’t working well - it wouldn’t render in each cell, only in the upper left corner obscuring the table. So I disabled the progress bar for now.
Sure, no worries.
Yeah, that’s why there was previously a progress bar. I think I mentioned in the commit log that it wasn’t working. That would be the better solution, but I wanted to get something finished for testing and string translation rather than continue to fiddle with the progress bars.
RIght now, the BasisSet::homo() and lumo() calls are used, which go on the electron count. Yes, it probably should work it out based on the occupations (and also distinguish alpha and beta spin orbitals).
Yes, occupations for closed-shell and alphaOccupations and betaOccupations for open-shell.
Some of the code is more-or-less identical. Some required some minor tweaks. There were a few crashy bugs that were annoying. Pretty sure I got those fixed at this point.
1 Like
I also just got a chance to put this thing through my typical round of tests, and I have to say it looks pretty good, with a few interesting bugs that I’ve noticed.
- When I open an ORCA output, the orbital energies are all listed as zeros (I’m not sure if this is ORCA specific).
- Changing the quality of the render and then hitting “Render” renders the orbital above the one selected, i.e. if I am selecting orbital 10, it will re-render orbital 11 instead of 10. This may have something to do with the file I am testing on being an ORCA output, which I know has numbering starting at zero instead of one. I don’t use any other programs so I can’t really tell if that is the quirk.
- If I hit render on orbital 10 using any quality other than Low (which renders orbital 11), then changing the quality back down to Low and hitting render does nothing. It seems to be only Low quality that has this issue, as switching to any other quality (including Very Low) will result in the orbital being rendered again.
- As I was typing that last bit I tried some other stuff (can’t actually remember what I was trying at the time) and all of a sudden the render button just stopped working altogether for orbital 10 (again, meaning I can’t re-render orbital 11).
Also, in a matter of personal preference, I would rather the orbital table be displayed only by selection, and not automatically upon opening an output. There’s also the matter of getting the window to dock like it used to in Av1 (I may be remembering that wrong, but I think it did), although that seems like its own headache, and the window works well enough as-is.
As a suggestion, it might be nice to be able to set a default render quality. I use a pretty beefy computer for almost everything, and it most certainly can handle rendering all the orbitals at High or Very High quality, so it would be nice if I could make that the default for new files.
1 Like
That’s weird. Can you post or send me that file?
A couple of those bugs are fixed in this pull request although sometimes I also get the render button to stop working … and I haven’t tracked that particular chain-of-events down.
Yeah, I haven’t gotten into the “dock” bits of Qt yet. OTOH, there were a bunch of “bug” reports complaining the orbital window didn’t open when loading a file. It seems like the “auto-open” docks were very popular in Avogadro 1.2.
At the moment, I haven’t bothered with the settings dialog for a few options like default render quality and how many orbitals to pre-calculate - mostly because it’s a lot of new strings to translate and I’d like to release 1.100. (I know some of the translators really want to be at 100% for every release.)
The file is too big (even when compressed) to attach here, but hopefully this link works so that you can download it. Hopefully it isn’t too big of a bug to fix!
Also, just as a note, the release of 1.100 might be a good time to redirect searches for Avogadro to be to the Avogadro 2 page. Avogadro 1 is definitely not the best foot to put forward with the state that it is in, and Avogadro 2 is nearing complete parity. I think it would be good to get things moving in the right direction, perhaps just a big header on the Av1 page that shows up to try and push people towards Av2 would be a good start.
That was actually very interesting. First off it was parsing orbital energies and then clearing them?! Fixed that, then realized ORCA doesn’t print all the LUMO energies and I could get them elsewhere in that file (i.e., with the MO coefficients).
That led me to realize the regex used to parse MO coefficients (from the ORCA-enhanced Avogadro 1.2) was really buggy on your file. I’ll skip the details, but for anyone reading, be very, very careful with testing your regex.
Yeah, I was thinking along similar lines. Obviously the https://two.avogadro.cc site needs work, but I can see there are ~50 searches a day on the forum for problems with Avogadro 1.2.
2 Likes
I’ve found another bug w.r.t the orbital window/rendering. Using the same file I linked earlier, if you click and drag on the orbitals quickly, Av2 just up and crashes. I’ve tried the rapid click and drag as opposed to just holding the arrow up key and both result in a crash. It seems to be something is up with rapidly requesting new renders, but I am not sure.
In an attempt to gain some more information, I monitored Av2 with the visual studio debugger while I did this, and got the following error message right before the crash:
Exception thrown at 0x00007FF8EC52FA4C in avogadro2.exe: Microsoft C++ exception: std::bad_array_new_length at memory location 0x0000004035FFF5F0.
Unhandled exception at 0x00007FF8ECC8F6FE (ucrtbase.dll) in avogadro2.exe: Fatal program exit requested.
The actual thing at the memory location it gave, 0x00007FF8ECC8F6FE, was this:
I’m not entirely sure if this helps at all, but I figured I’d try out some new things to maybe learn a bit more about how to debug better.
I’ve hit that once or twice. It seems like some sort of race condition (i.e., requesting a new render very quickly before the previous mesh is finished).
I think on Windows, to debug you need the debugging symbols. I don’t know the best way to handle that in Visual Studio, but maybe this is helpful? Configure CMake debugging sessions in Visual Studio | Microsoft Learn
The problem with this particular kind of bug is that debuggers often don’t provide much useful information.
Right now, the code sets up a queue for the cubes, and when you click on a particular orbital, it generates the meshes on-the-fly because it’s fast (with the new flying edges) and because the render type currently only handles up to 2 meshes per molecule.
So my guess is that the code is starting a mesh, then you request a new mesh before it’s finished. There should be a bit more “defensive” code in there (i.e., to detect a mesh is in progress before requesting the next one … and switching to a queue for mesh generation like for the cube code).
Yeah, those need to be generated during the build in the form of a bunch of .pdb files. That’s why I’ve been focused on getting the debug version to build lately. So far the only thing I can tell with the debugging mode that I’ve used is just what DLL file had the error, but without the .pdb files I couldn’t see what .cpp file it originated from.
I’ve noticed a lot lately that Av2 has some little bugs that result in just a forced exit, no error messages or anything, just crash. I don’t quite remember if it exists already, but is there a place that Av2 will dump information when it crashes?
That would be disappointing. This particular crash was my fault - basically not making the mesh creation lock / unlock properly. That’s called a race condition. Should be fixed now.
I’d be happy to start a separate thread if there’s a real need for a crash collection system. The current “best” option seems to be Chromium’s Crashpad library, which also needs a server repository to get the logs, and it presents privacy issues.
As a side note, I’ll see what I can do about a Debug version for Windows soon.
If you have a chance, I’d love to know if that pull request fixes your mesh crashing issues. Looks pretty solid to me in initial testing. 
It absolutely works, no crashes on that front! I think with that fix the molecular orbital window seems to be working quite well.
I think for the crash collection it doesn’t really need to be a log collection thing, but if I can take a look at any logs that get output on my own or provide them when a crash occurs that would be great.
I am very excited for this, should make bug hunting much easier on my end!
1 Like