smtg-bham / easyunfold Goto Github PK

At the time of writing the coverage is only 66% - ideally we should increase it to over 90%.

https://app.codecov.io/gh/SMTG-UCL/easyunfold/tree/dev/easyunfold

Top coverage misses are in plotting.py and unfold.py.

If there are too many kpoints, it might stop the calculation from happening!

Currently the loops in PROCAR parsing and spectral_function_from_weight_sets run over all bands/kpoints in the calculation.
In many cases, the bands extend over a very large energy range (e.g. in the Cs$_2$Sn/TiX$_6$ alloys from the docs example, the range is -37 to +8 eV), whereas we usually only want to plot within a much smaller energy range (e.g. -5 to +5 eV).
Given that the PROCARs are parsed each time when doing a projected band structure plot, and this is the most time-consuming part of the projected plotting, it could significantly speed up this step by only parsing bands with energies within the emin - emax range.

I implemented a (conceptually) similar masking approach in PyTASER recently (WMD-group/PyTASER@4b8ac4d) which gave a massive boost in efficiency.
Worth considering!

I'm not sure if this package also supports the feature Band re-ordering as the one implemented in VaspBandUnfolding:

Regards,
Zhao

The definition of the transformation matrix should be stated somewhere. It is different for row and column lattice matrices, here we use the column lattice matrix convention so

Where c and C are matrices made of column lattice vectors.

This means for row vector matrices we have:

Note： both ase and pymatgen stores the lattice as row vectors.

The project started with using mkdocs because it was simple and the site is well designed.

As more functionalities are added, we may want to switch to Sphinx + MyST without rewriting much of the documentation files?

The advantage is that the API documentation can be generated automatically, while currently one have to manually run commands and commit the changes.

Should be doable - we can link with multiple WAVECARs and search for eligible kpoints among them for computing the spectral weight.

I had some thoughts on some potential minor improvements to the package to make it even more user-friendly, but worth discussing as I'm not sure if some/all of them are worth it:

• Pulling the number of atoms and identities from the vasprun.xml, so that the user just needs to specify which 2 or 3 species they want to project (as in sumo) rather than listing the atom indices, and then done automatically from there. This would mean we could then automatically add a legend for the colour projections to the unfolded bandstructure plots which would be nice. The issue with this I guess is that currently the projections are done after the initial unfolding calculation, using the PROCAR file, which doesn't contain information on the atomic identities. So it would mean you also need the vasprun.xml at this step. In theory, the info in the PROCAR is also available in the vasprun.xml, with pymatgen parsers built for this, so you could add the functionality to pull this info from a vasprun.xml as well as from the PROCAR, so for these cases you could use --atoms and --vasprun instead of --procar and --atoms-idx to do the same thing (but now with a figure legend)?
  • Do you think this would be worth it @zhubonan? If so I can have a go at implementing.
• Related: Add functionality to also plot a DOS alongside the bandstructure, like in sumo. Could do this by having a --dos vasprun.xml option for the CLI plotting. If you think this would be useful @zhubonan, let me know and I can code it up!
• Quick docstrings flesh-out and update to make the API docs more informative (good atm, but a quick skim through would make them extra nice and clean).
• To me, the current setup of vscale is counter-intuitive (see https://smtg-ucl.github.io/easyunfold/cli/). It's a "scaling factor for the colour mapping", but decreasing it increases the colourmap intensity, whereas intuitively as a user I would've expected the opposite behaviour. Obvs a very minor thing, but I think it would be better to reverse this behaviour?
• Currently the code also supports orbital-specific projections as well as atom projections right? I think this is a useful feature and would be good to add an example showcasing this functionality. I can put together an example for this and add to the docs.

Should allow no averaging for comparing the effect of symmetry breaking.
Also, at the moment the averaged weights are stored, this means that the unaveraged weights should be stored in the json files as file.

This is part of review for JOSS over at openjournals/joss-reviews#5974

There are automated tests within the repository, which is great! However it is not explained in the documentation how to install the dependencies for the tests, or how to run the tests themselves manually. Adding a small section explaining this could be quite useful.

Hello.

I did a bandunfolding with the split option into 7 calculations. The overall bandstructure is plotted but the plotting projections yields the error:

ValueError: Cannot found kpoint [ 0.5 -0.5 0. ] in PROCAR files

Strangely, the output of grep gives in the last procar file:
k-point 9 : 0.50000000 -0.50000000 0.00000000 weight = 0.11111111

The point is there in the file but the program cannot find it.

I calculated the unfolded band structure of Sb2Si2Te6 supercell with pymatgen k-path. There are some flat bands between high symmetry points when I plot the unfolded band structure without atom projections, but the unfolded band structure becomes normal when I plot it with atom projections.

Hello

I'm trying to plot the band structure for my system. The overall band structure works fine but any projections yield the error:
P_Km = P_Km * band_weight_sets[ii][jj][ispin, :P_Km.shape[0]]
~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
IndexError: index 1 is out of bounds for axis 0 with size 1"

Kindly help.

Hi Bonan, so far the package is behaving well, I'm road-testing some ZnO supercells. One thing that I've noticed that would be a nice quality of life update is to have something similar to the folder generation in sumo. Currently, if you have say 8 splits for the band structure, it makes the 8 KPOINTS files, but then you have to manually sort out 8 separate calcs. In sumo the -f option pastes KPOINTS splits and relevant input files into fresh directories. This would be a nice feature :)

Will keep you updated if I find anything else, and will let you know how the calcs go. Cheers, Joe

This is part of the JOSS review over at openjournals/joss-reviews#5974

This is a minor point, but the community guidelines section of the review calls for: Contribute to the software, Report issues or problems with the software and Seek support. The first two aspects are already covered in the documentation. Adding a small section about how to reach out to the devs for support would help to close this issue.

Is it possible to export the energy, k, spectral weight to gnuplot unfold.dat format, likewise we have for sumo (energy vs k) as band.dat?

This is part of the JOSS review over at openjournals/joss-reviews#5974

• Line 10-11, 14 could be strengthened by a citation.
• Line 36, k-points were not mentioned before, the theory comes only later. Probably a one line introduction could be really useful.
• Line 47, VASP and CASTEP needs citations.

Syle of the plots may be further adjusted by mplstyle file.
Should be easy to implemented. sumo has something similar.

Note that mplstyle file does changes globally, so caution is needed for interactive sessions (notebooks etc.)

Is easyunfold compatible with other DFT packages than Vasp and Castep. The documentation states that integration is supposed to be straightforward.

An example via an ASE calculator which saves the band structure would be a very convincing example for a widely compatible band structure unfolding implementation. Alternatively, a short note in the docs and/or software paper why the ASE provided band structure tools are insufficient for easyunfold would be useful.

Hello easyunfold developer,

I've been noticed that various material properties, including elastic, dielectric and piezoelectric properties, the forms of the results are affected by the choice of the primitive cell, as discussed here.

Given that different tools can generate varying forms of a material's primitive cell, I'm curious about the potential implications when using easyunfold for subsequent calculations and processing. Specifically, I'm interested in understanding: How does choosing the primitive cell form (as obtained from different computational tools) affect the results obtained with easyunfold for unfolding band structures or calculating material properties?

As an example, we can take the POSCARs shown on the website mentioned above to conduct our discussion: POSCAR_.zip

Thank you for your time and support.

Best regards,
Zhao