scaling factor

Asked by maluneelambari on 2018-08-29

Is there any scaling factor used in .AVDOS and .AVTRANS calculation?

Question information

Language:
English Edit question
Status:
Solved
For:
Siesta Edit question
Assignee:
No assignee Edit question
Solved by:
Nick Papior
Solved:
2018-09-03
Last query:
2018-09-03
Last reply:
2018-09-01
Nick Papior (nickpapior) said : #1

Please state the tbtrans version you use.
And also, please add context.

I am using siesta4.1 b3 version. I am trying to study Co/MoS2/Co transport.
When I plot .AVTRANS_Left_Right file I am getting maximum transmission as
0.03. DOS obtained from .AVDOS file comes in the range 0- 0.008.

On Thu, Aug 30, 2018 at 12:12 PM Nick Papior <
<email address hidden>> wrote:

> Your question #673127 on Siesta changed:
> https://answers.launchpad.net/siesta/+question/673127
>
> Status: Open => Answered
>
> Nick Papior proposed the following answer:
> Please state the tbtrans version you use.
> And also, please add context.
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/siesta/+question/673127/+confirm?answer_id=0
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/siesta/+question/673127
>
> You received this question notification because you asked the question.
>

Nick Papior (nickpapior) said : #3

In Siesta-4.1 the following applies:

AVTRANS are NOT scaled with anything.
All DOS are normalized to the number of orbitals in which the data is accumulated.
I.e. the electrode bulk-DOS is averaged according to the number of orbitals in the electrodes.
The Green function DOS is averaged to the number of orbitals in the device region.

The reason for this is that it makes electrode DOS and device DOS comparable for pristine systems (of arbitrary length).

Thanks for the reply. But I didn't get how to solve this. Can you give some
suggestions?

On Thu, Aug 30, 2018 at 12:52 PM Nick Papior <
<email address hidden>> wrote:

> Your question #673127 on Siesta changed:
> https://answers.launchpad.net/siesta/+question/673127
>
> Status: Open => Answered
>
> Nick Papior proposed the following answer:
> In Siesta-4.1 the following applies:
>
> AVTRANS are NOT scaled with anything.
> All DOS are normalized to the number of orbitals in which the data is
> accumulated.
> I.e. the electrode bulk-DOS is averaged according to the number of
> orbitals in the electrodes.
> The Green function DOS is averaged to the number of orbitals in the device
> region.
>
> The reason for this is that it makes electrode DOS and device DOS
> comparable for pristine systems (of arbitrary length).
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/siesta/+question/673127/+confirm?answer_id=2
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/siesta/+question/673127
>
> You received this question notification because you asked the question.
>

Nick Papior (nickpapior) said : #5

The normalization is written at the top of the file (if using NetCDF, I will fix for non-NetCDF). Simply multiply if you want the full, unscaled, DOS.
Otherwise you can use sisl (https://github.com/zerothi/sisl) to extract data using custom normalizations in case the *.TBT.nc file exists (i.e. if NetCDF is used).

Thank you for the reply. Sorry for asking again and again. I didn't
understand completely what happened with my calculation.
1. In the last reply you have told normalization is written at the top of
the file. Is it weight(w) written at the top of DOS file? In mine it is
0.22. Even if I consider that still I am getting very less dos and
transmission.
Am I making some other mistakes?

On Thu, Aug 30, 2018 at 1:07 PM Nick Papior <
<email address hidden>> wrote:

> Your question #673127 on Siesta changed:
> https://answers.launchpad.net/siesta/+question/673127
>
> Status: Open => Answered
>
> Nick Papior proposed the following answer:
> The normalization is written at the top of the file (if using NetCDF, I
> will fix for non-NetCDF). Simply multiply if you want the full, unscaled,
> DOS.
> Otherwise you can use sisl (https://github.com/zerothi/sisl) to extract
> data using custom normalizations in case the *.TBT.nc file exists (i.e. if
> NetCDF is used).
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/siesta/+question/673127/+confirm?answer_id=4
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/siesta/+question/673127
>
> You received this question notification because you asked the question.
>

Nick Papior (nickpapior) said : #7

The AVDOS should not contain any weight(w) anywhere?

1) You can't directly compare DOS and transmission
2) If you are not using NetCDF while compiling tbtrans the normalization is not written at the top of the file:

