Real space representation of S and KS matrices with k-points

[Dmitry Ryndyk]

Dear developers,

I would greatly appreciate it if you could provide me with the reference to the exact description of the real space S and KS matrices, stored in qs_env%ks_env%matrix_ks_kp and qs_env%ks_env%matrix_s_kp.

I mean not the details of DBCSR matrices, but the way the matrix elements are placed inside the matrices.

My test calculations, as well as some code investigation, show that these matrix elements are mixed between space replicas ("images") used at k-point calculations, and some rearrangement is required to get normal symmetrical matrices, which depend on the atomic indices. 

Thank you,

Dmitry

[Augustin Bussy]

Dear Dimitry,

Dealing with CP2K's real space matrices in k-point calculations can be quite challenging. In principle, it follows equations (10) and (11) of https://arxiv.org/pdf/2508.15559. Elements i of the qs_env%ks_env%matrix_s_kp array contains real space overlap matrix elements between AOs in the main cell, and AOs in periodic image with index i. The indexing of periodic images is that imposed by the neighbor lists.

For historical reasons, the KP overlap and KS matrices are stored as DBCSR symmetric types, even though they are not symmetric. That's where it gets complicated. Both the S and KS matrices are Hermitian, and they have the following symmetry: S_ij^b = S_ji^-b, where b denotes the translation from the main cell to a given periodic image.

If you have access to the upper diagonal of a real space matrix with one AO in a periodic cell shifted by b, and that of a real space matrix with an AO shifted by -b, then you can reconstruct the full, asymmetric, real space matrix at b.

In the code, this operation is done when performing Fourier transforms real space to k-space. For example here: https://github.com/cp2k/cp2k/blob/5f3bc36082e75c975caee6a92073f395a2af7674/src/kpoint_methods.F#L855-L864.

I hope that helps.

Best,

Augustin

[Augustin Bussy]

For clarity: Both the S and KS matrices are Hermitian in k-space, but in real space, we have: S_ij^b = S_ji^-b

[Dmitry Ryndyk]

Dear Augustin,

thank you for the fast answer. It helps me to understand what is going on!

Best wishes,

Dmitry

[Dmitry Ryndyk]

Meanwhile, I found a very strange problem with the real space matrix images themselves.

As an example, a very simple system of a 1D H array, with 4 atoms in the unit cell (input file in attachment).

The coordinates are

    &CELL
      ABC    16.0 16.0 6.0
      PERIODIC xyz
    &END CELL
    &COORD
      H        0.00000000       0.00000000       0.00000000 
      H        0.00000000       0.00000000       1.50000000 
      H        0.00000000       0.00000000       3.00000000 
      H        0.00000000       0.00000000       4.50000000 
    &END COORD

The 5 RS image cells are

S CSR write|   5 periodic images
      Number    X      Y      Z
         1      0      0      0
         2      0      0     -1
         3      0      0      1
         4      0      0     -2
         5      0      0      2

and the 0,0,0 image for S overlap is (all other in attachment)

       1       1  0.10000000000000E+001
       1       2  0.39126534955779E+000
       1       3  0.39734112631705E-001
       1       4  0.39126534955779E+000
       2       1  0.39126534955779E+000
       2       2  0.10000000000000E+001
       2       3  0.39126534955779E+000
       2       4  0.39734112631705E-001
       3       1  0.39734112631705E-001
       3       2  0.39126534955779E+000
       3       3  0.10000000000000E+001
       3       4  0.12433452435606E-002
       4       1  0.39126534955779E+000
       4       2  0.39734112631705E-001
       4       3  0.12433452435606E-002
       4       4  0.10000000000000E+001

As one can see, the values of S correspond to the atom positions in order

4 1 2 3

not

1 2 3 4

as I assume to be correct.

If one makes only one RS image, e.g., taking 

ABC    16.0 16.0 16.0

in the input file, the file looks correct.

       1       1  0.10000000000000E+001
       1       2  0.39126534955779E+000
       1       3  0.39734112631705E-001
       1       4  0.12433452435606E-002
       2       1  0.39126534955779E+000
       2       2  0.10000000000000E+001
       2       3  0.39126534955779E+000
       2       4  0.39734112631705E-001
       3       1  0.39734112631705E-001
       3       2  0.39126534955779E+000
       3       3  0.10000000000000E+001
       3       4  0.39126534955779E+000
       4       1  0.12433452435606E-002
       4       2  0.39734112631705E-001
       4       3  0.39126534955779E+000
       4       4  0.10000000000000E+001

Here (1,4) and (4,1) matrix elements are the smallest.

Besides, this "cyclic shift" depends on k-points and the linear shift of atom coordinates.

Even if it does not change k-point calculations itself, it can be important in other problems.

Actually, I found this problem in "NEGF" transport systems, where it is important.

At the moment, I have not found the origin of this problem.

[Fabian Ducry]

Hi Dmitry,

the coordinates need to be in (-L/2, L/2) in each dimension, where L is the length of the cell.

Cheers,
Fabian

[Dmitry Ryndyk]

Ah, indeed!

It works and technically solves my problem.

Thank you, Fabian!

Why not do it by default when creating RS image matrices?

Best wishes,

Dmitry

[Fabian Ducry]

Hi Dmitry,

You can easily do it with https://manual.cp2k.org/trunk/CP2K_INPUT/FORCE_EVAL/SUBSYS/TOPOLOGY/CENTER_COORDINATES.html
bo need to manually shift the atoms. But I think it should be better documented. I'll try to find time to do it.

Cheers,
Fabian

[Dmitry Ryndyk]

Hi Fabian,

Unfortunately, it does not work if you need to analyse different parts of a bigger system and calculate matrix elements for these parts consistently.

Best,

Dmitry

[Fabian Ducry]

Hi Dmitry,

I don't understand what does not work with shifting the atoms to between -L/2 and L/2. Even if the atoms are part of a larger structure, a linear shift should not affect the elements.

Cheers,
Fabian

[Dmitry Ryndyk]

Hi Fabian,

the NEGF code (not written by me) compares the coordinates of two FORCE_EVAL: one for the entire system and the other for an electrode (contact). If I try to shift the electrode coordinates in the input file, an error appears. I can rewrite it, but I found a better solution: shift the coordinates inside the code after the point where they are compared. 
 

Best wishes,

Dmtry