[CP2K-user] [CP2K:13372] Problem with geometry optimization using LS_SCF

Torstein Fjermestad tfjer... at gmail.com
Wed Jun 10 11:41:31 UTC 2020


Dear Fabian and Thomas,

Thanks a lot for your useful feedback.
I thought I should give you an update to clarify a confusion I might have 
caused.

When I said "normal" SCF, I meant orbital transformation (OT). Sorry for 
the sloppy terminology.

I completely confused myself (and probably also you) when I reported the 
wall time for a single point / geometry step.
When I look at the wall time per SCF iteration, the OT method is 
significantly faster than LS_SCF both for the CPU and GPU machine, see 
table below. 
I think the wall time per SCF iteration is a more relevant quantity to look 
at because for the OT method, the number of SCF iterations is reduced 
significantly when the start guess can be read from the previous geometry 
of a geometry optimization.

Entry

Total energy/ Ha

machine

nodes

tasks-per-node

tasks-per-socket

cpus-per-task

gpus-per-node

threads

wall time

# SCF steps

wall time/
SCF step

Method

purification method

EPS_SCF

dynamic threshold

1

-3499.007666

cpu - MPI 

3

36

-

-

-

-

309.3

8

38.7

LS_SCF

sign

1.0E-07

FALSE

2

-3499.00768

cpu - MPI 

3

36

-

-

-

-

380.0

86

4.4

OT

-

1.0E-06

-

3

-3499.00769

gpu -MPI/OMP

4

4

2

32

4

16

67.5

11

6.1

LS_SCF

trs4

1.0E-06

TRUE

4

-3499.00768

gpu -MPI/OMP

4

4

2

32

4

16

361.7

86

4.2

OT

-

1.0E-06

-

Entry 1 and 2 are the same calculations as shown in Test 1 at the start of 
this thread. 

Best regards,
Torstein


