Neither textbooks like Kittel or Ashcroft&Mermin nor information gathered
in under/graduate courses on solid state physics, considering
quasi-continuum quasi-momenta/wavevectors provide much support on efficient
k-sampling using very modest k-grids. I was asking for some practical hints
on reasonably k-sampling (presumably much more similar to small-crystal
approaches (http://link.aps.org/doi/10.1103/PhysRevB.37.6073,
http://link.aps.org/doi/10.1103/PhysRevB.44.8554), not obvious for people
with background in general solid state physics but with very little
experience in tran/siesta-like calculations; a point certainly known for
experts in numerical approaches to nanotransport.

Concerning the main text of the PCCP-paper mentioned:

1. I can only find that five k-points were used in electronic structure
calculations (I presume kx=ky=5 used for siesta relaxation) and 25< k_xy<50
for "transport calculations". It is not clear to me whether "transport
calculations" refer to the section transiesta < SR.fdf > SR.out or to the
section "tbtrans < SR.fdf > tbt-SR.out &

2. Sorry for having possibly overlooked something, but I cannot find any
information on the kz-values used in all these runs. What I see in the ESI
is an overall use of kz=1. This kz-value is highly puzzling for me.


On Tue, Jan 19, 2016 at 10:01 PM, Nick Papior <[email protected]> wrote:

> You seem to think that k-points are a generic chosen value. It is not.
> You should think of k-points in _exactly_ the same way as in regular
> siesta calculations.
> And what does one do with k-points in siesta?
> Basically, you converge them...
>
> I would highly advice you to read Kittel, Martin, or any other book on
> condensed matter theory where the Brillouin zone is explained!
> Perhaps, that would reveal the importance of choosing a correct and
> appropriate k-point sampling?
> If you have a professor, ask her/him for guidance.
>
> NOTE:
> http://www.rsc.org/suppdata/c5/cp/c5cp04613k/c5cp04613k1.txt
> the k-point samplings for transiesta and tbtrans _are_ different.
> REMARK: that this input fdf file is for a future release of
> transiesta/tbtrans. Hence not all keywords are used in the currently
> available transiesta/tbtrans.
> The k-grid is as written in the article. 5 during transiesta, 25 and 50
> for tbtrans. The value 25 also exists in that file.
>
>
>
> 2016-01-19 21:38 GMT+01:00 ticu Cubot <[email protected]>:
>
>> Dear TranSiesta users,
>>
>> I am (still) confused on the k-sampling needed in the three steps
>> (denoted 1, 2, 3 below) in transport calculations for molecular junctions.
>> Let me refer to Au-BDT-Au, with all BDT atoms having y=0 (or almost zero).
>> Is is correct, if I (roughly) set
>>
>> 1. kx=8, ky=2, kz=50 for electrode-alone calculations to get the files
>> electrode.TSHS
>>
> kx and ky should be the same as chosen for your device calculation.
> kz should just be very high. I tend to use 100, but anything above 50
> would probably suffice... (converge if in doubt...)
>
>>
>> 2. ky=8, ky=2,  kz=2 the SR-transiesta step to obtain the SR- files
>> (SR.TSDE, SR.TSHS) needed for tbtrans. kx and ky same as in step 1, ky < kx
>> because of BDT extension along x in transverse direction. In this choice, I
>> was (correctly?) inspired by the k-values chosen in
>>
> Converge kx and ky. Understand what they imply by reading more material.
>
>>
>> http://www.rsc.org/suppdata/c5/cp/c5cp04613k/c5cp04613k1.txt
>>
>> 3. kx=16, ky=4, kz=50 for tbtrans calculations. That is, more dense
>> sampling for tbtrans than for transiesta (step 2), because
>> k_xyz-convergence of transmission is slower. Here I would note that in the
>> above link the same kgridMonkhorstPack seemed to have been used both in
>> step 2 and 3 (this is very surprising for me!); anyway,
>> TBTkgridMonkhorstPack is not explicitly given, and because other TBT
>> settings are given in that file, I assume that transiesta-k-grid and
>> tbtrans-k-grid were the same.
>>
> Converge kx and ky. Set kz=1.
>
>
>>
>> Many thanks for illuminating me on this point.
>>
>> ticu
>>
>
>
>
> --
> Kind regards Nick
>

Responder a