[CP2K-user] Overlap matrices for transport
Rutger Duflou
rutger.... at gmail.com
Tue May 4 09:57:04 UTC 2021
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>
More information about the CP2K-user
mailing list