mandag 25. mai 2020 21.59.49 UTC+2 skrev tkuehne følgende:
>
> Dear Torstein, 
>
> beside the advice by Fabian to reduce the numerical noise within the 
> forces to improve 
> the convergence of the geometry optimization, set EXTRAPOLATION_ORDER to 3 
> for 
> consistency. Since the sign-method is an alternative to diagonalization, 
> which is at variance 
> to OT that is a direct minimization method (inspite the fact that the 
> minimization steps 
> are also called SCF iterations within CP2K!), the largest difference is 
> due to the rather 
> simplistic mixing. You may try to use DIIS acceleration (LS_DIIS T 
> together with appropriate 
> values for INI_DIIS & NMIXING) or BROYDEN_MIXING inside RHO_MIXING. 
>
> Cheers, 
> Thomas
>
> Am 25.05.2020 um 13:45 schrieb Torstein Fjermestad <tf... at gmail.com 
> <javascript:>>:
>
> Dear Thomas,
>
> Thanks for your fast reply.
> I did not restart the Hessian matrix in test 3.
> The LS_SCF section with all default made explicit, you can see here:
> The complete input file is attached.
> Thanks
>
> Regards,
> Torstein
>
>      &LS_SCF
>        LS_DIIS  F
>        INI_DIIS  2
>        MAX_DIIS  4
>        NMIXING  2
>        EPS_DIIS     1.0000000000000001E-01
>        MAX_SCF  20
>        EPS_SCF     9.9999999999999995E-08
>        MIXING_FRACTION     4.5000000000000001E-01
>        EPS_FILTER     9.9999999999999995E-08
>        EPS_LANCZOS     1.0000000000000000E-03
>        MAX_ITER_LANCZOS  128
>        MU    -1.0000000000000001E-01
>        FIXED_MU  F
>        EXTRAPOLATION_ORDER  4
>        S_PRECONDITIONER  ATOMIC
>        PURIFICATION_METHOD  SIGN_MATRIX
>        DYNAMIC_THRESHOLD  F
>        NON_MONOTONIC  T
>        MATRIX_CLUSTER_TYPE  ATOMIC
>        SINGLE_PRECISION_MATRICES  F
>        RESTART_WRITE  F
>        RESTART_READ  F
>        S_INVERSION  SIGN_SQRT
>        SIGN_SQRT_ORDER  3
>        REPORT_ALL_SPARSITIES  T
>        PERFORM_MU_SCAN  F
>        CHECK_S_INV  F
>      &END LS_SCF
>
>
> mandag 25. mai 2020 12.58.48 UTC+2 skrev tkuehne følgende:
>>
>> Dear Torstein, 
>>
>> apparently you are not exploiting the WF guess in your LS_SCF run, as you 
>> have guessed. 
>> Without an input I can only speculate, but by default EXTRAPOLATION_ORDER 
>> is 4 within 
>> LS_SCF and 3 for all other methods. Regarding test 3, did you also 
>> restart the Hessian matrix? 
>>
>> Cheers, 
>> Thomas
>>
>> Am 25.05.2020 um 12:34 schrieb Torstein Fjermestad <tf... at gmail.com>:
>>
>> Dear all, 
>>
>> First some background for my question:
>> I got computing hours on a cluster with GPUs. I did some tests with 
>> single point calculations, and I found that linear scaling SCF ran about 5 
>> times faster than "normal" SCF for my system on that cluster. The total 
>> energy between SCF and LS_SCF differed only by about 0.04 kJ mol-1; and I 
>> therefore found the results encouraging. 
>>
>> I then went on to compare LS_SCF and "normal" SCF for geometry 
>> optimizations on a machine without GPUs. I did three tests:
>> Test 1: Single point calculation
>> Test 2: Geometry optimization starting from the geometry in Test 1
>> Test 3: Geometry optimization starting from the optimized geometry in 
>> Test 2
>>
>> I used the following keywords in the LS_SCF section. 
>>
>> &LS_SCF
>>   EPS_FILTER 1.0E-7
>>   EPS_SCF    1.0E-7
>> &END
>>
>> At the beginning of the attached output files the complete input is 
>> echoed. 
>>
>> I now describe the results of the tests.
>>
>> Test 1: Single point calculation. The total energy differs by 0.05 kJ 
>> mol-1
>>
>> entry
>>
>> Total energy/ Ha
>>
>> wall time / s
>>
>> LS_SCF?
>>
>> 1
>>
>> -3499.00767
>>
>> 309
>>
>> yes
>>
>> 2
>>
>> -3499.00768
>>
>> 380
>>
>> no
>>
>>
>> Test 2: Geometry optimization starting from the geometry in Test 1. 
>> SCF_GUESS ATOMIC is used 
>>
>> entry
>>
>> Total energy, first geom / Ha
>>
>> max. grad of first step
>>
>> # geometry steps
>>
>> Total energy, optim geom / Ha
>>
>> wall time, s
>>
>> wall time / geom. step, s
>>
>> LS_SCF?
>>
>> 1
>>
>> -3499.00767
>>
>> 0.03493
>>
>> 54
>>
>> Did not converge within the requested wall time
>>
>> 7260 a
>>
>> 134
>>
>> yes
>>
>> 2
>>
>> -3499.00769
>>
>> 0.03613
>>
>> 123
>>
>> -3499.11153
>>
>> 4386
>>
>> 36
>>
>> no
>> a Requested wall time in submit script
>>
>> In Test 2, the wall time per geometry step is much longer when LS_SCF is 
>> used than when "normal" SCF is used. This is in spite of Test 1 showing 
>> that LS_SCF is notably faster for a single point calculation. 
>> Am I doing something wrong here?
>> Is the start guess of the wavefunction at each geometry step perhaps not 
>> adequate in the case of LS_SCF?
>> How should I change the LS_SCF parameters in order to improve the 
>> calculation?
>>
>> Test 3: Re-optimization of the optimized structure in Test 2 (entry 2). SCF_GUESS 
>> ATOMIC is used 
>>  
>>
>> entry
>>
>> Total energy, first geom / Ha
>>
>> max.grad of first step
>>
>> # geometry steps
>>
>> Total energy, optim geom / Ha
>>
>> wall time
>>
>> wall time / geom step
>>
>> LS_SCF?
>>
>> 1
>>
>> -3499.11150
>>
>> 0.00016
>>
>> 1
>>
>> -3499.11153
>>
>> 396
>>
>> 396
>>
>> no
>>
>> 2
>>
>> -3499.11147
>>
>> 0.00183
>>
>> 19
>>
>> Did not converge within the requested wall time
>>
>> 7260a
>>
>> 382
>>
>> yes
>> a Requested wall time in submit script
>>
>> Not unexpectedly, in Test 3,  the geometry optimization with "normal" SCF 
>> converges after 1 geometry step. 
>> However, the geometry optimization with LS_SCF did not converge within 
>> two hours and took only 19 geometry steps.
>> I see that the max. gradient of the first geometry step is much higher in 
>> the case of LS_SCF than in the case of "normal" SCF. 
>> Are there some LS_SCF parameters I should adjust to check if the gradient 
>> has converged?
>>
>> I would really appreciate help in this matter, because in the current 
>> situation, I am not able to use LS_SCF for geometry optimizations. 
>>
>> Thanks and regards,
>> Torstein Fjermestad
>>
>>   
>>
>>  
>>
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "cp2k" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to c... at googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/cp2k/432b51c8-1d61-491e-a235-cb81b77bd3a7%40googlegroups.com 
>> <https://groups.google.com/d/msgid/cp2k/432b51c8-1d61-491e-a235-cb81b77bd3a7%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> <cp2k-forum-May25-2020.zip>
>>
>>
>>
>>
>> ==============================
>> Thomas D. Kühne
>> Dynamics of Condensed Matter
>> Chair of Theoretical Chemistry
>> University of Paderborn
>> Warburger Str. 100
>> D-33098 Paderborn
>> Germany
>> td... at mail.upb.de
>> +49/(0)5251/60-5726
>>
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "cp2k" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to c... at googlegroups.com <javascript:>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/cp2k/b88518c9-cfe4-4e9e-a465-c97ecb552942%40googlegroups.com 
> <https://groups.google.com/d/msgid/cp2k/b88518c9-cfe4-4e9e-a465-c97ecb552942%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> <input-explicit.inp>
>
>
>
>
> ==============================
> Thomas D. Kühne
> Dynamics of Condensed Matter
> Chair of Theoretical Chemistry
> University of Paderborn
> Warburger Str. 100
> D-33098 Paderborn
> Germany
> td... at mail.upb.de <javascript:>
> +49/(0)5251/60-5726
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20200610/1e22b2e4/attachment.htm>


More information about the CP2K-user mailing list