[Q-e-developers] minimizzazione inefficiente

[Nicola Manini]

At Paolo's request, I attach the input file of a typical example of 
problematic damp minimization.  The computation takes 4h30 on 12 cores (Xeon 
E5520 2.27GHz) but there is no need to wait for the end: the oscillation is 
clear after few iterations.

Here follows the output of 2 grep's on the output file (full file available 
upon request):

grep Tota c12-h2_side_d20.out
      Total force =     0.000020     Total SCF correction =     0.000004
      Total force =     0.000015     Total SCF correction =     0.000002
      Total force =     0.000018     Total SCF correction =     0.000002
      Total force =     0.000032     Total SCF correction =     0.000005
      Total force =     0.000032     Total SCF correction =     0.000005
      Total force =     0.000033     Total SCF correction =     0.000004
      Total force =     0.000033     Total SCF correction =     0.000006
      Total force =     0.000036     Total SCF correction =     0.000007
      Total force =     0.000039     Total SCF correction =     0.000003
      Total force =     0.000042     Total SCF correction =     0.000004
      Total force =     0.000046     Total SCF correction =     0.000002
      Total force =     0.000049     Total SCF correction =     0.000003
      Total force =     0.000052     Total SCF correction =     0.000002
      Total force =     0.000056     Total SCF correction =     0.000001
      Total force =     0.000060     Total SCF correction =     0.000001
      Total force =     0.000065     Total SCF correction =     0.000001
....

grep "atom   5 type  1   force =" c12-h2_side_d20.out
      atom   5 type  1   force =     0.00000320    0.00000000    0.00000367
      atom   5 type  1   force =     0.00000276    0.00000000   -0.00000047
      atom   5 type  1   force =     0.00000265    0.00000000    0.00000107
      atom   5 type  1   force =     0.00000198    0.00000000   -0.00000342
      atom   5 type  1   force =     0.00000232    0.00000000    0.00000120
      atom   5 type  1   force =     0.00000214    0.00000000    0.00000028
      atom   5 type  1   force =     0.00000179    0.00000000   -0.00000173
      atom   5 type  1   force =     0.00000204    0.00000000    0.00000170
      atom   5 type  1   force =     0.00000159    0.00000000   -0.00000182
      atom   5 type  1   force =     0.00000181    0.00000000    0.00000128
      atom   5 type  1   force =     0.00000137    0.00000000   -0.00000192
      atom   5 type  1   force =     0.00000165    0.00000000    0.00000179
      atom   5 type  1   force =     0.00000112    0.00000000   -0.00000258
      atom   5 type  1   force =     0.00000155    0.00000000    0.00000229
      atom   5 type  1   force =     0.00000086    0.00000000   -0.00000335
      atom   5 type  1   force =     0.00000148    0.00000000    0.00000340
....


I add a few comments in Italian to Paolo's message below.
All the best,
		Nick


On 05/09/2011 01:11 PM, Paolo Giannozzi wrote:
> Ciao
>
>> Per la cronaca, l'algoritmo rilassesco damp ha strane instabilita` quando
>> arriva vicino al minimo: come niente comincia ad oscillare con ampiezza
>> sempre maggiore facendo crescere l'energia totale.
>
> interessante. La dinamica dampata "normale", quella con un damping
> parameter, non puo' far altro che dampare: caso mai dampa troppo poco.

A meno che il time step sia troppo grosso.

> Non so bene (ne' lo sa nessun altro, temo) come funziona la dinamica
> dampata che c'e' nel QE. A me e' sempre sembrata una cosa di dubbia
> utilita', anche se ha i suoi tifosi. Se hai un caso che non prende
> secoli potresti per favore fare un bug report su qe-forge?

Se bfgs andasse meglio non ci sarebbe ragione di usare damp, ma tipicamente 
bfgs vicino al minimo comincia a vagare a casaccio, facendo salire l'energia, 
e uscendo con errore.  damp almeno continua a provarci, e se magari 
localmente fa aumentare l'energia, dopo parecchie iterazioni si redime e 
ri-inizia a calare (anche nell'esempio allegato).

>> Pure il bfgs non e` che brilli vicino al minimo. Non sarebbe possibile/furbo
>> quando l'energia si abbassa di poco switchare automaticamente a un conjugated
>> gradient, che se il gradiente non e` troppo sballato in 3 o 4 iterazioni piove
>> sul minimo?
>
> bisogna vedere se il motivo per cui il bfgs va a farfalle non e'
> proprio il gradiente in cui il rumore e' maggiore del segnale.

Gia`.

> Anni fa c'era la possibilita' di ottimizzare le posizioni con
> il conjugate gradient, ma non sembrava migliore del bfgs, anzi.
> Bisognerebbe provare, con qualche caso rognoso sottomano. Una
> delle difficolta' nel cercare di migliorare l'attuale algoritmo
> e' che ci vorrebbero un po' di casi difficili ma che non richiedano
> decine di ore per girare. Un'altra difficolta' e' che la parte di
> ottimizzazione ionica e' scritta in un modo piuttosto cervellotico
> che rende difficile metterci le mani. L'ultima difficolta' e' che
> di gente che si lamenta del bfgs ce n'e' tanta, ma di gente che si
> mette li' a migliorarlo, o anche solo a proporre qualche idea come
> la tua, ce n'e' molta meno! Grazie, ciao

Posso collaborare su questa cosa.  Penso di riuscire a fabbricare anche 
esempi rognosi con meno atomi&elettroni, da fare girare quasi al volo.
In effetti ho guardato il codice, e ci si capisce abbastanza poco.
Non e` evidente dove viene deciso il time step della dinamica ne` il 
parametro di damping (immagino che cercando abbastanza a lungo alla fine li 
troverei...).  La cosa piu` imbarazzante e` che non sono riuscito a trovare 
sulla rete una descrizione precisa del "preconditioned-projected-Verlet 
algorithm". Boh?  ;-)

Grazie!
		Nick
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: c12-h2_side_d20.in
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20110509/c9d14ac1/attachment.ksh>