Ricc2 and reducible E representations

[antti_karttunen]

We are having some issues when trying to optimize the geometry of a S6-symmetric system with ricc2. Dscf calculates the SCF orbitals OK, but ricc2 crashes with the following message:

wrong number of saos specified in line :
 1  eg     eigenvalue=-.58445669265832D+02   nsaos=148

 ========================
  internal module stack:
 ------------------------
    ricc2
    cc_rspdrv
    cc_rspden
    cc_rirelden
 ========================

 faulty orbitals:$scfmo
 ri-cc2 ended abnormally

Looking at the mos file, the Ag and Au representations have 74 SAOs and Eg and Eu 148 SAOs.

Are there some some special requirements for point groups with reducible e representations? Ricc2 prints out message "e representations are reducible in this point group", but there are no further warnings. Lowering the point group symmetry would be one solution, but that would be bad for performance.

We also tested rimp2, but it went totally crazy, giving the following warnings and a non-sensical MP2 energy:

 WARNING
 Symm. of e-repr. not preserved in            1 cases
 Max deviation in the symm. blocks:   1.0986269671775517E-009
 WARNING
 Symm. of e-repr. not preserved in           44 cases
 Max deviation in the symm. blocks:   3.9119356642913772E-009
 WARNING
 Antisymm. of e-repr. not preserved in           23 cases
 Max deviation in the antis. blocks:   2.4438051582365006E-009


The calculations were run with version 5.9 (x86-64 binaries)

[christof.haettig]

Thanks for the info!

I could locate and solve the problem in ricc2. (Information about a fixed binary will hopefully follow soon...)

The bad news: It turned out that there is a problem with the orbitals for reducible E representations
written presently by dscf and riscf. As a consequence most post-HF programms will give wrong results
for point groups with such representations since TM V5.7...

Best regards,
Christof

[antti_karttunen]

It's nice to hear that the E-problem can be fixed!

We have not encountered the problem previously, as this was the first time we tried using post-HF modules for systems with reducible E representations. However, we have had similar situations with aoforce. Though it gives a clear warning about symmetries with reducible (complex) E-representations, it continues execution and the CPHF iterations never converge. Perhaps aoforce could just terminate on unimplemented symmetries and not continue using CPU time, as less experienced users might not notice the warning.