[CP2K:10305] Re: MO coefficients not normalized?

Dan_M danielm... at gmail.com
Fri May 11 17:01:22 UTC 2018


Hi Matt and Matthias,

I checked again how it is restarting and everything seems OK except for one 
small detail that I noticed before: at the end of the OT run that converges 
fine I asked for the eigenvalues/vectors and get this:

 MO EIGENVALUES, MO OCCUPATION NUMBERS, AND SPHERICAL MO EIGENVECTORS

                              1            2            3            4
                           0.000000     0.000000     0.000000     0.000000

                           2.000000     2.000000     2.000000     2.000000

     1     1  H  1s        0.041792    -0.021819     0.017069     0.034694
     2     1  H  2s       -0.001649     0.001658    -0.000426    -0.000597
     3     1  H  3s       -0.011486     0.007381    -0.005083    -0.008958
     4     1  H  4s       -0.006041     0.006679    -0.005789    -0.009582
....

So apparently the eigenvectors are fine but the eigenvalues are missing. 
This is strange because I also requested the PDOS and the eigenvalues there 
seem fine (they are not zero). If I convert to ascii the *-RESTART.wfn file 
that it is saved at the end of the run, I see that indeed the eigenvectors 
are the same I see in the plain text output but the eigenvalues are not 
properly stored (all are 0.00000). Of course, if I look at the restarted 
calculation where I try the diagonalization and I ask to see the eigenv. at 
the very beginning I get:

 MO EIGENVALUES, MO OCCUPATION NUMBERS, AND SPHERICAL MO EIGENVECTORS AFTER 
SCF STEP -1

                              1            2            3            4
                           0.000000     0.000000     0.000000     0.000000

                           2.000000     2.000000     2.000000     2.000000

     1     1  H  1s        0.041792    -0.021819     0.017069     0.034694
     2     1  H  2s       -0.001649     0.001658    -0.000426    -0.000597
     3     1  H  3s       -0.011486     0.007381    -0.005083    -0.008958
     4     1  H  4s       -0.006041     0.006679    -0.005789    -0.009582
...

I am wondering: is it possible that the problem are all these eigenvalues 
that are 0 ? Maybe the actual problem is that the OT run is not properly 
recording the wfn?

Thanks a lot
Daniel


