[CPMD-list] serial and parallel gradients differ

[Axel Kohlmeyer]

On Sat, 26 Mar 2005, Robert Williams wrote:


hi bob,

RW> Dear CPMDers,

[...]
RW> Serial   3.9.1:
RW>   *** TOTAL STEP NR.  9999           GEOMETRY STEP NR.   2284  ***
RW>   *** GNMAX=  1.182878E-03 [5.35E-05]     ETOT=   -189.032981  ***
RW>   *** GNORM=  2.870398E-04               DETOT=     1.005E-09  ***
RW>   *** CNSTR=  0.000000E+00                TCPU=         80.58  ***

hmmmm. TOTAL STEP NR looks suspicious. if you have not changed the
defaults, that your optimization is _not_ converged!
it just stopped at the 10000th step (MAXSTEPS is 10000 by default).

RW> ...
RW>   =              END OF GEOMETRY OPTIMIZATION                    =
RW>   *                        FINAL RESULTS                         *
RW> ...
RW>     ATOM          COORDINATES            GRADIENTS (-FORCES)
RW>     1  O  5.1224  2.8573  3.3944   0.000E+00  0.000E+00  0.000E+00
RW>     2  O  4.1231  8.7555 10.3710   0.000E+00  0.000E+00  0.000E+00
RW>     3  O 14.3880  2.7858  3.3105   0.000E+00  0.000E+00  0.000E+00
RW>     4  O 13.4023  8.7048 10.1629   0.000E+00  0.000E+00  0.000E+00
RW> ..................................................................

since the optimization has not converged (it probably stopped
in the middle of the wavefunction optimization) the forces 
have not been calculated and are thusly still zero. older versions
of cpmd did always compute the forces at the end of a job,
leading to a large amount of wasted cpu time. so this was changed
seems like you just found a case, where the output does not
detect, that there are now forces to print.

RW> Parallel 3.9.1:
RW>   *** TOTAL STEP NR.  6604           GEOMETRY STEP NR.   1400  ***
RW>   *** GNMAX=  1.825868E-03 [8.65E-09]     ETOT=   -189.032988  ***
RW>   *** GNORM=  4.655294E-04               DETOT=    -2.749E-10  ***
RW>   *** CNSTR=  0.000000E+00                TCPU=         18.64  ***
RW> ...
RW>   =              END OF GEOMETRY OPTIMIZATION                    =
RW>   *                        FINAL RESULTS                         *
RW> ...
RW>     ATOM          COORDINATES            GRADIENTS (-FORCES)
RW>     1  O  5.1271  2.8813  3.4124  -7.567E-04  9.170E-05 -4.731E-04
RW>     2  O  4.1229  8.6424 10.2943   6.352E-04 -9.080E-06  1.336E-04
RW>     3  O 14.4179  2.8784  3.3640   1.826E-03 -1.309E-04  3.528E-04
RW>     4  O 13.3743  8.6440 10.2220  -1.175E-03 -2.027E-04  2.011E-04
RW> ..................................................................

looks normal. in my experience this is about the convergence 
wrt. individual forces you can get.

since you need a lot of steps, i'd like to suggest some
additional entries in your input, that may help to speed
up your optimizations a little.

  ODIIS NO_RESET=30
    5
  LBFGS NREM
    20
  PRINT LSCAL ON

to explain: the default DIIS vector is good for well-behaving
systems, but reducing that cuts down memory use and can speed
up convergence. in some cases i found that a DIIS vector of 7
is even better. YMMV. NO_RESET=30 will have a DIIS reset
only after 30 steps. the default is to reset after the length
of the DIIS vector. this is usually too early for ODIIS 10
but surely for smaller vectors.

in my experience, the linear scaling optimizer 
(LBFGS) is much better suited for bulk systems
(in fact it seems better for most cases).

best regards,
	axel.

RW> 
RW> 
RW> Bob
RW> 
RW> 

-- 

=======================================================================
Dr. Axel Kohlmeyer   e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de
Lehrstuhl fuer Theoretische Chemie          Phone: ++49 (0)234/32-26673
Ruhr-Universitaet Bochum - NC 03/53         Fax:   ++49 (0)234/32-14045
D-44780 Bochum  http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.