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: 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

32
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


33
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

34
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.

35
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



36
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


37
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









38
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

39
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

40
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

41
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]