with the newest Avogadro 2, OpenBabel and xtb plugin on my Windows11 notebook I compute orbitals, but they do not show up in the “Molecular Orbitals” window. The MO window is empty - see the printscreen. Please help.
PS: I get the message about xtb calculated oribtals; likewise in the log.log file I see :
"main_:75: The following dictionary was passed back to Avogadro: {‘readProperties’: True, ‘moleculeFormat’: ‘molden’, ‘molden’: '[Molden Format]\n[Title]\n[Atoms] AU\nC 1 "
I’ll reply more thoroughly to you shortly, but to begin with you can look in the calculation directory (in the plugin’s submenu) and open the molden.input file manually with Avogadro. That should give you the results, at least.
I see the molden.input file in the deep xtb calculation subdirectory. But Avogadro 1.100 can not open this file (I am under Windows, and have no molden program )…
You can just click on other lines in the table. It will pre-compute +/- 5 around the HOMO/LUMO gap, but it doesn’t take long to click on another one and have it render.
The issue there is that xtb doesn’t print the full set of MOs, and Avogadro currently doesn’t really expect that the set of MOs will be incomplete.
I need to change the plugin slightly so that the MO indices are passed back to Avogadro, but I’m not sure whether that will entirely fix the issue.
Besides which, the interface between Avogadro and the plugin is clearly not working at the moment anyway, since the orbitals weren’t being loaded for you. Can you please reproduce the original issue (no MOs being displayed after running an orbital calc with the plugin) and send the log file, input file, and the various output files from the calculation folder? (As an archive e.g. .zip). Then I can take a look. Thanks!
I think the main thing is that parts of Avogadro assume electrons / 2 → HOMO, and there needs to be more code that sets the HOMO or orbital occupations. The latter is probably the better option to also handle other kinds of calculations.
you can reproduce this issue with any small molecule.
For instance CH3Cl, optimize it using FF, and then calculate orbitals using xtB-as-plugin. Open the calculation files, rename molden.input to file.molden and open this file in Avogadro2.
In molden.input file there are all xtb calculated orbitals. But Avogadro2 does not properly counts the MOs, it wrongly assignes HOMO-x numbering…
Having a look at it briefly, what happens for me is the same as you, that I run the orbitals calculation, and the MO dialog then opens but is empty, so I can confirm the bug.
However, if I then switch to another molecule in the Molecules Pane and back again, the dialog is then populated. So the information is being passed back correctly, there’s just something weird going on on the Avogadro side.
I know that’s a bit inconvenient, but at least that’s a bit of a work-around so you can see the orbitals without having to load the file manually.
I’ll also note @ghutchis that some MOs seem to render the same even when they ought to be different (and are verifiably different by checking the file).
Yeah – looking at the files, the orbital numbering does actually match up with the scheme that xtb uses (i.e. even though it only looks at the valence orbitals, it just ignores the core orbitals for the purpose of the numbering).
So it’s the occupations that are needed really.
The occupancies are actually included in the .molden file, but unfortunately Avogadro doesn’t currently parse them.
Edit: I also just had a go at having the plugin pass the occupations back to Avogadro within the output JSON e.g. example.json.txt (11.5 KB) and it doesn’t seem like the occupations are registered, as if I run an orbitals calculation and then save to CJSON the occupation data doesn’t appear. So it’s not a simple fix that can be done from the plugin.
Avogadro of course has to act appropriately for the given occupations, but getting the occupation data into Avogadro is a pre-requisite for that. The easiest way to get that to happen for now will be to add support for parsing occupation data from .molden files. I guess that’s not a huge undertaking and something that I can look at.
Coming back to this … is it a problem with the MO window? In other words, if you use “Create Surfaces” does it show the same issue?
While in principle, the occupations are tracked, in practice the code for handling basis sets does not do a great job with that - I noticed as I was working on the MO window itself. (e.g., it assumes it can get the HOMO number as electrons / 2 which is problematic).
Yes, parsing occupation from molden would be great.