[CPMD-list] slow convergence with ODIIS

Axel Kohlmeyer axel.kohlmeyer at theochem.ruhr-uni-bochum.de
Wed Apr 14 16:25:03 CEST 2004


>>> "CT" == Christian Tuma <ct at chemie.hu-berlin.de> writes:

hello christian, veronique, and everybody else on cpmd-list,

please note, that the following statements are entirely my personal 
observations and that my insight in the cpmd sourcecode was limited
to 'how do i get this beast to compile and work properly on machine 
X, Y and Z' until about a year ago. so my knowledge on the historical
design decisions and motivations is based on looking at source code, 
cvs logs and hearsay. so take my views with a big grain of salt.

as far as i can tell, apart from adding support for the new file format,
there have not been many changes in the uspp part of the cpmd code over
the last years. in fact, last december i stumbled on a (rarely used)
part that had not been converted to the 'NEWCODE' scheme.

somehow you have to 'pay' for the luxury of being able to use such a 
small cutoff, thus the implementation is much more complicated. at 
least this is the impression i got from looking at the code.
it seems to me, that it is _much_ less painful to get additional cpu 
time (and i already consider writing applications for computer resources
a rather painful process) and continue using normconserving PPs and do 
all the nice stuff you can do with them. while in case of improving 
the uspp support, you would have to spend a lot of time only to get,
where you already are (ok, you could do larger systems, or more 
calculations) with the normconserving PPs. due to the fact how 
science has mutated into a highly competitive business, i can 
fully understand that choice.

the situation will not change much, until somebody steps
forward and improves/extends/fixes the uspp related stuff in cpmd.
the upcoming cpmd version 3.9 will hopefully be more reliable (not only) 
for uspps, as i recently spend some time on, at least, adding warnings or
error exits into those parts of the cpmd code that obviously do not
support uspps or look suspicious. some of the fixes were embarrassingly
simple, btw. time contraints and my own, (still) insufficient
knowledge about the underlying physics regrettably prohibit me to go
beyond that. which really is a pity, since you can already do many nice
calculations with uspps. i particularly like the fact, that you can use
them to demonstrate 'chemistry in motion' to students with just a 
simple linux pc.

but after all, you _have_ access to the source code, so don't be afraid
to look into it. even documenting useful workarounds or providing simple
examples to demonstrate more typical applications of cpmd (to add to the
cpmd testsuite) would be helpful. again you'll see that the manual
for cpmd v3.9 will already contain edited versions of many of the 
suggestions, fixes that were discussed on this list. a job that did
not need much more than some basic knowledge on how to run cpmd (to
check the suggestions) and a bit of common sense.

until then i can only suggest to carefully double-check your results
and be highly suspicious if things don't run smoothly. 

[...]

CT> However, testing several values for TIMESTEP is no guarantee to find the
CT> "correct" wavefunction and so the convergence problem still persists.
CT> Axel, you suggested to put some initial ATOMIC CHARGES. I would like
CT> to try this and to see whether this improves the situation, but, I
CT> have no clear idea which values to choose. When doing a properties

i found that (partial) charges from force field parameters
or results of a NBO calculation worked well for me. but this was
only for water and small (mostly organic) molecules.

CT> calculation for atomic charges I get a set of charges derived from
CT> real space integration and another one from the electrostatic potential,
CT> the absolute values from the latter being about one order of magnitude bigger
CT> than the ones from real space integration. Which of these two sets should I
CT> use as an orientation for the ATOMIC CHARGES to follow your suggestion?

since you need a (tightly) converged wavefunction to do that calculation,
this would result in a nice catch-22. ;-)
but mainly you have to try-and-err. please also note, that there is a 
(non-fatal) bug in the initial guess subroutine of cpmd v3.7.x that 
can make the intial guess worse in certain cases, even if you use 
the 'correct' ATOMIC CHARGES.

CT> Does anybody have another new idea how to make life easier when trying
CT> to converge the wavefunction using Vanderbilt-PPs?

in one case i got the fastest uspp convergence, by starting from a 
wavefunction that was (partially) converged with normconserving PPs.

hope you don't mind my ramblings (i really needed to get that out)
and good luck,
    axel.


CT> cheers,
CT> Christian.

CT> PS: I agree to Atte, PBE calculations seem to converge easier than e.g.
CT> BP86 calculations, at least when using normconserving PPs.

CT> -- 
CT> Christian Tuma             Humboldt-Universitaet Berlin
CT> ct at chemie.hu-berlin.de     Arbeitsgruppe Quantenchemie (Prof. Sauer)
CT> phone: +49-30-20937140     Brook-Taylor-Str. 2, 12489 Berlin, GERMANY
CT> fax:   +49-30-20937136     http://www.chemie.hu-berlin.de/ag_sauer
CT> _______________________________________________
CT> CPMD-list mailing list
CT> CPMD-list at cpmd.org
CT> http://www.cpmd.org/mailman/listinfo/cpmd-list



--

=======================================================================
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.



More information about the CPMD-list mailing list