[CP2K:10302] Re: MO coefficients not normalized?
Matt W
mattwa... at gmail.com
Fri May 11 16:25:00 UTC 2018
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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20180511/eacc323a/attachment.htm>
More information about the CP2K-user
mailing list