This thread is locked.Only browsing is available.
Top Page > Browsing
Question about PAO cut radii and size of unit cells in NEGF calculation
Date: 2015/04/08 11:45
Name: kzhoulatte

Hi, All,
When I start to do some NEGF calculations for MoS2. I set my input file as below for the band calculation of the leads. But I keep getting errors like: "The length between atomA=1 and atomB=1 is too short for the transport calculation, PAOs of lead atoms can overlap only to the next nearest region." More error details are as below.
The cut radii of my atoms are 7.00 bohr (Mo) / 7.00 (S) bohr from the default PAOs of openMX. My question is what is the distance=12.016567 here coming from? And what is wrong about my settings, what can I do with this situation?

Thanks.


*********************************************************************************

TRAN_Check_Region_Lead()

The length between atomA=1 and atomB=1 is too short for the transport calculation.
distance=12.016567 rcutA=7.000000 rcutB=7.000000


ERROR: PAOs of lead atoms can overlap only to the next nearest region.



TRAN_Check_Region_Lead()

The length between atomA=1 and atomB=1 is too short for the transport calculation.
distance=12.016567 rcutA=7.000000 rcutB=7.000000


ERROR: PAOs of lead atoms can overlap only to the next nearest region.


*****************************************************************************************************

Species.Number 2
<Definition.of.Atomic.Species
Mo Mo7.0-s2p2d1 Mo_PBE13
S S7.0-s2p2d1 S_PBE13
Definition.of.Atomic.Species>

#
# Atoms
#

Atoms.Number 6
Atoms.SpeciesAndCoordinates.Unit Ang # Ang|AU
<Atoms.SpeciesAndCoordinates
1 S 1.605845446 1.871405846 0.000000000 3.0 3.0
2 Mo 3.210443637 0.935701903 1.620681382 7.0 7.0
3 S 4.815041827 1.871405846 0.000000000 3.0 3.0
4 S 8.026732719 0.935701903 1.620681382 3.0 3.0
5 Mo 9.631341007 1.871405846 0.00000000 7.0 7.0
6 S 11.235898807 0.935701903 1.620681382 3.0 3.0
Atoms.SpeciesAndCoordinates>
Atoms.UnitVectors.Unit Ang # Ang|AU
<Atoms.UnitVectors
0.00000 0.000000 3.179447
0.00000 2.753482 -1.589723
13.3761 0.000000 0.0000
Atoms.UnitVectors>

#
# SCF or Electronic System
#

scf.XcType GGA-PBE # LDA|LSDA-CA|LSDA-PW|GGA-PBE
scf.SpinPolarization off # On|Off|NC
scf.ElectronicTemperature 300.0 # default=300 (K)
scf.energycutoff 150.0 # default=150 (Ry)
scf.maxIter 100 # default=40
scf.EigenvalueSolver Band # DC|GDC|Cluster|Band
scf.lapack.dste dstevx # dstegr|dstedc|dstevx, default=dstegr
scf.Kgrid 12 12 1 # means n1 x n2 x n3
scf.Mixing.Type rmm-diisk # Simple|Rmm-Diis|Gr-Pulay|Kerker|Rmm-Diisk
scf.Init.Mixing.Weight 0.010 # default=0.30
scf.Min.Mixing.Weight 0.001 # default=0.001
scf.Max.Mixing.Weight 0.020 # default=0.40
scf.Mixing.History 20 # default=5
scf.Mixing.StartPulay 7 # default=6
scf.criterion 1.0e-8 # default=1.0e-6 (Hartree)
メンテ
Page: [1]

Re: Question about PAO cut radii and size of unit cells in NEGF calculation ( No.1 )
Date: 2015/04/08 22:17
Name: Artem Pulkin  <artem.pulkin@epfl.ch>

Hi,

This distance is a real-space distance between some pair of atoms in your MoS2. It comes from check whether your lead Hamiltonian can be presented in a 'tri-diagonal' form along the transport direction. This is a requirement for NEGF, the details are carefully explained in the documentation.

Since you posted the lead file only I cannot say what is wrong. I guess the major problem here is a non-rectangular unit cell: the first unit cell vector should be perpendicular to others two. As far as I know, it has even more constraints, the unit vectors section should be of following structure:

