Was the handling of g orbitals added in 1.100? When I try to open a molden file for a molecule / basis with up to g orbitals, the orbitals presumably render (per the MO table) but they dont show in the screen. Nor do I get an error of some sort.
ppoThere’s some support, but I didn’t have a lot to test it with.
I suspect the bigger question is on the normalization. So it’s possible that the orbitals are “there” but not scaled correctly.
This week is busy for me, but I’ll definitely take a look.
Good afternoon Geoff,
Did you, by chance, take a look at this? Alternatively - is there some way to chose the normalization / scale them orbitals manually within Avogadro?
I haven’t - thanks for the reminder. I’ll check with a colleague soon to check on the g normalizations.
Okay, I remember that I did run a large-basis calculation with \ce{CO2} when I implemented the ‘g’ functions and it looked okay.
I spent more time re-analyzing your file tonight. It shows orbitals in some cases, but something is very wrong with the parsing.
Avogadro thinks there should be 154 orbitals, but Molden only gives 128 energies?!
Some of the orbitals look okay, but some of them .. are decidedly wrong.
What program did you use for this? Did it somehow output spherical basis functions? (In principle, in Molden you should output [5d] [7f] [9g] for that .. which I think would add up to 128 orbitals?
DyO2.out (76.6 KB)
Geoff, I used CFour for the calculation and the output file indeed gives me 128 orbitals. And per the manual, it does use spherical basis functions. Will try to repeat the calculation with Cartesians and see what happens.
It is not the first time I have CFour format molden files strangely… The vibrational frequencies of linear triatomics come all scrambled up .
I don’t think it’s just the spherical basis functions. I think there’s also something a bit weird with the ordering. I hacked the import code to assume spherical, and it still didn’t look quite right.
There’s a specific order to the angular momenta, and I’m guessing there’s something off about it.
I ran a few more ‘g’ runs with ORCA and everything looks okay (and ORCA defaults to spherical basis functions).
Certainly happy to help work through this with you.
I tried to replicate the calculation with Orca. The energy is off by a few mHa but I think it’s basically the same result. It also has 128 MOs. And I also cannot visualize the few orbitals I tried (either with the Orca one or the CFour molden files). What orbital are you visualizing up there?
DyO2_Orca.mol (426.4 KB)
DyO2_Orca.out (86.2 KB)
This ORCA file doesn’t have the MO or basis printed:
%output
print[p_mos] 1
print[p_basis] 2
end
But with the molden file you sent, here’s the HOMO:
And the LUMO:
The initial resolution (medium) wasn’t great) so I picked “High” and re-rendered.
BTW, as ‘.mol’ it will get rejected since it tries to read it as a MDL molfile but I changed the extension to DyO2.molden
Interesting… for me, I click and nothing shows!
Also, I had to change it to .mol because the website does not allow me to upload .molden files. It would be convenient if we could.
And I dont mind at all! It’s a beautiful picture.
You don’t have “Surfaces” checked in the display types. I’ll go see why that’s not getting enabled automatically.
And I’ll go add .molden to the allowed types. 
Oh silly me, thank you. What orbital number exactly are you plotting? My HOMO (40) definitely does not look like that. Mine has pi symmetry instead of sigma. What isovalues are you using? Is there a way to change the default isovalue of the MO table?
At the moment, no. It uses 0.03. I’ll bring back the configuration dialog after this release.
I was using HOMO = orbital 40, but I’m using 1.103 / continuous release. IIRC there were some bugs fixed in Molden parsing when I added support for open-shell species.
(I also have about a 30-40% speedup in orbital rendering.)
The current continuous release is essentially 1.103, or you can wait until tomorrow for the official release binary.
It works with the 1.103 for me now, thank you!
