[CP2K-user] Overlap matrices for transport

[fa...@gmail.com]

Dear Rutger,

The trunk version of cp2k now has a switch REAL_SPACE in 
DFT%PRINT%S_CSR_WRITE and DFT%PRINT%KS_CSR_WRITE to print the real space 
representation of the overlap and KS matrix.

Cheers,
Fabian
On Thursday, 22 April 2021 at 16:01:59 UTC+2 rut... at gmail.com wrote:

> Dear Fabian (and other devs),
>
> I experimented a bit further with the toy problems and came to the 
> following conclusion:
> - 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.
> - 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.
> 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.
>
> Kind regards and many thanks for the help,
>
> Rutger Duflou
>
> Op vrijdag 16 april 2021 om 16:15:48 UTC+2 schreef 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/20210430/9700cd3e/attachment.htm>