<Atoms.UnitVectors
0 0 x
x x 0
x x 0
Atoms.UnitVectors>

Artem
メンテ
Re: Question about PAO cut radii and size of unit cells in NEGF calculation ( No.2 )
Date: 2015/04/09 06:41
Name: kzhoulatte

Hi, Artem,
Thanks for your response.
So you mean all unit vectors should be perpendicular to each other, which means rectangular unit cell instead of hexagonal? That seems to be the case for Graphehe in examples.
Thanks
メンテ
Re: Question about PAO cut radii and size of unit cells in NEGF calculation ( No.3 )
Date: 2015/04/09 10:02
Name: kzhoulatte

Hi,
Because according to my calculation, I keep getting transmission very small. But according to the band calculation, or results from Quantum Espresso, I should get 1 there.
My settings and unit vectors are as below which actually seems reasonable to me. So could you help check this?

***************************************************************************************
<Atoms.UnitVectors
13.3761 0.000000 0.000000
0.00000 2.753482 -1.589723
0.00000 0.000000 3.179447

****************************************************************************************
Species.Number 2
<Definition.of.Atomic.Species
Mo Mo7.0-s2p2d1 Mo_PBE13
S S7.0-s2p2d1 S_PBE13
Definition.of.Atomic.Species>
#
# Atoms
#
Atoms.SpeciesAndCoordinates.Unit Ang # Ang|AU

Atoms.Number 6
<Atoms.SpeciesAndCoordinates
1 S 14.981945446 1.871405846 0.000000000 3.0 3.0
2 Mo 16.586543637 0.935701903 1.620681382 7.0 7.0
3 S 18.191141827 1.871405846 0.000000000 3.0 3.0
4 S 21.402832719 0.935701903 1.620681382 3.0 3.0
5 Mo 23.007441007 1.871405846 0.000000000 7.0 7.0
6 S 24.611998807 0.935701903 1.620681382 3.0 3.0
Atoms.SpeciesAndCoordinates>
#
# Lead-Left
#

LeftLeadAtoms.Number 6
<LeftLeadAtoms.SpeciesAndCoordinates # Unit=Ang.
1 S 1.605845446 1.871405846 0.000000000 3.0 3.0
2 Mo 3.210443637 0.935701903 1.620681382 7.0 7.0
3 S 4.815041827 1.871405846 0.000000000 3.0 3.0
4 S 8.026732719 0.935701903 1.620681382 3.0 3.0
5 Mo 9.631341007 1.871405846 0.000000000 7.0 7.0
6 S 11.235898807 0.935701903 1.620681382 3.0 3.0
LeftLeadAtoms.SpeciesAndCoordinates>

#
# Lead-Right
#

RightLeadAtoms.Number 6
<RightLeadAtoms.SpeciesAndCoordinates # Unit=Ang.
1 S 28.358045446 1.871405846 0.000000000 3.0 3.0
2 Mo 29.962643637 0.935701903 1.620681382 7.0 7.0
3 S 31.567241827 1.871405846 0.000000000 3.0 3.0
4 S 34.778932719 0.935701903 1.620681382 3.0 3.0
5 Mo 36.383541007 1.871405846 0.000000000 7.0 7.0
6 S 37.988098807 0.935701903 1.620681382 3.0 3.0


******************************************************************************************

191 6.611185e-02 3.674932e-03 1.798995e+00 1.000000e-01 1.008135e-06 1.917254e-15 1.008135e-06 1.917254e-15
192 6.703520e-02 3.674932e-03 1.824121e+00 1.000000e-01 2.573112e-06 5.798829e-15 2.573112e-06 5.798829e-15
193 6.795855e-02 3.674932e-03 1.849246e+00 1.000000e-01 5.704673e-06 1.574807e-14 5.704673e-06 1.574807e-14
194 6.888190e-02 3.674932e-03 1.874372e+00 1.000000e-01 1.001803e-05 3.501744e-14 1.001803e-05 3.501744e-14
195 6.980525e-02 3.674932e-03 1.899497e+00 1.000000e-01 1.338625e-05 6.021006e-14 1.338625e-05 6.021006e-14
196 7.072860e-02 3.674932e-03 1.924623e+00 1.000000e-01 1.390333e-05 7.820488e-14 1.390333e-05 7.820488e-14
197 7.165195e-02 3.674932e-03 1.949749e+00 1.000000e-01 1.269368e-05 7.764132e-14 1.269368e-05 7.764132e-14
198 7.257530e-02 3.674932e-03 1.974874e+00 1.000000e-01 1.208143e-05 6.059785e-14 1.208143e-05 6.059785e-14
199 7.349865e-02 3.674932e-03 2.000000e+00 1.000000e-01 1.155767e-05 3.717362e-14 1.155767e-05 3.717362e-14


