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 - Troels-Markussen

Pages: 1 2 [3]
31
General Questions and Answers / Re: mobility_error
« on: July 9, 2020, 14:14 »
Hi,

This looks strange and should not happen. How many processes did you run with?  I was unable to reproduce the error, with a slightly modified script. Perhaps try to run with fewer processes. Also, I noticed that your k-point sampling for the ElectronPhononCoupling is around the Gamma-point (ka_range=[-0.1, 0.1], kb_range=[-0.1, 0.1]), while I guess you would rather have it around the K-point, i.e.

Code
kpoints = RegularKpointGrid(
    ka_range=[0.23, 0.43],
    kb_range=[0.23, 0.43],
    kc_range=[0.0, 0.0],
    na=20,
    nb=20,
    nc=1,
    )

Regards,
Troels

32
Hi,

Currently the ZT is only shown in the table if both the phonon transmission and electron transmission spectra are available. However, the ZT which is shown in the plot is calculated from the usual formula ZT=G*S^2*T/k_tot,
where k_tot = k_el + k_ph. In the case where the phonon transmission spectrum is not calculated, the phonon thermal conductance, k_ph, is just set to zero.

Notice that often k_ph > k_el, which means that the ZT calculated without the phonon contribution is way too large. However, the values in the plot of ZT are fine, given that you are aware of the overestimation of ZT. In scientific papers, this quantity if sometimes denoted ZT_el, highlighting that it is calculated only from the electronic transmission. The "real" ZT is the ZT  = ZT_el * k_el / (k_el + k_ph).

Regards,
Troels

33
You can (and should) run the calculation of the DynamicalMatrix in parallel. This is the most expensive part of the calculation. When the DynamicalMatrix is calculated, you run a different script in serial to do the phonon transmission. The phonon transmission calculation can easily be done in serial for 144 atoms.

Regarding device optimization: If you simply repeat the unit cell and don't introduce defects, if should not be necessary to relax the device configuration.

Concerning the K-point sampling, this will depend on the system and in general convergence  with respect to number of K-points should be checked. But usually the default values in QuantumATK are good.


34
General Questions and Answers / Re: Semi-emprical methods
« on: July 7, 2020, 09:33 »
Hi,

If you are interested in Mobility calculations for the present system containing C, Al, S, and P atoms, I think you need to use an LCAOCalculator instead. Currently, we don't support HamiltonianDerivatices for Extended Huckel and we also miss the pair potentials needed to calculate Forces (for the DynamicalMatrix).

Regards,
Troels

35
General Questions and Answers / Re: print data of fatband
« on: July 3, 2020, 16:17 »
Hi,

Once you have a FatBandstructure object, you can get the projection weights as

Code
weights = fat_bandstructure.weights()

This will return a matrix of dimention (n_projections, n_kpoints, n_bands).

See also https://docs.quantumatk.com/manual/Types/FatBandstructure/FatBandstructure.html

Regards,
Troels


36
Hi,

This is probably caused by a bug that we have only recently fixed, which can cause the phonon transmission to hang, when running parallel calculations. Try to run the phonon transmission calculation in serial instead. This issue is solved in the upcoming 2020.09 version.

Regards,
Troels

37
Hi,

The calculations can be run with something like

Code
ProjectOnShellsByElementAndSpin = ProjectionGenerator(atoms=ElementsProjection, l_quantum_numbers=True, spin=UpDownProjection)

projected_density_of_states = ProjectedDensityOfStates(
    configuration=bulk_configuration,
    kpoints=kpoint_grid,
    projections=ProjectOnShellsByElementAndSpin,
    energies=numpy.linspace(-10, 4, 1000)*eV,
    energy_zero_parameter=FermiLevel,
    bands_above_fermi_level=All,
    spectrum_method=TetrahedronMethod,
)

where I defined a new projection generator to project on elements, shells (s, p, d, etc.) and spin up/down.

Regarding the plotting, it will definitely be possible with the upcoming 2020.09 release. There you can rather easily customize plot to e.g. flip the sign of a given curve (in this case the spin-down component). For now, you might need to make the plots yourself by getting each individual pdos using p_xx = projected_density_of_states.evaluate(projection_index=xx), where xx is the index of the specific projection. And the plot the results using pylab or matplotlib.

38
Hi,

You need to use the ProjectedDensityOfStates analysis object.
When you in the ProjectedDensityOfStates select projections to be  "Elements and Orbitals" you will get the individual contribution from each orbital. In the case of the p-shell you will get three curves (p_x, p_y, p_z).

Regards,
Troels



39
Hi,
I think the problem is in your python script:

Code
# Add external potential
external_potential = AtomicCompensationCharge([
    ('doping_0', 0.0168772635404),
    ('doping_1', 1.66714432533e+98)
    ])

