Fix catastrophic bugs reading Orca orbitals.

[md-5]

Prior to this commit, the parser would randomly set orbital coefficients to zero for any coefficients with 3 or more characters prior to the decimal point and then silently error out for other coefficients in the affected lines.

Surprisingly this was not commonly noticeable in visualisations of several hundred orbitals, but was picked up in CAM-B3LYP calculations of ethene and WB97X calculations on butadiene.

The code is still a mess, but at least should be more robust against parsing such input files. It will be further tested in my work over the coming week or so.

Open shell orbital visualisations (copy pasted code) have not been updated as I don't have any such systems to test, and it doesn't appear to be well supported in the first place.

[md-5]

Orbital before this fix

Orbital after this fix

[ghutchis]

Thanks, a quick look is promising. Does the same problem exist in http://github.com/openchemistry/avogadrolibs as well? (Probably yes.)

[md-5]

I don’t believe orca is supported natively in avogadro 2, so no.

I will have to compile avogadro 2 to make sure some day ;)

[md-5]

Yeah so avogadro 2 doesn't read orbitals from .orca files, and produces garbage orbitals when reading from orca->molden converted files, so this bug doesn't directly occur there.

Cheers

[ghutchis]

@md-5 - not sure if "cheers" is the right term. 😦

Thanks for the heads-up, I'll see if we can port your now-fixed Orca code to Avo2.

Not sure about molden, but my group is using Orca a lot now, so I'll check out molden and mkl support in the next few weeks.

[md-5]

No problem,

Re: Molden it was just me using the orca_2mkl tool (https://sites.google.com/site/orcainputlibrary/printing-and-visualization) to get the output in a different format, in case Avogadro(2) supported that better. I don't actually use it myself.

Parsing all these text files is indeed incredibly annoying. The Orca people have released some vague information about the binary .gbw file format (https://orcaforum.cec.mpg.de/viewtopic.php?f=8&t=3299&start=20) which is enough to get out the geometry and orbital coefficients (and with a little more work I'm sure the basis set information too). Could be an alternative approach in the future - certainly more robust.

I'll also leave the affected ethene text output on this PR in case its useful:
cam-b3lyp.txt

[ghutchis]

As it turns out, the orca_2mkl can be used to generate MKL but also to regenerate GBW files, so I was going to start with that. Since some Orca folks contributed the Avo1 code, I'm hopeful we can get some help with GBW eventually too.

(As it turns out, gzip or bzip2 on mkl files produce smaller results than GBW itself.)

Anyway, I'll review your changes here and then see about porting them. Thanks.