On Fri Feb 24 '12 2:26pm, Mikhail wrote
>Dear Dr Granovsky,
>your explanation is quite surprising, because when I began these calculations I obtained sometimes the massages about "unsufficient memory", and as you can see from $SYSTEM group in my input I increased memory reqirement up to the level, where such message not appeared.
>So, the printout about memory problem certanly exists in the code, but it doesn't work in some cases, where the memory is really unsufficient?
Yes it does not work with Firefly v. 7.1.G (and below) in the case of 32-bit integer math overflow. This was fixed in version 8.0.0
>>Do you really need such a large active space? I'd suggest to cut
>>significantly it until it fits, then perform CASSCF followed by XMCQDPT2 calculations.
>The decrease of active space can be done in two ways:
>1) To remove the 7s orbitals from active space to core and corresponding decrease of electron number: NCORE=10 NELS=4 NACT=30 (the former NCORE=8 NELS=8 NACT=32). This works, but the approach is unphysical.
>2) To decrease the number of active orbitals, I am not sure that decrease of NACT from 32 to 26 means the exclusion of six 7p orbitals from the calculation, but the job stops in a way simlar to NACT=32. I am also not sure, that NACT=12 means the additional exclusion of fourteen 5f orbitals, however, this input works, but the approach is unphysical.
>Thus, all possible ways to cut the active space are unacceptable. Can the GUGA approach be more useful?
How to cut this extra-large active space really depends on the type of states you want to describe as a result of CASSCF or XMCQDPT2 calculations.
Normally, one can take into account low-population orbitals perturbatively while keeping in the active space only the most populated orbitals.