xamberl / dft-ramo

DFT-raMO and tools to support DFT-raMO, a Wannier-type analysis.

DFT-raMO

DFT-raMO, a Wannier-type analysis, and its supporting tools.

The original DFT-raMO (written in MATLAB)

The current version of DFT-raMO is a MATLAB script which can be run in the terminal. You'll need a MATLAB installation in order to run it.

DFTraMO.jl

A Julia package that performs the same DFT-raMO analysis, but with support for parallelization. The results from this package are higher in quality than the original MATLAB code, and it has support for both abinit and VASP inputs. Runs are specified through YAML files (an example is provided).

This package also contains Psphere analysis, a tool to determine the degree of localization for reconstructed orbitals.

Installation

This package is not currently registered in the Julia package registry, so you'll need to add the package by the URL directly:

(v1.8+ pkg)> add https://github.com/xamberl/DFT-raMO#main

The #main portion is optional, and can be changed to track a different branch.

dft-ramo's Issues

Electrum now uses Hartree atomic units

This is critically important to consider. By default, the VASP files have their units converted from angstroms/eV to Hartree atomic units, and writing VASP outputs respects the unit convention - but internally, there may be constants that are unit-dependent. Hopefully, the switchover will actually reduce the number of irrational constants needed in the code.

Relevant issue and pull request in Electrum.

You can import Electrum.HARTREE2EV, Electrum.EV2HARTREE, Electrum.ANGSTROM2BOHR, and Electrum.BOHR2ANGSTROM if you need conversion factors in the code.

Refactoring `raMO_to_density()`

The way this function is currently written seems ripe for simplification. I'm opening this issue to remind myself to refactor it.

Support for non-diagonal k-point meshes

Currently, a lot of the code assumes that the k-point mesh is represented by a diagonal matrix, but in reality, the k-point mesh is actually a matrix which may have off-diagonal components. It can be advantageous to use those in some contexts (for example, unit cells that are not orthorhombic), so I'm opening this issue to see if we can treat k-point meshes more rigorously.

Option to print raMO xsfs with finer grid

Currently, the size of the electron density grid is based off the range of planewaves and supercell/k-point mesh, i.e. for a system with planewave indices that range from (-10:10, -10:10, -10:10,) and a supercell size of 2*2*2, we will have an electron density grid of 42*42*42. (In the xsf file, this is 43*43*43 due to periodicity.)

Ideally, we should have a function that reads a binary .raMO file and can print out a finer, user-specified electron density grid. However, .raMO files only contain the coefficients of the raMO function and lack information about the system's geometry. A function should be written such that it reads in the .raMO and other system information (i.e. POSCAR, KPOINTS, & WAVECAR) to print out an xsf to the user's specificity.

Refactoring `OccupiedStates`

I think OccupiedStates is ripe for a refactoring.

The first bit I noticed was that the kpt and G fields are matrices with the same element repeated along each column or row, respectively, and therefore they could likely be reduced to vectors so that we keep the storage space down.

Second, we can probably treat OccupiedStates like a matrix, and have it subtype DenseMatrix{ComplexF32}. Along with a Base.getindex definition, this would allow it to be have just like a regular Matrix{ComplexF32} and simplify a number of methods.

This would also involve changes to get_occupied_states, but I think a more elegant way to approach this is by defining a constructor for OccupiedStates that uses the new raMOInput or raMODFTData structs we've been working on.

Wigner rotation matrix for d orbitals

Rotation matrices are needed for the incorporation of hybrid states involving d orbitals.

Make UnicodePlots.jl dependency (and possibly some others) optional

UnicodePlots adds some really nice visual information to the log, but it takes a while to load/precompile, so I think using Requires.jl or Julia 1.9's weak dependencies would be a good idea to make this optional so that loading the package can be more efficient.

Default units for energies and lengths in YAML input

As I've reading through the read_run_yaml code, I've come to realize that the default interpretation of energy values depends on the choice of software package. This may not require a significant change, but I figure explicitly considering the solutions to this issue is a good idea, especially if others plan to rerun calculations with different software packages.

There are three options to consider:

1. Infer the energy unit from the software package (if software: vasp then assume the input is in eV, if software: abinit then assume hartree). This is the behavior as coded.
2. Use a default energy unit for DFT-raMO (probably Hartree, as with Electrum and most DFT packages) and allow for users to specify a different unit if desired. emax: 9.5 would be interpreted as 9.5 hartree by default.
3. Require that an energy unit is specified every time. An entry like emax: 9.5 would be invalid, and an error would be thrown to indicate this.

If we want to stick with the first option, feel free to close the issue. However, we should add support for alternative units in the YAML regardless.

Renaming and refactoring `Supercell`

This no longer seems to refer to a supercell, but instead contains information about atomic orbitals associated with a PeriodicAtomList. This data structure should definitely be renamed, but I also think refactoring the code referring to it is in order.

Check for "negative number of electrons"

DFT-raMO/src/data.jl

Line 206 in 93790c6

@assert electrons_left >= 0 "The number of electrons left is a negative value."

For now, the number of electrons left can be negative due to the Fermi energy in VASP being imprecise. I need to add a check or a warning at the beginning of the DFT-raMO analysis, which will suggest the user to adjust emax.

Additionally, users might want to artificially raise emax to see a raMO scheme at an increased electron count, which means the number of electrons left with respect to the calculated composition will be negative.

I think we should comment out this assertion for now.

Specify energy range for raMO analysis

We plan to write a function that allows you to specify the energy range of the bands that are included in the DFT-raMO analysis. Currently, only bands up to the Fermi energy are used. This feature would be useful especially in variations of the valence electron concentration, i.e. ±1 electron.

Atomic orbitals on arbitrary points

Danny asked, is it possible to reconstruct an atomic orbital at an arbitrary point rather than one of the atomic centers in the supercell? This should be possible to implement.