TURBOMOLE Users Forum
TURBOMOLE Modules => Ricc2 => Topic started by: antti_karttunen on March 16, 2007, 12:21:21 PM
-
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)
-
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
-
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.