Calculation of interpolated currents at different bias

Asked by Pengfei Ou

Hi,

I would like to double check that I understand the things right. If I want to calculate the current under different bias after I have calculated the SCF solution of a certain system at 5 different applied bias,

1. Firstly run TRANSIESTA by setting TS.Voltage = 0, -0.5, 0.5, -1.0, 1.0 eV respectively. In this step, should I calculate the transmission spectra for each bias?

2. In the run.fdf file, I only need to write the following lines:

SystemName iv_curve
SystemLabel iv_curve

TBT.HS.Interp spline

%block TBT.k
  diag 1 1 101
%endblock

TS.TBT.Emin -2.0 eV
TS.TBT.Emax 2.0 eV
TS.TBT.NPoints 101

%block TBT.HS.Files
../V0/siesta.TSHS 0. eV
../V-0.5/siesta.TSHS -0.5 eV
../V0.5/siesta.TSHS 0.5 eV
../V-1.0/siesta.TSHS -1.0 eV
../V1.0/siesta.TSHS 1.0 eV
%endblock

3. Then, I run the run.fdf by submitting the job

for V in ‘seq -1.5 0.1 1.5‘ ; do
tbtrans -V $V:eV -D V$V RUN.fdf
done

4. Finally, I can get the I-V curves, right?

Thanks for your time.

Question information

Language:
English Edit question
Status:
Answered
For:
Siesta Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Nick Papior (nickpapior) said :
#1

Yes, it looks correct.

Note, when you perform an interpolation of various bias', and one bias is V_tbt = V_ts, then no interpolation is done.
This means that it is quite safe to calculate the current/transmission after you have successfully completed all transiesta runs.

A couple of notes

1) The TBT.k looks like you have transport along the first or the second cell vector? If you have transport along the 3rd lattice vector (as in the old transiesta/tbtrans) then this input is wrong (please see discussions on k-point sampling on the mailing list of siesta.

2) These 3 lines are not read by tbtrans 4.1-b3
TS.TBT.Emin -2.0 eV
TS.TBT.Emax 2.0 eV
TS.TBT.NPoints 101
Please look in the manual for details.

3) Also note that you should pipe the output of the tbtrans runs into separate out-files. If you have compiled tbtrans with NetCDF-4 support then the end of the out-files will contain the current at the given bias.

Revision history for this message
Pengfei Ou (barneycavs) said :
#2

Hi Nick,

Thanks for your answer.

So you suggest me to finish all the transiesta calculations before I calculate the current under different bias which is a safer way.

1) I have transport along the 3rd lattice vector, and I just checked the tbtrans manual, the kpoints of tbt should write this way:
%block TBT.k
1 0 0 0.
0 10 0 0.
0 0 100 0.
%endblock
Note: I am using the transiesta version of 3.2, not the latest version of 4.3.

2) The calculations under zero bias has been done successfully but when it comes to the calculations under finite bias, an error message shows:
ERROR: No. points= 5 not valid for real axis gaussian quadrature, mi
 n 10
ERROR Contour: too few points for real axis int

How can I solve this problem? I searched the mail archive and it seems that this problem can be solved by increase TS.biasContour.NumPoints to 10.

Thanks for your help.

Revision history for this message
Nick Papior (nickpapior) said :
#3

1) No, tbtrans k-points along transport direction should ALWAYS be 1 (however, tbtrans automatically sets it to 1). Note that for electrodes you need a high number of k-points along the semi-infinite direction (transport direction). Please don't confuse the two.

2) The error you see relates o the number you specify for the "Line" part, this is not TS.biasContour.Numpoints, please look in the manual for checking out this.

Also, you are using 3.2 transiesta and tbtrans. Neither of these implement the interpolation scheme, this is only present in the 4.1 release. So basically, you cannot do the interpolation.

Revision history for this message
Pengfei Ou (barneycavs) said :
#4

Hi Nick,

I couldn't find any information in the manual about how to solve the "ERROR: Contour: too few points for real axis int", could you please elaborate this problem more?

Thanks for your help.

Revision history for this message
Nick Papior (nickpapior) said :
#5

I think it is this one:

TS.ComplexContour.NumLine

but check it.

Revision history for this message
Pengfei Ou (barneycavs) said :
#6

Hi Nick,

TS.ComplexContour.NumLine doesn't solve this issue, but it does by increasing the TS.BiasContour.NumPoints to some larger values.
In your powerpoint, the convergence of TranSiesta, it says TS.BiasContour.NumPoints normally equals to V/0.01.

Revision history for this message
Nick Papior (nickpapior) said :
#7

Ok, so you are using 4.0 or 3.2

Yes, I would advice to use N = V/0.01, but you have to set it explicitly, it does not do it automatically in those older versions of transiesta.

Revision history for this message
Pengfei Ou (barneycavs) said :
#8

For now, I use 3.2, because I am trying to compile the Tbtrans 4.1. There is an another error occurred:

libfdf.a(fdf.o): In function `fdf_shutdown':
/gs/project/emm-484-aa/Ou/software/siesta-4.1-b3/Util/TS/TBtrans/../../../Src/fdf/fdf.F90:1704: undefined reference to `__kmpc_global_thread_num'
/gs/project/emm-484-aa/Ou/software/siesta-4.1-b3/Util/TS/TBtrans/../../../Src/fdf/fdf.F90:1704: undefined reference to `__kmpc_single'
/gs/project/emm-484-aa/Ou/software/siesta-4.1-b3/Util/TS/TBtrans/../../../Src/fdf/fdf.F90:1711: undefined reference to `__kmpc_end_single'
/gs/project/emm-484-aa/Ou/software/siesta-4.1-b3/Util/TS/TBtrans/../../../Src/fdf/fdf.F90:1711: undefined reference to `__kmpc_barrier'
libfdf.a(fdf.o): In function `fdf_init':
/gs/project/emm-484-aa/Ou/software/siesta-4.1-b3/Util/TS/TBtrans/../../../Src/fdf/fdf.F90:340: undefined reference to `__kmpc_global_thread_num'
/gs/project/emm-484-aa/Ou/software/siesta-4.1-b3/Util/TS/TBtrans/../../../Src/fdf/fdf.F90:340: undefined reference to `__kmpc_single'
/gs/project/emm-484-aa/Ou/software/siesta-4.1-b3/Util/TS/TBtrans/../../../Src/fdf/fdf.F90:390: undefined reference to `__kmpc_end_single'
/gs/project/emm-484-aa/Ou/software/siesta-4.1-b3/Util/TS/TBtrans/../../../Src/fdf/fdf.F90:390: undefined reference to `__kmpc_barrier'

Revision history for this message
Nick Papior (nickpapior) said :
#9

I would suggest you to start by compiling without OpenMP support.

Revision history for this message
adma (adamdevine78) said :
#10

I am facing error in this code calculation

Can you help with this problem?

Provide an answer of your own, or ask Pengfei Ou for more information if necessary.

To post a message you must log in.