El viernes, 11 de mayo de 2018, 18:34:52 (UTC+2), Matthias Krack escribió:
>
> Hi Daniel
>
>  
>
> I am afraid that you will have to provide your full input and output (OT 
> run and DIAG restart), if you want to get further hints from the forum.
>
> Matthias
>
>  
>
> *From:* cp... at googlegroups.com <javascript:> [mailto:
> cp... at googlegroups.com <javascript:>] *On Behalf Of *Matt W
> *Sent:* 11 May 2018 18:25
> *To:* cp2k
> *Subject:* Re: [CP2K:10305] Re: MO coefficients not normalized?
>
>  
>
> Are you sure it is restarting correctly? Do you have, for instance, a name 
> of a restart file that does not exist?
>
>  
>
> Matt
>
>  
>
>
>
> On Friday, May 11, 2018 at 4:43:08 PM UTC+1, Dan_M wrote:
>
>
> I just checked with DZVP-MOLOPT-SR and I get the same bahaviour (as 
> before, previously converged without any issue with OT at EPS_SCF 1.0E-8):
>
>   Step     Update method      Time    Convergence         Total energy    
> Change
>   
> ------------------------------------------------------------------------------
>      1 P_Mix/Diag. 0.10E+00    1.9     1.01887548     -2483.2801991206 
> -2.48E+03
>      2 P_Mix/Diag. 0.10E+00    2.2     0.17795477     -2483.2664599411  
> 1.37E-02
>      3 P_Mix/Diag. 0.10E+00    2.2     0.15515820     -2483.2705252108 
> -4.07E-03
>      4 P_Mix/Diag. 0.10E+00    2.2     0.13461919     -2483.2732304534 
> -2.71E-03
>      5 P_Mix/Diag. 0.10E+00    2.2     0.11636509     -2483.2750698192 
> -1.84E-03
>      6 P_Mix/Diag. 0.10E+00    2.2     0.10030721     -2483.2763421133 
> -1.27E-03
>      7 P_Mix/Diag. 0.10E+00    2.2     0.08629078     -2483.2772336240 
> -8.92E-04
>      8 P_Mix/Diag. 0.10E+00    3.3     0.07412833     -2483.2778639847 
> -6.30E-04
>      9 P_Mix/Diag. 0.10E+00    2.2     0.06362153     -2483.2783121408 
> -4.48E-04
>     10 P_Mix/Diag. 0.10E+00    2.2     0.05457503     -2483.2786314448 
> -3.19E-04
>     11 P_Mix/Diag. 0.10E+00    2.2     0.04680461     -2483.2788586871 
> -2.27E-04
>     12 P_Mix/Diag. 0.10E+00    2.2     1.01928993     -2483.2790196613 
> -1.61E-04
>     13 P_Mix/Diag. 0.10E+00    2.2     0.17939488     -2483.2653152844  
> 1.37E-02
>     14 P_Mix/Diag. 0.10E+00    2.2     0.15625219     -2483.2694676081 
> -4.15E-03
>     15 P_Mix/Diag. 0.10E+00    2.2     0.13547789     -2483.2722671414 
> -2.80E-03
>     16 P_Mix/Diag. 0.10E+00    2.2     0.11706181     -2483.2741996740 
> -1.93E-03
>     17 P_Mix/Diag. 0.10E+00    2.2     0.10089024     -2483.2755600100 
> -1.36E-03
>     18 P_Mix/Diag. 0.10E+00    2.2     0.08679173     -2483.2765326974 
> -9.73E-04
>     19 P_Mix/Diag. 0.10E+00    2.2     0.07456783     -2483.2772368267 
> -7.04E-04
>     20 P_Mix/Diag. 0.10E+00    2.2     0.06401302     -2483.2777514316 
> -5.15E-04
>     21 P_Mix/Diag. 0.10E+00    2.2     0.05492734     -2483.2781302721 
> -3.79E-04
>     22 P_Mix/Diag. 0.10E+00    2.2     1.00816260     -2483.2784106908 
> -2.80E-04
>     23 P_Mix/Diag. 0.10E+00    2.2     0.20701607     -2483.2636042414  
> 1.48E-02
>     24 P_Mix/Diag. 0.10E+00    2.2     0.16102347     -2483.2681624989 
> -4.56E-03
> ..
>
> Is it worth to try with other settings for the diagonalization/mixing or 
> should I look somewhere else? 
>
> Thanks a lot
> D.
>
>
> El viernes, 11 de mayo de 2018, 14:32:12 (UTC+2), Matthias Krack escribió:
>
> Hi Daniel
>
>  
>
> did you check if other basis sets like DZVP-MOLOPT-SR cause the same 
> behaviour?
>
>  
>
> Best regards
>
>  
>
> Matthias
>
>  
>
> *From:* cp... at googlegroups.com [mailto:cp... at googlegroups.com] *On Behalf 
> Of *Dan_M
> *Sent:* 11 May 2018 11:48
> *To:* cp2k
> *Subject:* Re: [CP2K:10302] Re: MO coefficients not normalized?
>
>  
>
> Hi Matthias,
>
> I did what you suggested and even though it seemed to make the convergence 
> a bit smoother for OT, still it does not improve the diagonalization.
> Specifically, I set EPS_DEFAULT 1.0E-14 and dropped the *_CUTOFF and XC 
> smoothing, and converged with OT and EPS_SCF 1.0E-8.
> With this optimized wfn I started the diagonalization (algorithm standard, 
> direct_p_mixing, alpha 0.1) and doesn't work:
>
>   Step     Update method      Time    Convergence         Total energy    
> Change
>   
> ------------------------------------------------------------------------------
>      1 P_Mix/Diag. 0.10E+00    5.9     1.04345518     -2483.7051317469 
> -2.48E+03
>      2 P_Mix/Diag. 0.10E+00    6.2     0.21526298     -2483.6950681260  
> 1.01E-02
>      3 P_Mix/Diag. 0.10E+00    6.3     0.18583657     -2483.6983718168 
> -3.30E-03
>      4 P_Mix/Diag. 0.10E+00    6.2     0.15912799     -2483.7005021331 
> -2.13E-03
>      5 P_Mix/Diag. 0.10E+00    6.6     0.13537782     -2483.7018913141 
> -1.39E-03
>      6 P_Mix/Diag. 0.10E+00    7.2     0.11457317     -2483.7028012278 
> -9.10E-04
>      7 P_Mix/Diag. 0.10E+00    6.2     0.09655329     -2483.7033951772 
> -5.94E-04
>      8 P_Mix/Diag. 0.10E+00    6.2     0.08107945     -2483.7037777217 
> -3.83E-04
>      9 P_Mix/Diag. 0.10E+00    6.4     0.06788010     -2483.7040173663 
> -2.40E-04
>     10 P_Mix/Diag. 0.10E+00    6.2     1.05830128     -2483.7041598673 
> -1.43E-04
>     11 P_Mix/Diag. 0.10E+00    6.4     0.27282434     -2483.6885022250  
> 1.57E-02
>     12 P_Mix/Diag. 0.10E+00    6.2     0.19477670     -2483.6934564774 
> -4.95E-03
>     13 P_Mix/Diag. 0.10E+00    6.3     0.15900657     -2483.6966522751 
> -3.20E-03
>     14 P_Mix/Diag. 0.10E+00    6.3     0.13501187     -2483.6987689554 
> -2.12E-03
>     15 P_Mix/Diag. 0.10E+00    6.2     0.11406673     -2483.7002037460 
> -1.43E-03
>     16 P_Mix/Diag. 0.10E+00    6.3     0.09597285     -2483.7011950370 
> -9.91E-04
>     17 P_Mix/Diag. 0.10E+00    6.3     0.08046688     -2483.7018901542 
> -6.95E-04
>     18 P_Mix/Diag. 0.10E+00    6.3     0.06782297     -2483.7023829252 
> -4.93E-04
>     19 P_Mix/Diag. 0.10E+00    6.3     1.04290747     -2483.7027348383 
> -3.52E-04
>     20 P_Mix/Diag. 0.10E+00    6.2     0.21550410     -2483.6899786616  
> 1.28E-02
>     21 P_Mix/Diag. 0.10E+00    6.2     0.18544263     -2483.6942956542 
> -4.32E-03
> ....
>
> BTW, that was after I set EPS_DIIS in &SCF below EPS_SCF, since otherwise 
> things get much worse after DIIS starts:
>
>   Step     Update method      Time    Convergence         Total energy    
> Change
>   
> ------------------------------------------------------------------------------
>      1 P_Mix/Diag. 0.10E+00    5.9     1.04345518     -2483.7051317469 
> -2.48E+03
>      2 P_Mix/Diag. 0.10E+00    6.5     0.21526298     -2483.6950681260  
> 1.01E-02
>      3 P_Mix/Diag. 0.10E+00    6.5     0.18583657     -2483.6983718168 
> -3.30E-03
>      4 P_Mix/Diag. 0.10E+00    6.6     0.15912799     -2483.7005021331 
> -2.13E-03
>      5 P_Mix/Diag. 0.10E+00    6.5     0.13537782     -2483.7018913141 
> -1.39E-03
>      6 P_Mix/Diag. 0.10E+00    6.5     0.11457317     -2483.7028012278 
> -9.10E-04
>      7 P_Mix/Diag. 0.10E+00    6.5     0.09655329     -2483.7033951772 
> -5.94E-04
>      8 DIIS/Diag.  0.26E-02    6.6     1.09993086     -2483.7037777217 
> -3.83E-04
>      9 P_Mix/Diag. 0.10E+00    6.5    98.45213358     -2482.2918306873  
> 1.41E+00
>     10 P_Mix/Diag. 0.10E+00    6.5    88.61338472     -2479.1562224901  
> 3.14E+00
>     11 P_Mix/Diag. 0.10E+00    6.4   738.84827806     -2413.5998990757  
> 6.56E+01
>     12 P_Mix/Diag. 0.10E+00    6.5   726.38204744     -2239.0573891721  
> 1.75E+02
> ...
>
> So probably you are right, there may be something else wrong. The possible 
> issue that comes to my mind is that the system is not that simple. It is a 
> water slab periodic in 2 dimensions and with a ~12 angstroms spacing in the 
> 3rd dimension, treated as fully periodic (e.g. &Poisson periodic XYZ) but I 
> made sure that the net dipole is very small and slab-slab interactions are 
> negligible for the neutral water slab. Then there is a proton placed close 
> to a water in the slab surface, geometry very far from optimal (some could 
> say "unphysical" but it should be treatable --and actually it works with 
> OT--, H+ is 1.14 angstrom away from the closest O and 1.47 to the closest 
> H). I am aware that of course I can not expect to converge the wfn for any 
> kind of crazy geometry, but what I don't understand is why if OT converges 
> (despite all the issues like charged cell, exotic geometry, etc) then 
> diagonalization does not. Is it possible that simply the difficult geometry 
> screws up that much the diagonalization of the OT converged wfn?
>
> Thanks a lot for your comments,
> Daniel
>
>
> El jueves, 10 de mayo de 2018, 18:43:47 (UTC+2), Matthias Krack escribió:
>
> Hi Daniel
>
>  
>
> If your preceding OT run converged properly (tightly), the restart with 
> diagonalisation should converge immediately or after a few steps, otherwise 
> something is wrong.
>
>  
>
> There are some issues in your input which I would change without claiming 
> that this will solve your problem. I would
>
> 1)      use a smaller EPS_DEFAULT, e.g. at least 1.0E-12 (smaller is also 
> fine), 1.0E-10 is not tight enough
>
> 2)      drop the *_CUTOFF values in the &XC section unless you have a 
> good reason to set some of these values explicitly
>
> 3)      drop the smoothing unless you have any good reason to use it 
> (e.g. with BLYP), since you are using with 700Ry a rather high cutoff anyway
>
> 4)      use diagonalisation  with direct_p_mixing and a mixing alpha of 
> about 0.1 for restart, if that does not converge immediately or at least 
> within a few SCF steps starting from a converged OT run, then most likely 
> something else is wrong and it is unlikely that any other mixing method 
> will work better and solve the problem
>
> I understood that you are dealing with a condensed phase system. If yes, 
> did you check that the QZV3P basis sets you are using are suited for that 
> setup?
>
>  
>
> Best regards
>
>  
>
> Matthias
>
>  
>
> *From:* cp... at googlegroups.com [mailto:cp... at googlegroups.com] *On Behalf 
> Of *Dan_M
> *Sent:* 10 May 2018 18:04
> *To:* cp2k
> *Subject:* Re: [CP2K:10300] Re: MO coefficients not normalized?
>
>  
>
> Hi Matthias,
>
> yest I did but it does not converge, for instance this is what I get when 
> using Davidson diagonalization (defaults parameters for &MIXING):
>
>   Step     Update method      Time    Convergence         Total energy    
> Change
>   
> ------------------------------------------------------------------------------
>      1 P_Mix/Dav.  0.40E+00    8.1     0.00309369     -2483.1531852407 
> -2.48E+03
>      2 P_Mix/Dav.  0.40E+00    2.5     0.15334223     -2483.1531847710  
> 4.70E-07
>      3 P_Mix/Dav.  0.40E+00    2.4     0.14839060     -2483.1496260655  
> 3.56E-03
>      4 P_Mix/Dav.  0.40E+00    2.4     0.06204907     -2483.1516643558 
> -2.04E-03
>      5 P_Mix/Dav.  0.40E+00    2.4     0.72149356     -2483.1519086893 
> -2.44E-04
>      6 P_Mix/Dav.  0.40E+00    2.4     0.44697821     -2483.0750573108  
> 7.69E-02
>      7 P_Mix/Dav.  0.40E+00    2.4     0.21458187     -2483.1176203039 
> -4.26E-02
>      8 P_Mix/Dav.  0.40E+00    2.4     0.09370387     -2483.1338242392 
> -1.62E-02
>      9 P_Mix/Dav.  0.40E+00    2.4     1.08948074     -2483.1415463487 
> -7.72E-03
>     10 P_Mix/Dav.  0.40E+00    2.4     0.67563179     -2482.9378947719  
> 2.04E-01
>     11 P_Mix/Dav.  0.40E+00    2.4     0.32819448     -2483.0539735944 
> -1.16E-01
>     12 P_Mix/Dav.  0.40E+00    2.4     0.15275080     -2483.0996929120 
> -4.57E-02
>     13 P_Mix/Dav.  0.40E+00    2.4     1.06118539     -2483.1220162257 
> -2.23E-02
>     14 P_Mix/Dav.  0.40E+00    2.4     0.77108692     -2482.9213332983  
> 2.01E-01
>     15 P_Mix/Dav.  0.40E+00    2.4     0.32374229     -2483.0459012328 
> -1.25E-01
>     16 P_Mix/Dav.  0.40E+00    2.4     0.16259590     -2483.0951505330 
> -4.92E-02
>     17 P_Mix/Dav.  0.40E+00    2.3     0.10138969     -2483.1193594430 
> -2.42E-02
>     18 P_Mix/Dav.  0.40E+00    2.4     0.06424836     -2483.1326526033 
> -1.33E-02
>     19 P_Mix/Dav.  0.40E+00    2.4     0.03960077     -2483.1403233567 
> -7.67E-03
> ...
>
> Similar behavior happens with the other diagonalization flavors, I am 
> playing around with the mixing parameters but no success so far.
>
> In passing there is a curious thing I observed with OT: the wfn is 
> converged and the eigenvalues are printed in the PDOS but they are not 
> printed correctly together with the MO coefficients (I request eigenvalues, 
> eigenvectors and occupations), instead I get:
>
>  MO EIGENVALUES, MO OCCUPATION NUMBERS, AND SPHERICAL MO EIGENVECTORS
>
>                               1            2            3            4
>                            0.000000     0.000000     0.000000     0.000000
>
>                            2.000000     2.000000     2.000000     2.000000
>
>      1     1  H  1s        0.041699    -0.021600     0.017105     0.034420
>      2     1  H  2s       -0.001594     0.001644    -0.000409    -0.000568
>      3     1  H  3s       -0.011532     0.007340    -0.005061    -0.008943
>      4     1  H  4s       -0.005753     0.006757    -0.005764    -0.009668
> ...
>
> For what it is worth, I am using version 5.1 (svn 18091) and the relevant 
> parts of the electronic structure are these (for the diagonalization I just 
> turn &OT F and uncomment the relevant parts; also I tried with and without 
> ADDED_MOS/NLUMO etc etc...)
>
> &FORCE_EVAL
>   METHOD QS
>   &DFT
>     CHARGE 1
>     BASIS_SET_FILE_NAME ./GTH_BASIS_SETS
>     POTENTIAL_FILE_NAME ./GTH_POTENTIALS
>     &PRINT
>       &MULLIKEN ON
>         &EACH
>             JUST_ENERGY 1
>         &END EACH
>       &END
>       &HIRSHFELD
>         &EACH
>             JUST_ENERGY 1
>         &END EACH
>       &END
>       &MO_CUBES
>           WRITE_CUBE F
> !          NLUMO 576
>       &END
>       &MO ON
>         &EACH
>           JUST_ENERGY 1
>           QS_SCF 0
>         &END
> !        MO_INDEX_RANGE 1 1152
>         EIGENVALUES
>         EIGENVECTORS
>         OCCUPATION_NUMBERS
>       &END
>       &PDOS
>         &EACH
>           JUST_ENERGY 1
>         &END
>         APPEND
> !        NLUMO 576
>       &END
> !      &AO_MATRICES ON
> !        OVERLAP T
> !      &END
>     &END
>
>     &MGRID
>       REL_CUTOFF 70.0
>       NGRIDS     5
>       CUTOFF  700.0
>     &END MGRID
>     &QS
>       METHOD GPW
>       EPS_DEFAULT 1.0E-10
>       MAP_CONSISTENT
>     &END QS
>     &SCF
>       &PRINT
>         &RESTART
>            BACKUP_COPIES 1
>         &END RESTART
>       &END PRINT
>       SCF_GUESS  RESTART
> !     ADDED_MOS 576 
>       MAX_SCF 20
>       EPS_SCF 2.0E-7
>  !     EPS_LUMO 2.0E-7
>  !     MAX_ITER_LUMO 10000
>       &OUTER_SCF
>         EPS_SCF 2.0E-7
>         MAX_SCF 300
>       &END OUTER_SCF
> !      &MIXING
> !        ALPHA 0.01
> !      &END
> !      &DIAGONALIZATION
> !        ALGORITHM  DAVIDSON
> !      &END
>       &OT T
>         MINIMIZER DIIS
>         PRECONDITIONER FULL_KINETIC  !  FULL_ALL
>         SAFE_DIIS  T
>       &END OT
>     &END SCF
>     &XC
>       &XC_FUNCTIONAL PBE
>       &END XC_FUNCTIONAL
>       DENSITY_CUTOFF     1.0000000000000000E-10
>       GRADIENT_CUTOFF     1.0000000000000000E-10
>       TAU_CUTOFF     1.0000000000000000E-10
>       &XC_GRID
>         XC_SMOOTH_RHO NN50
>         XC_DERIV NN50_SMOOTH
>       &END XC_GRID
>     &END XC
>     &POISSON
>       PERIODIC XYZ
>     &END POISSON
>   &END DFT
>   &SUBSYS
>     &CELL
>       ABC 1.5200509080292399E+01  3.3000000000000E+01  
> 1.3178605533387005E+01
>       PERIODIC XYZ
>     &END CELL
>     &TOPOLOGY
>       COORD_FILE_NAME ./mystruc.xyz
>       COORDINATE XYZ
>     &END TOPOLOGY
>     &KIND O
>       BASIS_SET QZV3P-GTH-q6
>       POTENTIAL GTH-PBE-q6
>     &END KIND
>     &KIND H
>       BASIS_SET QZV3P-GTH-q1
>       POTENTIAL GTH-PBE-q1
>     &END KIND
>     &END
>   &END SUBSYS
>   &PRINT
>     &TOTAL_NUMBERS  ON
>     &END TOTAL_NUMBERS
>   &END
> &END FORCE_EVAL
>
>
> Thanks again and best
>
> Daniel
>
>
>
>
> El jueves, 10 de mayo de 2018, 14:23:28 (UTC+2), Matthias Krack escribió:
>
> Dear Daniel
>
>  
>
> Did you try to restart with DIAGONALISATION and ADDED_MOS using a 
> wavefunction restart file from a well-converged OT run?
>
>  
>
> Best regards
>
>  
>
> Matthias
>
>  
>
> *From:* cp... at googlegroups.com [mailto:cp... at googlegroups.com] *On Behalf 
> Of *Dan_M
> *Sent:* 10 May 2018 13:46
> *To:* cp2k
> *Subject:* [CP2K:10298] Re: MO coefficients not normalized?
>
>  
>
>
> Thanks a lot Matt for your very fast answer. I was so concerned with 
> technical issues that I forgot about the basics.
>
> Actually maybe you or some other expert can help me out with the actual 
> issue I am having. The situation is this:
>
> I want to get the MOs (eigenvalues and eigenvectors) for both the occupied 
> and unoccupied states in a somewhat involved system (~100-200 waters plus 
> one proton, i.e. total charge +1, geometry let's say far from any local 
> minima). For this I tried two routes:
>
> 1) converge the wfn with OT and request NLUMO to be computed after 
> convergence. With this I find two problems:
>   - The calculation of the LUMOs does not converge (I get "WARNING : did 
> not converge in ot_eigensolver" even if I increase MAX_ITER_LUMO to 1000 
> which I think should be enough). I note that I could get it converged for 
> EPS_LUMO 1.0E-4 but I tried with a much tighter convergence (2.0E-07 as 
> with the occupied states) since what I get otherwise is the energy of the 
> LUMO below that of the HOMO. I am aware of this happening often when the 
> system is metallic and OT is not well suited but I think it should not 
> happen in a protonated water system (I would expect finding the LUMO as a 
> lone state somewhere in the middle of the band gap, but not this).
>   - Even when it converges (which I managed to do in toy systems but not 
> on my system of interest), this only works for getting the eigenvalues 
> which can be done either requesting the NLUMO in the &PDOS or in the 
> &MO_CUBES sections, but not the eigenvectors even if I try to do the trick 
> of asking for MO_INDEX_RANGE 1 [nhomo+nlumo] in the &MO section.
>
> 2) converge the wfn with diagonalization in any flavor (standard, 
> davidson, lanczos or filter_matrix) requesting ADDED_MOS. Here the problem 
> is that the diagonalization is a complete pain and I am struggling a lot to 
> get it converged, which I did not manage yet. I am trying to do the usual 
> tricks (playing with the ALPHA in &MIXING, etc), but still I have not 
> managed to converge it. I tried doing the trick of computing the wfn with 
> OT and then use that wfn as guess in a run with diagonalization with 
> ADDED_MOS, but in that case the coefficients seem to be rescaled or ignored 
> (since there are less MOS in the restart wfn than expected) and I don't get 
> any improvement.
>
> Maybe somebody could give me some tips for improving the diagonalization 
> in charged systems (some combination of mixing methods, parameters, etc.) 
> or some workaround to make it work with OT?
>
> Thanks again!
> D.
>
>  
> El miércoles, 9 de mayo de 2018, 22:21:37 (UTC+2), Matt W escribió:
>
> Dear Daniel,
>
>  
>
> the Gaussian basis set is not orthonormal, so the overlap matrix is 
> required to provide a metric that converts to an orthonormal basis. Due to 
> symmetry the pz orbital is orthogonal to the others in your example, so in 
> that case every thing is easy.
>
>  
>
> In general, the relation is C^T S C = I, where C is the matrix of MO 
> coefficients, S is the overlap matrix and I is the identity matrix. You can 
> print of the S matrix and check this. It is somewhere in the AO_MATRICES 
> section of DFT % PRINT.
>
>  
>
> See, for instance, Szabo and Ostlund, Modern Quantum Chemistry, 
> Introduction to Advanced Electronic Structure Theory - exercise 3.10 in my 
> version.
>
>  
>
> Matt
>
> On Wednesday, May 9, 2018 at 8:20:13 PM UTC+1, Dan_M wrote:
>
> Dear all,
>
> After requesting the printing out of the MO coefficients, I have observed 
> that the coefficients do not seem to be normalized. For instance, here are 
> the MOs for 1 water molecule with a SZV basis (after a single point 
> calculation on the "real" geometry, with diagonalization algorithm 
> standard):
>
>  MO EIGENVALUES, MO OCCUPATION NUMBERS, AND SPHERICAL MO EIGENVECTORS
>
>                               1              2                3            
>     4
>                            -0.952554    -0.496599    -0.304175    -0.250528
>
>                             2.000000     2.000000     2.000000     2.000000
>
>      1     1  O  2s        0.807460    -0.000000     0.542312     0.000000
>      2     1  O  3py      -0.246487    -0.000000     0.810927     0.000000
>      3     1  O  3pz      -0.000000     0.000000    -0.000000     1.000000
>      4     1  O  3px       0.000000    -0.661844    -0.000000    -0.000000
>
>      5     2  H  1s        0.125677    -0.390214    -0.194623    -0.000000
>
>      6     3  H  1s        0.125677     0.390214    -0.194623    -0.000000
>
> So only the MO 4 is trivially normalized, but the others are not. Am I 
> missing something (some correction factor, etc) or is this just the way it 
> is?
>
> Thanks and best
> Daniel
>
> -- 
> 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 cp2k+... at googlegroups.com.
> To post to this group, send email to cp... at googlegroups.com.
> Visit this group at https://groups.google.com/group/cp2k.
> For more options, visit https://groups.google.com/d/optout.
>
> -- 
> 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 cp2k+... at googlegroups.com.
> To post to this group, send email to cp... at googlegroups.com.
> Visit this group at https://groups.google.com/group/cp2k.
> For more options, visit https://groups.google.com/d/optout.
>
> -- 
> 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 cp2k+... at googlegroups.com.
> To post to this group, send email to cp... at googlegroups.com.
> Visit this group at https://groups.google.com/group/cp2k.
> For more options, visit https://groups.google.com/d/optout.
>
> -- 
> 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 cp2k+... at googlegroups.com <javascript:>.
> To post to this group, send email to cp... at googlegroups.com <javascript:>.
> Visit this group at https://groups.google.com/group/cp2k.
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20180511/5a785bfd/attachment.htm>


More information about the CP2K-user mailing list