Up
| | This is the old documentation.
Here's the link to the new documentation.
global{}
Global settings simulation domain.
global{
database = "../Syntax/database_nnp.in" #
(obsolete) ==> moved to
database{}
Specify simulation dimension:
simulate1D{} # for a 1D simulation
or
simulate2D{} # for a 2D simulation
or
simulate3D{} # for a 3D simulation
Specify orientation of crystal coordinate system
with respect to simulation coordinate system.
For zinc blende materials
there are three-digit Miller indices.
The Miller indices define a plane. There exists a
vector that is perpendicular to this plane, e.g. in zinc blende blende
materials, the [hkl] vector is always perpendicular to the (hkl) plane.
However, for wurtzite, this is not necessarily
true. For instance, although the [0001] vector is perpendicular to the (0001)
plane, in general is does not hold that the vector that is perpendicular to the
(hkil) plane is defined by [hkil].
Note: For a 1D simulation, the heterostructure is
always grown along the x axis.
For a
2D simulation, always the (x,y) plane is used.
Zincblende
crystal_zb{
x_hkl = [1, 0, 0] #
Specify (hkl) plane perpendicular to x axis: The x axis of the simulation
coordinate system is perpendicular to this hkl plane of the crystal (here:
(1 0 0) ).
y_hkl = [0, 1, 0] #
Specify (hkl) plane perpendicular to y axis: The y axis of the simulation
coordinate system is perpendicular to this hkl plane of the crystal (here:
(0 1 0) ).
# The
Miller indices (here: (0 0 1) ) for the z axis are determined automatically.
# For zinc blende it holds: The vector [hkl] is perpendicular to the
(hkl) plane.
or
x_hkl = [3, 1, 1] #
x axis of simulation coordinate system is perpendicular to (3 1 1)
plane of crystal coordinate system, i.e. the x axis is along [311] direction.
y_hkl = [0, -1, 1] #
y axis of simulation coordinate system is perpendicular to (0 -1 1 )
plane of crystal coordinate system, i.e. the y axis is along [0-11] direction.
# The Miller indices (here: [2, -3, -3] )
for the z axis are determined automatically, i.e. (2 -3 -3) plane, i.e. the z
axis is along [311] direction.
}
Wurtzite
Usually for wurtzite, the four-digit
Miller-Bravais indices (h k i l)
are used. We also use this notation but omit the
'i' because i = - h - k .
The three integer values (Miller indices) that
are given for x_hkl refer to a
plane and not to a direction. The x direction is then the one that is perpendicular to this plane.
This vector along the x axis has indices that are in general not identical to
the Miller indices in wurtzite.
crystal_wz{
# e.g. hexagonal [0001] axis along x axis
# Specify (hkil) plane perpendicular to x axis:
x_hkl = [ 0, 0, 1]
# This corresponds to the four-digit Miller-Bravais indices hkil =
( 0, 0, 0, 1)
that define the (hkil)=(0001) plane. Coincidently, the vector [0001] is
pependicular to it.
# Specify (hkil) plane perpendicular to y axis:
y_hkl = [ 1, 0, 0]
# This corresponds to the four-digit Miller-Bravais indices hkil =
( 1, 0, -1, 0)
that define the (hkil)=(10-10) plane.
}
# The Miller-Bravais indices for the (hkil) plane perpendicular to the z
axis are determined automatically inside the code (here: (-1 2 -1 0) ).
or
crystal_wz{
# e.g. (10-10) plane is perpendicular to x axis
x_hkl = [ 1, 0, 0]
# This corresponds to the four-digit Miller-Bravais indices hkil =
( 1, 0, -1, 0)
that define the (hkil)=(10-10) plane. The x axis of the simulation coordinate
system is perpendicular to this plane.
y_hkl = [-1, 2, 0]
# This corresponds to the four-digit Miller-Bravais indices hkil =
(-1, 2, -1, 0)
that define the (hkil)=(-12-10) plane. The y axis of the simulation coordinate
system is perpendicular to this plane.
# The Miller-Bravais indices of the (hkil) plane perpendicular to the z
axis are determined automatically inside the code (here: (0001) ).
Coincidently, the vector [0001] is pependicular to it.
# In this particular case, no rotation has to be applied to the crystal
(rotation matrix = identity matrix).
rotation_c_a_ratio_use_substrate =
yes
# (default: yes ) In wurtzite,
the c/a ratio of the two lattice constants 'c' and 'a' is important.
# The ideal one, c/a=sqrt(8/3)=1.63299..., is not the one present in GaN,
AlN or InN, i.e. in real materials.
# For the rotation of the crystal coordinate system to the simulation
coordinate system, a specific c/a ratio has to be assumed.
# By default, we use the one of the substrate material.
# If you want to use the ideal c/a ratio, you have to specify
rotation_c_a_ratio_use_substrate = no .
rotation_c_a_ratio =
1.63299
# Additionally, you can specify a custom value for the c/a ratio. If no
customized value is specified, rotation_c_a_ratio =
sqrt(8/3) (default).
# The actually used rotation matrix is written to the log file.
}
Exactly two of these three axes have
to be specified, the third one is calculated internally.
x_hkl = [ ., ., .]
#
y_hkl = [ ., ., .]
#
z_hkl = [ ., ., .]
#
Specify substrate (and thus its lattice constant),
i.e. the material on which all layers are grown.
Consequently, all layers are strained with respect to the (unstrained)
substrate.
The substrate is also
necessary to determine the symmetry properties of the k||
integration.
substrate{ # binary
name = "GaAs"
}
or
substrate{ # ternary
name = "Al(x)Ga(1-x)As" #
AlxGa1-xAs
alloy_x = 0.3 #
x = 0.3, i.e. Al0.3Ga0.7As
}
or
substrate{ # quaternary
name =
"Al(x)Ga(y)In(1-x-y)As" #
AlxGayIn1-x-yAs
alloy_x = 0.3 #
x = 0.3, i.e. Al0.3Ga0.1In0.6As
alloy_y = 0.1 #
y = 0.1, i.e. Al0.3Ga0.1In0.6As
}
substrate{ # quinternary
name =
"Al(x)Ga(y)In(1-x-y)Sc(1-x-y-z)N" #
AlxGayInzSc1-x-y-zN
alloy_x = 0.3 #
x = 0.3, i.e. Al0.3Ga0.1In0.55Sc0.05N
alloy_y = 0.1 #
y = 0.1, i.e. Al0.3Ga0.1In0.55Sc0.05N
alloy_z = 0.55 #
z = 0.05, i.e. Al0.3Ga0.1In0.55Sc0.05N
}
Specify simulation temperature:
temperature = 300 # T in Kelvin (here: 300 K), temperature should be larger than 1 µK
(T >= 1e-6 K)
temperature_dependent_bandgap = yes/no
# turns on/off temperature dependence of band gaps (optional, default is yes )
temperature_dependent_lattice = yes/no
#
turns on/off temperature dependence of lattice constants (optional, default is yes )
Note: The band gaps (and thus the conduction band edges) are adjusted
when the temperature changes.
This has the consequence that the conduction band offsets are
temperature dependent whereas
the valence band offsets are not temperature dependent.
Due to Varshni formula a correction is calculated
(if necessary interpolated) which is then added to the (interpolated) band gap. For
instance:
Egap (T > 0 K) = Egap (T =
0 K) + Egap,Varshnicorrection(T)
- alpha[AC] * T^2
- alpha[BC] * T^2
- alpha_bow[ABC] * T^2
Egap,Varshnicorrection[AxB1-xC]
= x -------------------------- + (1-x) -------------------------- - x(1-x)
------------------------------------
T + beta[AC]
T + beta[BC]
T + beta_bow[ABC]
Note: For all nextnano versions older than
2019-04-16, the
periodic{} flag was specified within the
grid{} section and not within the
global{} section.
periodic{
#
(optional)
x = yes/no
#
periodic along x direction (default is
no )
y = yes/no
#
periodic along y direction (default is
no ) (2D or 3D only)
z = yes/no
#
periodic along z direction (default is
no ) (3D only)
}
Note: If the grid is periodic along any of the three
directions, then the Poisson and the strain equations
are solved automatically with periodic boundary
conditions along the appropriate directions.
For the Schrödinger equation periodic boundary conditions
are taken only
if the quantum region extends over the whole
simulation region along the relevant direction.
Objects (e.g. circles, rectangles, ...)
extending over an edge of the simulation region will not automatically be
continued on the opposite side.
Periodic boundaries are not implemented
for magnetic fields.
Specify magnetic field:
magnetic_field{
strength = 5.3
# magnetic flux density B in units of Tesla [T] = [Vs / m2]
direction = [3, 1, 1] # (only 3D) orientation of magnetic field vector with respect to (x,y,z) simulation
coordinate system, here: [311]
# Note: In 2D, the specifier
direction must not be
present because the direction is automatically
# set internally to be perpendicular to
the simulation
plane in 2D, i.e. (x,y) plane => [0, 0, 1] .
# In 1D (Zeeman splitting of
energy levels only), the specifier
direction must not be present because the direction is parallel to the
simulation direction (x).
# Defining magnetic_field{} in the input file results into a different (slower) solver being called.
Thus, omit this section altogether in case no magnetic field is needed.
# Note: The Hall effect for the
drift-diffusion current calculation is not implemented yet.
}
For single-band:
For a normal single-band calculation, all eigenstates are
internally treated to be two-fold spin degenerate (e.g. when calculating the
quantum density).
In contrast, if magnetic_field{} is defined, the
Pauli equation
is solved in all 2D and 3D single-band quantum regions instead of the
single-band Schrödinger equation.
So the states are no longer two-fold spin degenerate (unless the
magnetic field is zero).
Note that even if the magnetic field strength is explicitly set to
zero, still the
Pauli equation
equation is solved in which case both spin eigenfunctions will be calculated
although they have the same energy.
Thus, to maximize speed in the absence of magnetic fields, leave magnetic_field{} undefined.
Then the dimension of the matrix from which the eigenfunctions
are calculated has only half the size (and thus only half of the
eigenfunctions have to be calculated), and it is is real instead of Hermitian.
Currently, the magnetic field is input to the single-band and the
multi-band k.p Hamiltonian but is not input to the drift-diffusion
current equation.
Thus the classical Hall effect is not taken into account.
As the magnetic field modifies the eigenenergies and
probability densities, and thus the quantum density, the current will be
different compared to the zero-field case
because the current is proportional to the density.
}
|