Thanks
メンテ
Re: Question about PAO cut radii and size of unit cells in NEGF calculation ( No.4 )
Date: 2015/04/09 22:42
Name: Artem Pulkin  <artem.pulkin@epfl.ch>

Yes, you should use rectangular unit cell for in-plane transport in MoS2. Regarding your transmission, you still did not post the full scattering region input file. In any case I am sure by 99% that

- either you miss energy (some Fermi level misalignment)
- or you miss k-point (calculate at Gamma instead of full Brillouin zone)
- or you did not converge your NEGF

The transmission code in OpenMX worked well to my knowledge.
メンテ
Re: Question about PAO cut radii and size of unit cells in NEGF calculation ( No.5 )
Date: 2015/04/10 08:15
Name: kzhoulatte

Hi, Artem,
Thanks for response.
I see what you mean. I attach my input file here. (This is one for vertical transport through bulk MoS2 with gate voltage calculation, instead of bias).
And maybe my statements were not clear. What now confuses me is: the Total transmission vs Energy relation seems reasonable when I plot Sum of T(k) vs E, but I think from Bands, you can see for each K points, your Trans(k) for single K point vs E should be 1 when you have DOS at that energy, right? And that is what I got from Quantum Espresso.
But from OpenMX, I got 2E-1, 3E-2 etc which are smaller than 1. I think probably you have some constants related to the K-point choice with the final Trans for each K. Or maybe it comes from your "gate voltage method" etc?
So I am confused how OpenMX determine the K points and that constant.

Thanks!

***********************************************************************************************
Input file for step1:

NEGF.output_hks on
NEGF.filename.hks lead-chain.hks
NEGF.Output.for.TranMain on

NEGF.tran.energydiv 200 # default=200
NEGF.tran.energyrange -3 2 1.0e-1 # default=-10.0 10.0 5.0e-3 (eV)
NEGF.tran.Kgrid 3 3 # default= 1 1

# Definition of Atomic Species
#

Species.Number 2
<Definition.of.Atomic.Species
Mo Mo7.0-s2p2d1 Mo_PBE13
S S7.0-s2p2d1 S_PBE13
Definition.of.Atomic.Species>

#
# Atoms
#

Atoms.Number 6
Atoms.SpeciesAndCoordinates.Unit Ang # Ang|AU
<Atoms.SpeciesAndCoordinates
1 S 0.000000 1.871405846 1.605845446 3.0 3.0
2 Mo 1.620681382 0.935701903 3.210443637 7.0 7.0
3 S 0.00000000 1.871405846 4.815041827 3.0 3.0
4 S 1.620681382 0.935701903 8.026732719 3.0 3.0
5 Mo 0.0000000 1.871405846 9.631341007 7.0 7.0
6 S 1.620681382 0.935701903 11.235898807 3.0 3.0
Atoms.SpeciesAndCoordinates>
Atoms.UnitVectors.Unit Ang # Ang|AU
<Atoms.UnitVectors
0.000000 0.000000 13.3761
-1.589723 2.753482 0.00000
3.179447 0.00000 0.00000
Atoms.UnitVectors>

