[CP2K-user] Overlap matrices for transport

[Rutger Duflou]

Deer Fabian,

Ah, that explains indeed how cp2k still gets the right result. I had been 
wondering about that.
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
                      ! yielding a Natom**2 pair list build."
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.

Kind regards,

Rutger

Op vrijdag 16 april 2021 om 15:46:28 UTC+2 schreef fa... at gmail.com:

> Dear Rutger,
>
> 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:
>
>          IF (do_symmetric .AND. (iatom > jatom)) THEN
>             irow = jatom
>             icol = iatom
>             fsym = -1.0_dp
>          END IF
>
> 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.
>
> Cheers,
> Fabian
> On Friday, 16 April 2021 at 14:07:10 UTC+2 rut... at gmail.com wrote:
>
>> Dear developers,
>>
>> Apologies beforehand as this is going to be a long question.
>> 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.
>>
>> 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)).
>>     _____
>>   /         \
>> /   W-S   \_____            (ASCII art to demonstrate what I mean.) 
>> \ (0,0,0) /         \                      (I hope the format is 
>> preserved in this mail).
>>   \_____/    W-S  \
>>              \ (1,0,0) /
>>                \_____/
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Kind regards,
>>
>> Rutger Duflou
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20210416/374ae72a/attachment.htm>