Dear Fabian (and other devs),<div><br></div><div>I experimented a bit further with the toy problems and came to the following conclusion:</div><div>- my atoms should have fractional coordinates (relative to the bravais vectors) between -0.5 and 0.5. Otherwise, the periodic image of them will be taken as the main cell atom such that they are in between -0.5 and 0.5. This explains the weird phenomenon I had with cnt.</div><div>- For the overlaps with periodic image cells, you should interchange the lower or upper triangular parts of S_(x,y,z) and S_(-x,-y,-z) depending on whether the sum of the atom indices of the atoms to which the orbitals belong are odd or even.</div><div>With this I managed to build a script that performs these switches and I now get the correct band structure. I think it could still definitely be worthwhile for other people (and to have something more robust than my script) to have the correct matrices directly from cp2k, but for now I have a workaround for my own projects.</div><div><br></div><div>Kind regards and many thanks for the help,</div><div><br></div><div>Rutger Duflou<br><br></div><div class="gmail_quote"><div dir="auto" class="gmail_attr">Op vrijdag 16 april 2021 om 16:15:48 UTC+2 schreef Rutger Duflou:<br/></div><blockquote class="gmail_quote" style="margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Deer Fabian,<div><br></div><div>Ah, that explains indeed how cp2k still gets the right result. I had been wondering about that.</div><div>Implementing the right printing would be very helpful. I should mention that it is only a problem when doing a kpoint calculation (which is unfortunately required for real systems as the supercell approach quickly becomes too large), which combined with a comment in the file I mentioned: "! FIXME for non-periodic systems, the whole subcell trick is skipped</div><div>                      ! yielding a Natom**2 pair list build."<br>leads me to believe that it is a sort of optimization artifact that could be skipped altogether. I unfortunately do not know how to skip it, so I'm just bringing it to your attention.</div><div><br></div><div>Kind regards,</div><div><br></div><div>Rutger<br><br></div><div class="gmail_quote"><div dir="auto" class="gmail_attr">Op vrijdag 16 april 2021 om 15:46:28 UTC+2 schreef <a href data-email-masked rel="nofollow">fa...@gmail.com</a>:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Dear Rutger,</div><div><br></div><div>I think it's true that the printed overlap matrices are not entirely correct. I think the printing of the AO matrices is intended only for debugging purposes. You can find the relevant code to perform the real space to k-space transformation in kpoint_methods.F in the rskp_transform subroutine. At line 733 of the current trunk cp2k uses certain symmetries:</div><div><br></div><div>         IF (do_symmetric .AND. (iatom > jatom)) THEN<br>            irow = jatom<br>            icol = iatom<br>            fsym = -1.0_dp<br>         END IF<br></div><div><br></div><div>I can try to implement the printing of the real space Hamiltonian and overlap matrices in the csr format if that's something usefull to you.</div><div><br></div><div>Cheers,</div><div>Fabian<br></div><div class="gmail_quote"><div dir="auto" class="gmail_attr">On Friday, 16 April 2021 at 14:07:10 UTC+2 <a rel="nofollow">rut...@gmail.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Dear developers,</div><div><br></div><div>Apologies beforehand as this is going to be a long question.</div><div>I'm using CP2K to extract Hamiltonians and overlap matrices to then use them in transport calculations. The band structures that I obtain with the Hamiltonians and overlap matrices from CP2K are, however, off. I did quite a few tests on 2 toy-problems: two-dimensional WS2 (with 3 atoms) and one-dimensional cnt (with 64 atoms). For both systems I calculated the overlap matrix from a supercell (without periodic images) and a kpoint calculation with periodic images and compared the corresponding overlap entries.</div><div><br></div><div>For WS2 the overlap of orbitals both in the main unit cell are equal for the supercell and kpoint approach. For periodic images, however, the kpoint approach gives symmetrical matrices (which to me does not make sense, the overlap between a 1s orbital on W in (0,0,0) and a 1s orbital on S in (1,0,0) is not equal to the overlap between a 1s orbital on S in (0,0,0) and a 1s orbital on W in (1,0,0)).</div><div>    _____<br></div><div>  /         \</div><div>/   W-S   \_____            (ASCII art to demonstrate what I mean.) </div><div>\ (0,0,0) /         \                      (I hope the format is preserved in this mail).</div><div>  \_____/    W-S  \</div><div>             \ (1,0,0) /</div><div>               \_____/</div><div>After comparison with the supercell approach I found that I can reproduce the correct matrices if I interchange the upper triangular part of the overlap matrix (and KS matrix) with the (x,y,z) and (-x,-y,-z) cell when exactly one of the two orbitals resides on W. If no orbital or both orbitals reside on W, then I have to interchange the lower-triangular elements of the (x,y,z) and (-x,-y,-z) overlap matrices. Looking into the source code indeed shows that these periodic image matrices are printed as symmetric matrices even though they aren't... I, however, do not understand why it is sometimes the upper triangular element and sometimes the lower-triangular element that is correct and when it is which for other systems.</div><div><br></div><div>For cnt, even the overlap matrices of the main unit cell differ between kpoint approach and supercell approach. It seems that in the kpoint approach, for the overlap matrix entries it sometimes takes atoms from periodic images instead of the main unit cell. I verified this by changing the unit cell dimensions and noticing that some overlap matrix entries of the main unit cell change, which, as far as I can see, should not be possible if they are actually both in the main unit cell.</div><div><br></div><div>I have looked into the source code and think I found some clue on line 1263 of qs_neighbour_lists.F (version 7.1), but at that point the code becomes a bit too obscure, so I was wondering whether I could get some insight into this matter.</div><div><br></div><div>Kind regards,</div><div><br></div><div>Rutger Duflou</div><div><br></div></blockquote></div></blockquote></div></blockquote></div>