#
# SCF or Electronic System
scf.XcType GGA-PBE # LDA|LSDA-CA|LSDA-PW|GGA-PBE
scf.SpinPolarization off # On|Off|NC
scf.ElectronicTemperature 300.0 # default=300 (K)
scf.energycutoff 150.0 # default=150 (Ry)
scf.maxIter 100 # default=40
scf.EigenvalueSolver Band # DC|GDC|Cluster|Band
scf.lapack.dste dstevx # dstegr|dstedc|dstevx, default=dstegr
scf.Kgrid 2 12 12 # means n1 x n2 x n3
scf.Mixing.Type rmm-diisk # Simple|Rmm-Diis|Gr-Pulay|Kerker|Rmm-Diisk
scf.Init.Mixing.Weight 0.010 # default=0.30
scf.Min.Mixing.Weight 0.001 # default=0.001
scf.Max.Mixing.Weight 0.020 # default=0.40
scf.Mixing.History 20 # default=5
scf.Mixing.StartPulay 7 # default=6
scf.criterion 1.0e-8 # default=1.0e-6 (Hartree)

#
# MD or Geometry Optimization
#

MD.Type Nomd # Opt|EF|BFGS|RF|DIIS
MD.Opt.DIIS.History 6 # default=3
MD.Opt.StartDIIS 7 # default=5
MD.Opt.EveryDIIS 6 # default=10
MD.maxIter 200 #
MD.Opt.criterion 1.0e-4 # default=1.0e-4 (a.u.)


***********************************************************************************************
For TranMain

NEGF.filename.hks.l lead-chain.hks
NEGF.filename.hks.r lead-chain.hks

NEGF.Num.Poles 150 # default=150
NEGF.scf.Kgrid 3 3 # default=1 1
NEGF.SCF.Iter.Band 10

NEGF.bias.voltage 0.0 # default=0.0 (eV)
NEGF.bias.neq.im.energy 0.01 # default=0.01 (eV)
NEGF.bias.neq.energy.step 0.02 # default=0.02 (eV)

Dos.fileout on # on|off, default=off
NEGF.Dos.energyrange -3.0 2.0 5.0e-1 #default=-10.0 10.0 5.0e-3 (eV)
NEGF.Dos.energy.div 200 # default=200
NEGF.Dos.Kgrid 3 3 # default=1 1

NEGF.tran.energydiv 200 # default=200
NEGF.tran.energyrange -3 2 1.0e-1 # default=-10.0 10.0 1.0e-3 (eV)
NEGF.tran.Kgrid 3 3 # default= 1 1

#
# Definition of Atomic Species
#

Species.Number 2
<Definition.of.Atomic.Species
Mo Mo7.0-s2p2d1 Mo_PBE13
S S7.0-s2p2d1 S_PBE13
Definition.of.Atomic.Species>

#
# Atoms
#

Atoms.SpeciesAndCoordinates.Unit Ang # Ang|AU

Atoms.Number 6
<Atoms.SpeciesAndCoordinates
1 S 0.000000 1.871405846 14.981945446 3.0 3.0
2 Mo 1.620681382 0.935701903 16.586543637 7.0 7.0
3 S 0.000000 1.871405846 18.191141827 3.0 3.0
4 S 1.620681382 0.935701903 21.402832719 3.0 3.0
5 Mo 0.000000 1.871405846 23.007441007 7.0 7.0
6 S 1.620681382 0.935701903 24.611998807 3.0 3.0
Atoms.SpeciesAndCoordinates>
#
# Lead-Left
#

RightLeadAtoms.Number 6
<RightLeadAtoms.SpeciesAndCoordinates # Unit=Ang.
1 S 0.00000000 1.871405846 28.358045446 3.0 3.0
2 Mo 1.620681382 0.935701903 29.962643637 7.0 7.0
3 S 0.000000000 1.871405846 31.567241827 3.0 3.0
4 S 1.620681382 0.935701903 34.778932719 3.0 3.0
5 Mo 0.000000000 1.871405846 36.383541007 7.0 7.0
6 S 1.620681382 0.935701903 37.988098807 3.0 3.0
RightLeadAtoms.SpeciesAndCoordinates>

#
# SCF or Electronic System
#

