GaussianSet and contraction coefficients

Hi!

I have a GAMESS output file which kills Avogadro when loading MOs:

push back 0.013014
add MOs: 50 1052
*** glibc detected *** /usr/bin/avogadro: malloc(): memory corruption:
0x0000000002bec940 ***
When calling new in OpenQube::GAMESSUSOutput::load at
libavogadro/src/extensions/surfaces/openqube/gamessus.cpp:257

So I’m reading trough the code trying to understand where is the issue.
The relevant files seem to be gamessus.{h,cpp} and gaussianset.{h,cpp}.
I haven’t gone trough all of it yet, but the first thing I noticed in
gaussianset.h is this:

  • The GaussianSet class has a transparent data structure for storing the basis
  • sets output by many quantum mechanical codes. It has a certain hierarchy
  • where shells are built up from n primitives, in this case Gaussian Type
  • Orbitals (GTOs). Each shell has a type (S, P, D, F, etc) and is composed of
  • one or more GTOs. Each GTO has a contraction coefficient, c, and an exponent,
  • a.

It says that there is one exponent and one contraction coefficient for
each GTO and the code seems to also treating it like that, but my output
file has two contraction coefficients for L type shells (it should be
6-31G** basis set):

SHELL TYPE PRIMITIVE EXPONENT CONTRACTION COEFFICIENT(S)

O

  1   S       1          5484.6716600    0.001831074430
  1   S       2           825.2349460    0.013950172200
  1   S       3           188.0469580    0.068445078098
  1   S       4            52.9645000    0.232714335992
  1   S       5            16.8975704    0.470192897984
  1   S       6             5.7996353    0.358520852987

  2   L       7            15.5396162   -0.110777549525    0.070874268231
  2   L       8             3.5999336   -0.148026262701    0.339752839147
  2   L       9             1.0137618    1.130767015354    0.727158577316

  3   L      10             0.2700058    1.000000000000    1.000000000000

  4   D      11             0.8000000    1.000000000000

Did I read it correctly and it is a bug in Avogadro or am I missing
something? There are other things which might trow off the parser (it is
output from FMO calculation), but I want to have this clarified first.

Reinis