Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Petr Khomyakov

Pages: 1 ... 84 85 [86]
1276
In 'Iteration control parameters', you may increase 'Maximum steps' from 100 to whatever you think is reasonable, e.g., 200.
However, it might also be that your computational settings are not appropriate, e.g., the number of k-points, electron temperature or some other setting. This may cause an instability of the self-consistent calculation. In this case, you should identify which of the computational settings (parameters) are responsible for the slow convergence.

1277
There is no really short answer to your questions. You may however find them as well as answer to other potential questions on quantum transport if you read, for example, the following two papers: http://journals.aps.org/prb/abstract/10.1103/PhysRevB.72.035450 and http://journals.aps.org/prb/abstract/10.1103/PhysRevB.70.195402
There are many other publications on the topic; these two are just my favorite.

1278
The  manual on TransmissionEigenstate does not say that "the transmission eigenstates are linear combinations of Bloch states of the electrodes".

In the manual section you refer to, it is said that "t_{nk} is the transmission amplitude from Bloch state \psi_n in the left electrode to Bloch state \psi_k in the right electrode.
 ...
The transmission eigenstates are obtained by propagating the linear combination of the Bloch states".

It means that the transmission eigenstates are the linear combination of the Bloch states in the semi-infinite electrodes, not the central region. The corresponding electron wave function given by this linear combination of the Bloch states is then effectively matched to the electron wave function in the central region by propagation through the central region.

A good textbook example is the electron scattering on a square barrier potential, where the wave function in the electrodes is a linear combination of an incoming and reflected Bloch state of the electron, which are just two plane waves in this case indeed. The under barrier wave function is a simple decaying function that has to be matched to the wave function in the electrodes.

You may solve the same problem without explicit wave-function matching, e.g., by propagation of the corresponding states of the electrodes through the central region. And this is what is described in Jeremy's thesis as well as in most dissertations on quantum transport.

 

1279
General Questions and Answers / Re: fermi level problem
« on: May 12, 2016, 14:52 »
I have looked at your files. As a general suggestion, you may want decreasing the tolerance parameter for the total energy from 10^-4 to 10^-7 Hartree. In addition, increasing the number of k-points might also be helpful, and try using an odd k-point grid, e.g., 31x31x31, to shift the mesh to the Gamma point as that is usually considered as a good choice for cubic and hexagonal crystal structures.

1280
One should increase the number of k-points to see how the physical quantity of interest (e.g., optical spectrum) changes upon increasing the k-mesh density. Note that one needs to substantially increase the density, e.g., not just using 5x5x5 instead of 4x4x4. Otherwise, you may not see much of a difference.

This kind of convergence tests are usually done for several different meshes. "Substantially" and the amount of testing effort are vaguely-defined things indeed, but this is where one needs to experiment to get reliable computational results within the tolerance you think is good enough for the problem of your study.

A good initial guess for k-point sampling usually comes with experience in doing calculations for different physical systems and quantities.  The convergence speed with respect to k-point sampling can differ significantly for different physical quantities as well as physical systems (e.g., metals vs semiconductors). 

1281
I would guess that the number of k-grid points needed for calculating the optical spectra are to be at least comparable to that typically used for DOS calculations. As a general rule, the actual k-grid for any type of calculations has to be chosen based on a convergence test for a specific physical quantity of interest.

1282
General Questions and Answers / Re: mobility calculation
« on: May 10, 2016, 00:59 »
For mobility calculation, you may do a classical molecular dynamics (MD) simulation for 'DeviceConfiguration', see http://docs.quantumwise.com/tutorials/md_basics.html, combined with conductance calculations.  In your case, Device Configuration is a silicon nanowire with a given length attached to the left and right electrodes, which can be designed as semi-infinite silicon nanowires to avoid a contact resistance issue as it would be the case for metal electrodes.

The actual purpose of the classical MD simulation is to use its trajectory to calculate the conductance for a set of frames along the trajectory.  Each frame corresponds to a certain atom arrangement in the finite-length nanowire, which is a central region in the Device Configuration described in the previous paragraph.

The mobility or conductivity of an infinite silicon nanowire can then be related to the finite-length nanowire conductance averaged over the trajectory frames selected. Assuming that the nanowire length in the device central region is more than the electron mean free path, the conductivity can be defined as the trajectory-averaged conductance multiplied by the nanowire length. If the nanowire diameter is large enough to neglect a surface effect, the conductance can be divided by the nanowire diameter to get a bulk-like conductivity.  To reach the actual bulk limit, the nanowire diameter should exceed the mean free path indeed.

The mobility can be related to the trajectory-averaged conductivity as discussed in the theory section of the tutorial on 'Mobility', http://docs.quantumwise.com/tutorials/mobility.html.

The theoretical grounds for the described procedure are based on the fact that electron dynamics is much faster than that of ions, i.e., the electrons go through the nanowire faster than ions change their positions, so that the electrons "see" a static lattice of ions at the time scale of electron dynamics. The described approach does not require explicit calculation of the electron-phonon coupling. Note that It accounts for the elastic electron-phonon scattering only. This is perhaps good enough for silicon since it is not a polar semiconductor, i.e., it does not have polar optical phonon modes like in III-V semiconductors.

