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

Dan_M danielm... at gmail.com
Thu May 10 16:04:05 UTC 2018


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 <javascript:> [mailto:
> cp... at googlegroups.com <javascript:>] *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 <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/20180510/1a218a00/attachment.htm>


More information about the CP2K-user mailing list