Clearly, something is wrong for the 'doping_1' value.

Regards,
Troels


40
Hi,

The initial state energy range depends on your system and what you want to study. If your system is a metal, you are usually interested in an energy range around the Fermi level, so e.g. [-0.1, 0.1]*eV. If your system is a semi-conductor, you will usually want to study energies around the conduction band minimum (CBM) or the valence band maximum (VBM).

I suggest that you first do a Bandstructure calculation or a DensityOfStates calculation of your system and determine the relevant energies. Once you have determined the relevant energy range, you can use that in the ElectronPhononCoupling object. And then you will also need to increase the k-point sampling (kpoints_fractional) in ElectronPhononCoupling, such that you cover the energy range. For a semi-conductor, it can often be advantageous to use a RegularKpointGrid covering only the k-points around the CBM or VBM, if these are located around a single valley.

In your case, the CBM is located around the M point (0.5, 0.5, 0) and if you want to study the electron mobility I would then suggest a RegularKpointGrid of e.g.

Code
kpoints= RegularKpointGrid(
   ka_range=[0.45, 0.55],
   kb_range=[0.45, 0.55],
   kc_range=[0.0, 0.0],
   na=7,
   nb=7,
   nc=1,
)

and then set the initial_state_energy_range=[0.93,0.96]*eV.

The next you should determine is the qpoints. If you want to study both intra-valley and inter-valey scattering it might be best to use a MonkhorstPackGrid with a fine sampling, something like MonkhorstPackGrid(na=100, nb=100, nc=1). However, you can also focus on the intra-valley scattering taking place only around the M point. In this case I would suggest to start with

Code
qpoints= RegularKpointGrid(
   ka_range=[-0.1, 0.1],
   kb_range=[0.1, 0.1],
   kc_range=[0.0, 0.0],
   na=11,
   nb=11,
   nc=1,
)

You need to check your results for convergence wrt. both the k- and q-point ranges as well as the number of k-and q-points.
 
Regards,
Troels









41
Hi,

I think this is what you want:

Code
ProjectOnOrbitalsAndSpin = ProjectionGenerator(
    spin=UpDownProjection, l_quantum_numbers=True, m_quantum_numbers=True)

fat_bandstructure = FatBandstructure(
    configuration=bulk_configuration,
    route=['G', 'X', 'W', 'L', 'G', 'K', 'X', 'U', 'W', 'K', 'L'],
    points_per_segment=20,
    bands_above_fermi_level=All,
    projections=ProjectOnOrbitalsAndSpin
)

Regards,
Troels

42
Right. I'm not surprised that you get good agreement for pristine graphene. This is an 'easy' case for Huckel since there is only a single element. When you add dopant (nitrogen) atoms the interactions becomes more complicated and the Huckel parameters are probably not optimized for this situation. DFT is more transferable and probably gives a better description of the doped graphene.

Regards,
Troels

43
Hi,

There has unfortunately been a bug in the way QuantumATK calculated the transmission for a bulk configuration, which in some case could lead to wrong transmission values. This was solved in the 2019.12 version.
1) Concerning the comparison between DFT and extented Hückel, you cannot in general expect to get the same results. In the attached scripts, the device is calculated with Hückel, while the bulk configuration with DFT. Usually this will give different results, at least quantitatively different. There might be qualitative agreement. The use of force fields for the phonons is usually fine.
2) Yes, the electrode size can matter, also for a perfect device. You can use the "Electrode Validator" to the right of the LabFloor to validate if a certain bulk configuration is a valid electrode.

Regards,
Troels

44
Hi,

It is currently not possible in QuantumATK to calculate the phonon linewidth due to anharmonic phonon-phonon interactions as  done here http://ollehellman.github.io/page/workflows/minimal_example_1.html .

In principle you can calculate the electron linewidth due to electron-phonon coupling.  It will require some scripting by yourself, but we might make an actual implementation next year.

The way to do it would be something like:

Code
# Calculate electron-phonon coupling.
# This requires a HamiltonianDerivatives and a DynamicalMatrix object.
# Also, specify the k-points at which to calculate the broadening.
# Manually specify the bands to consider (speed up computation time).

electron_phonon_coupling = ElectronPhononCoupling(
    hamiltonian_derivatives,
    dynamical_matrix,
    kpoints_fractional=kpoint,
    qpoints_fractional=MonkhorstPackGrid(30,30,30),
    electron_bands=[3, 4, 5],
    energy_tolerance=1.0*eV,
    initial_state_energy_range=[-100, 100]*eV,
    )

# Calculate the inverse life-time (broadening)
inverse_life_time = electron_phonon_coupling.inverseLifeTime()

The calculated inverse life time corresponds to the linewidth calculated with the EPW code.

Regards,
Troels

Pages: 1 2 [3]