To avoid direct MD simulations, one may also follow the procedure described in http://journals.aps.org/prb/abstract/10.1103/PhysRevB.91.220405 and applied to metals, but this approach is limited to harmonic approximation, and would also require an additional effort to be interfaced with ATK, unlike the MD simulator that is already a part of ATK.


1283
In the INCAR file, you should also set LORBIT, for example, to 12, see http://cms.mpi.univie.ac.at/vasp/vasp/LORBIT.html for all the options.

1284
It really depends on what you mean by 'accurate'. If you want the accuracy given by the tolerance you have set for that calculation, it is not accurate yet, and you then need to do more iterations to achieve the accuracy required.

On the other hand, it might be that the accuracy of physical quantities of interest is already sufficient for making reliable conclusions on the problem of your study. It is only up to you to decide on it.

The warning is only to tell you that the tolerance criteria required by you is not achieved in a given number of iterations, but it might be that this setting is too strict or there is a convergence problem.  In both cases, you may try increasing the maximum number of iterations to see how the total energy of your system converges with respect to the iteration number.

1285
Take a look at these two tutorials for how to analyze the VASP calculated band structure and calculate an electron effective mass in VNL, http://quantumwise.com/publications/tutorials/item/523-set-up-and-analyze-vasp-calculations-with-vnl and http://docs.quantumwise.com/tutorials/effective_mass.html?highlight=effective%20mass.

Regarding mobility, I guess knowing just the band structure is not sufficient for calculating electron mobility.

1286
You should configure the VASP scripter as described in http://quantumwise.com/documents/tutorials/latest/VASPScripter/index.html/chap.setup.html. The POTCAR pseudopotential files for O and Sn are to be in the corresponding pseudopotential directories, e.g., in C:\Users\Asus\potpaw (default directory) for LDA-PAW calculations you intend to do, or any other directory, but the paths are then to be changed in the VASP Scripter accordingly. The POTCAR files as well as the entire VASP package are provided by the VASP distributor in Vienna, https://www.vasp.at/, not by QuantumWise.

1287
The POSCAR_after (generated presumably with an older plugin) enclosed in the original post has correct atom position coordinates, which are identical to that in the POSCAR_before file as it should be in the 'Direct' (lattice vectors) coordinate system, no matter how it is rotated. This might still have been an issue if the original coordinates were given in 'Cartesian'. So, using a bug-free plugin (1.15) is the best option to avoid any import-export issues indeed.   :)
VASP convergence problem is another issue, which I believe has nothing to do with the VASP plugin in VNL, at least in this particular case.

1288
Hi Mark,

I have imported your POSCAR_before into VNL, and then exported the corresponding structure to POSCAR. VNL does export it in the original format. So, this is a plugin version issue indeed. I assume that you did not manually change the lattice type from 'Unit Cell' to 'Hexagonal' in 'Lattice Parameters' after importing POSCAR_before. This is when VNL would convert it in accordance with its internal convention for a hexagonal lattice.

For your information, VASP should work without any problem for the hexagonal lattice vectors as defined in POSCAR_after, at least according to my experience. In fact, this definition is considered as conventional for hexagonal lattices, see Setyawan&Curtarolo, Computational Materials Science 49 (2010) 299–312.

Regards,
Petr

1289
I did a test for a hexagonal lattice by straining a graphite lattice, using 'Stretch Cell', and then exported the strained graphite structure to POSCAR. It worked for me. The strained lattice vectors in POSCAR are exactly as they were in VNL for the unit cell stretched. The lattice symmetry retains only if one deforms the lattice unit cell in a very specific way, e.g., by applying hydrostatic stress.

I guess stretching of the lattice vectors does not allow applying an arbitrary deformation to the crystal structure. You may, however, re-define the lattice parameters explicitly in Bulk Tools -> Lattice Parameters to model any strain configuration of the crystal structure.   

Regarding the k-lines in KPOINTS, one may use the k-point coordinates (given in a Cartesian coordinate system) as defined for the Brilloiun zone (BZ) of the pristine lattice. This allows using the corresponding KPOINTS file for the pristine crystal structure, BUT the k-points are to be given in 'Cartesian', i.e., not in 'Direct'. I guess, at the end you want to see the effect of strain on the band energies at the symmetry k-points of the original, pristine material.

Otherwise, one has to specify the k-lines in KPOINTS manually since the choice depends on what you actually want to get from the band stricture calculations of the strained material.
 

1290
Hi Mark,

VNL has not changed your unit cell, i.e., it is still hexagonal. The lattice vectors are also exactly the same as you defined them originally. In the POSCAR_after, VNL has just rotated the original Cartesian coordinate system about the c-axis. Since the atom positions are given with respect to the lattice vectors (i.e., in 'Direct'), this rotation had no effect on the atom coordinates given in the POSCAR file.

Note that you may also see this rotation as a rotation of the whole lattice and its lattice vectors (defined in POSCAR_before) about the c-axis.

Regards,
Petr

Pages: 1 ... 84 85 [86]