[CP2K-user] Overlap matrices for transport

[Rutger Duflou]

Dear Fabian,

Thank you very much. 

Kind regards,

Rutger

Op vrijdag 30 april 2021 om 20:12:26 UTC+2 schreef fa... at 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/20210504/00f710db/attachment.htm>