[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