scf.XcType GGA-PBE # LDA|LSDA-CA|LSDA-PW|GGA-PBE
scf.SpinPolarization off # On|Off|NC
scf.ElectronicTemperature 300.0 # default=300 (K)
scf.energycutoff 150.0 # default=150 (Ry)
scf.maxIter 100 # default=40
scf.EigenvalueSolver NEGF # DC|GDC|Cluster|Band
scf.lapack.dste dstevx # dstegr|dstedc|dstevx, default=dstegr
scf.Kgrid 12 12 6 # means n1 x n2 x n3
scf.Mixing.Type rmm-diisk # Simple|Rmm-Diis|Gr-Pulay|Kerker|Rmm-Diisk
scf.Init.Mixing.Weight 0.020 # default=0.30
scf.Min.Mixing.Weight 0.020 # default=0.001
scf.Max.Mixing.Weight 0.100 # default=0.40
scf.Mixing.History 20 # default=5
scf.Mixing.StartPulay 10 # default=6
scf.Kerker.factor 1.0 # default=1.0
scf.criterion 1.0e-8 # default=1.0e-6 (Hartree)

メンテ
Re: Question about PAO cut radii and size of unit cells in NEGF calculation ( No.6 )
Date: 2015/04/10 19:01
Name: Artem Pulkin  <artem.pulkin@epfl.ch>

"Trans(k) for single K point vs E should be 1 when you have DOS at that energy, right?"

No. First of all, T(k) can be any non-negative integer in ballistic conductor. Second, at the same energy transmission differs when going from one K point to another. I.e. T(E,k1) can be zero while T(E,k2) can be unity.

DoS is a quantity integrated over the Brillouin zone while T obviously depends on K. In the simplest case you have to integrate T(K) over Brillouin zone to compare those.

"the Total transmission vs Energy relation seems reasonable when I plot Sum of T(k) vs E"

Of course, sum of transmissions makes no sense: you should INTEGRATE it, i.e. int(T(k)*dk). The differential dk is probably what you mean by a 'constant'.

To summarize, non-zero DoS guarantees that you have some state at that energy. But it does not guarantee that you have such a state for every possible k_parallel. For some k_parallel you have no incoming/outgoing modes and there is nothing to transmit, i.e. transmission is zero.

Regarding QE, I cannot really judge what and why you obtained. It may be that you just misinterpreted the results. Also note that (at least in 2013) pwcond worked properly only with metals.

Artem
メンテ
Re: Question about PAO cut radii and size of unit cells in NEGF calculation ( No.7 )
Date: 2015/04/11 04:17
Name: kzhoulatte

Hi,
I see. My words were not clear. By DOS, actually I was going to say a (E,K) state. And I thought the k mesh is uniform, and I was assuming there is a dk as a constant already included in the results. Thus I thought I could Sum them.
Thanks for your detailed response!


メンテ
Re: Question about PAO cut radii and size of unit cells in NEGF calculation ( No.8 )
Date: 2015/04/11 06:35
Name: kzhoulatte

Hi, Artem,
Thanks. Your response makes NEGF in OpenMX clear to me.
I would like to ask: could I explicitly control the k grid I want to calculate transmission like (kx ky kz), instead of specifying a NEGF.tran.Kgrid? So I can decide to calculate transmission for maybe only an irreducible first BZ.

Thanks.
メンテ
Re: Question about PAO cut radii and size of unit cells in NEGF calculation ( No.9 )
Date: 2015/04/13 20:53
Name: Artem Pulkin  <artem.pulkin@epfl.ch>

'could I explicitly control the k grid I want to calculate transmission like (kx ky kz), instead of specifying a NEGF.tran.Kgrid?'

I am not aware of such option. It is easy to implement it, though. In file TranMain.c the following line

printf(" myid0=%2d i2=%2d i3=%2d k2=%8.4f k3=%8.4f\n",myid0,i2,i3,k2,k3);

prints both k2 and k3. As a one-time solution you may change k2 and k3 to whatever right before this line.

Artem
メンテ
Re: Question about PAO cut radii and size of unit cells in NEGF calculation ( No.10 )
Date: 2015/04/14 04:31
Name: kzhoulatte

Hi, Artem,
I mean could I control the k grid which I want to calculate the transmission instead of calculating for the whole k*k mesh so I can save the time for the calculation? Because my task will be really time consuming.
And I know openMX is good at parallelization. But using symmetry of BZ, I think I could save more time by controlling the k grids. That is what I did for pwcond.x.

Thanks.
メンテ

Page: [1]