MO coefficients not normalized?

Dan_M danielm... at gmail.com
Thu May 10 11:46:20 UTC 2018


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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20180510/ade2f1d1/attachment.htm>


More information about the CP2K-user mailing list