dynpol: "RPA metric is ill-conditioned" when taking multiple frequencies

Started by drew, October 20, 2008, 06:51:58 AM

Previous topic - Next topic

drew

Using escf I am trying to calculate dynamic polarisabilities, setting frequencies with $scfinstab dynpol.

I find if I try to do "too many" frequencies at once, then the calculation crashes with, for instance (for chloride):
..........................................................................................
Iteration IRREP Converged      Max. Euclidean
                 roots          residual norm


         0 2 e - integrals written in         0 blocks requiring       0 k-byte

    1       a       17        1.007987072749249D-02

Warning! RPA metric is ill-conditioned: cond =  1.618844632179714E+016
    2       a       20        1.639881319565660D-03


MODTRACE: no modules on stack

singular metric in <ritz2>
escf ended abnormally
..........................................................................................

If I reduce the calculation down to say 1 frequency, then the calculation succeeds.  In some cases I can successfully push through 15 frequencies, in other cases (for the same system) even 10 frequencies crashes.  There's no obvious pattern explaining the crash.

I'm not sure that it's related to the amount of memory available.  Increasing $rpacor or $maxcor makes no difference, and the turbomole is not even using that (uses only 35MB of the 500MB I gave it).

Is there any sensible fix or input parameter for handling many dynpol frequencies at once or are single frequency calculations the only way to work around the problem?

Thanks,
Drew


christof.haettig

This looks more like a problem with (near) linear dependencies between trial vectors in the solution of the CPHF equations.
You should send this problem to the TM helpdesk (COSMOLogic).

Christof

Stephan

I encountered the same problem.
It seems to help to just converge the calculation with a lower number of frequencies
and then increase the number after convergence is reached and redo the calculation.
(That is, if you can afford multiple calculations...)

Regards,
Stephan