A) If tbtrans is compiled with NetCDF (check manual and arch.make for details) the header of the AVDOS* files is:

# DOS calculated from the Green function, k-averaged
# Date: 2018-08-30
# Normalization: 2
# E [eV] DOS [1/eV]

In which case the written DOS is DOS[1/eV] / 2. Hence to get the full DOS in the device region, simply multiply by 2.

B) If tbtrans is compiled without NetCDF there are no AVDOS files written. But the DOS files are, they contain the k-point resolved DOS with w = *** being the weights for the following columns DOS.
The normalization is not written out in 4.1-b3 (but it will be in 4.1-b4) so the header looks like this:

4.1-b3
# DOS calculated from the Greens function, k-resolved
# Date: 2018-08-30
# E [eV] DOS [1/eV]

# kb = -0.333333, 0.000000, 0.000000, w = 0.333333

Here w = 0.33333 is the k-point weight (i.e. 0.33333 is the weight for the corresponding k-point. The normalization has to be looked up in the output of tbtrans (the number of orbitals in the device region).

4.1-b4
# DOS calculated from the Greens function, k-resolved
# Date: 2018-08-30
# Normalization: 2
# E [eV] DOS [1/eV]

# kb = -0.333333, 0.000000, 0.000000, w = 0.333333

Similarly here.

Again Thank you so much.
I am using siesta 4.1b3 version and I compiled it with netcdf.
The starting line of .AVDOS file is as follows.
# DOS calculated from the Green function, k-averaged
# Date: 2018-08-26
# E [eV] DOS

No normalization value is mentioned here.

On Fri, Aug 31, 2018 at 12:22 PM Nick Papior <
<email address hidden>> wrote:

> Your question #673127 on Siesta changed:
> https://answers.launchpad.net/siesta/+question/673127
>
> Status: Open => Answered
>
> Nick Papior proposed the following answer:
> The AVDOS should not contain any weight(w) anywhere?
>
> 1) You can't directly compare DOS and transmission
> 2) If you are not using NetCDF while compiling tbtrans the normalization
> is not written at the top of the file:
>
>
> A) If tbtrans is compiled with NetCDF (check manual and arch.make for
> details) the header of the AVDOS* files is:
>
> # DOS calculated from the Green function, k-averaged
> # Date: 2018-08-30
> # Normalization: 2
> # E [eV] DOS [1/eV]
>
> In which case the written DOS is DOS[1/eV] / 2. Hence to get the full
> DOS in the device region, simply multiply by 2.
>
> B) If tbtrans is compiled without NetCDF there are no AVDOS files written.
> But the DOS files are, they contain the k-point resolved DOS with w = ***
> being the weights for the following columns DOS.
> The normalization is not written out in 4.1-b3 (but it will be in 4.1-b4)
> so the header looks like this:
>
> 4.1-b3
> # DOS calculated from the Greens function, k-resolved
> # Date: 2018-08-30
> # E [eV] DOS [1/eV]
>
> # kb = -0.333333, 0.000000, 0.000000, w = 0.333333
>
> Here w = 0.33333 is the k-point weight (i.e. 0.33333 is the weight for
> the corresponding k-point. The normalization has to be looked up in the
> output of tbtrans (the number of orbitals in the device region).
>
>
> 4.1-b4
> # DOS calculated from the Greens function, k-resolved
> # Date: 2018-08-30
> # Normalization: 2
> # E [eV] DOS [1/eV]
>
> # kb = -0.333333, 0.000000, 0.000000, w = 0.333333
>
>
> Similarly here.
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/siesta/+question/673127/+confirm?answer_id=6
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/siesta/+question/673127
>
> You received this question notification because you asked the question.
>

Nick Papior (nickpapior) said : #9

Ok, thanks for letting me know.

Then I have added that since 4.1-b3... Sorry.

It will be there in 4.1-b4.

Solution: check output and determine number of orbitals in the device region.

Yeah . In tbtrans output file it is given as follows.

tbtrans: # of device region orbitals: 689
Region (47): [A]-device
  [ 29 -- 75 ]

tbtrans: # of Left scattering orbitals: 302
tbtrans: # of Left down-folding orbitals: 722
Region (28): [A]-Left folding region
  [ 1 -- 28 ]
Region (22): [A]-Left folding in D
  [ 29 -- 50 ]

tbtrans: # of Right scattering orbitals: 347
tbtrans: # of Right down-folding orbitals: 767
Region (28): [A]-Right folding region
  [ 76 -- 103 ]
Region (25): [A]-Right folding in D
  [ 51 -- 75 ]

So, should I multiply 689 with the values in .AVDOS file to get actual value?
What about .AVTRANS ? It also looks very less.

Nick Papior (nickpapior) said : #11

Yes, this means multiply AVDOS by 689 if you want the full DOS.

As mentioned previously do NOT multiply on AVTRANS.

Following is a part of .AVDOS file

# DOS calculated from the Green function, k-averaged
# Date: 2018-08-26
# E [eV] DOS
  -4.99499 0.32281400E-05
  -4.98499 0.32281143E-05
  -4.97499 0.74773348E-05
  -4.96499 0.24372909E-05
  -4.95499 0.25193493E-05
  -4.94499 0.23208265E-05
  -4.93499 0.28884688E-05
  -4.92499 0.25108911E-05
  -4.91499 0.24959102E-05
  -4.90499 0.39273841E-05
  -4.89499 0.43086918E-05
  -4.88499 0.64038325E-05
  -4.87499 0.43463375E-05
  -4.86499 0.87443456E-05
  -4.85499 0.32653813E-05
  -4.84499 0.44184949E-05
  -4.83499 0.32215791E-05
  -4.82499 0.35213445E-05
  -4.81499 0.31563379E-05
  -4.80499 0.25111277E-05
  -4.79499 0.24603170E-05
  -4.78499 0.48389819E-05
  -4.77499 0.25781267E-05
  -4.76499 0.27705909E-05
  -4.75499 0.21356345E-05
  -4.74499 0.17763247E-05
  -4.73499 0.40402226E-05
  -4.72499 0.45038165E-05
  -4.71499 0.25287073E-05
  -4.70499 0.65379392E-05
  -4.69499 0.61455707E-05
  -4.68499 0.22337250E-05
  -4.67500 0.20777962E-05
  -4.66500 0.26780096E-05
  -4.65500 0.20960894E-05
  -4.64500 0.18567103E-05
  -4.63500 0.26879077E-05
  -4.62500 0.18819614E-05

Here even if I multiply with 689 it comes a very less value. Number of
states should be larger than these values, I think. Isn't it?

On Fri, Aug 31, 2018 at 2:02 PM Nick Papior <
<email address hidden>> wrote:

> Your question #673127 on Siesta changed:
> https://answers.launchpad.net/siesta/+question/673127
>
> Status: Open => Answered
>
> Nick Papior proposed the following answer:
> Yes, this means multiply AVDOS by 689 if you want the full DOS.
>
> As mentioned previously do NOT multiply on AVTRANS.
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/siesta/+question/673127/+confirm?answer_id=10
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/siesta/+question/673127
>
> You received this question notification because you asked the question.
>

Best Nick Papior (nickpapior) said : #13

For the record,

I have decided to change the normalization in 4.1-b4 to not do any normalization.

Hence, when the new version comes, you shouldn't do anything. if you want the full DOS.

Secondly, I can't comment on your numbers, please consult somebody with intricate knowledge of your system.

Thanks Nick Papior, that solved my question.