-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add fat bands
to the BandPdosWidget
.
#624
Add fat bands
to the BandPdosWidget
.
#624
Conversation
This is the first commit to support `fat bands` in the `BandPdosWidget`, to visualize the contribution of the orbitals directly on top of the bandstructure. The commit contains the following main changes: * `_add_projection_traces` is added to plot the projections on top of the bandstructure. It follows the logic of the existing methods. * A checkbox is added to `BandPdosWidget` to enable the projected bands. To group the orbitals etc., the existing grouping features for the PDOS are used for the projected bands as well. In case PDOS and projected bands are plotted at the same time, the legend is grouped so that the data can be hidden in both subplots simultaneously. * `get_bands_projections_data` is added to extract the projections from a `ProjwfcBandsWorkChain` (see `aiida-wannier90-workflows`). Moreover, the new version relies on `_get_bandplot_data` to extract the bandstructure. In addition to the previously used `_exportcontent` in `export_bands_data`, this method also provides the bands along the full k-path and not only the separate segments. This allows to plot all bands and projections (for each orbital group) in a single trace which should improve the performance. Important to note, the data of the previous method is still accessible. * `_prepare_projections_to_plot` is used to convert the projections into a certain format (see the comments in the implementation for details). This involves some numpy operations to address the previous point of plotting the groups in a single trace. * `_projections_curated_options` is refactored quite a bit. The method supports now the extraction and curation of the PDOS or the projections. Moreover, the different aspects are divided into separate functions to facilitate the maintenance
a band needs to be concatenated with its mirror image, first. | ||
""" | ||
projected_bands = [] | ||
for spin in [0, 1]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe try to use the naming from aiidalab_qe , as collinear
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also try to see if this logic is consistent for SOC scenario ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure, if I fully get your point here. The 0
and 1
are the indicators for the different spin-channels that are used in the BandsData. _get_bandplot_data
method. Therefore, I didn't use something like "up" and "down".
But good point, I'll check how these list would look like in case of SOC.
@t-reents thank you ! nice work I had a few comments. First It would be nice to test the logic for all conditions , selecting atoms , orbitals ... and so on , also it is necessary to test a SOC simulation to determine if the logic is preserved. If the plot is only bands with projection then the widgets for displaying the projection should be displayed if there is a projection and hidden if not. Regarding the nested loops, I agree it would be the best to do one single trace , however the way the data in the dictionary was given by traces. Could you please suggest a solution where is only one trace, and double check that you still can select points from the bands (plot) |
@@ -397,6 +431,7 @@ class BandPdosWidget(ipw.VBox): | |||
Select the style of plotting the projected density of states. | |||
</div>""" | |||
) | |||
projected_bands_width = 0.5 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add this to the SETTINGS dictionary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one question any particular reason for this number ? Maybe try to test a system with a good amount of atoms and/or kinds , so you see the appearance onced you have plenty of bands
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was just to have a first starting point, to check that everything works.
Not sure, how you think about it (I'm also not a 100% sure, what I think about it, as the layout might get too complicated with too many options), but one could also add a dropdown/slider to choose the maximum linewidth, since the perfect value might differ for different applications?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@t-reents Since the idea is that the widget it has a general behaviour , is important you check with a medium and big system , so you can see how is the appearance, and if you need to maybe add this as a extra widget to control this width
Thanks for your comments @AndresOrtegaGuerrero. I tested all kind of selections and they seem to work. I was also thinking about a SOC calculation but don't have experience with those calculations and no data right now. Do you have a WorkChain to share as an archive, so that I can use it for the development? Yes, I'll provide a "one trace" solution for the bands tomorrow, and I'll keep in mind that each band/k-point can still be selected.
Exactly, I haven't done this yet, but the idea was that the grouping options are alway displayed in case PDOS or band projections are available |
For SOC , you can install this plugin to your aiidalab_qe (https://github.com/AndresOrtegaGuerrero/aiidalab-qe-soc/tree/main) , and run a calculation , however for the projections , we need to do a modification , you can check in (https://github.com/AndresOrtegaGuerrero/aiidalab-qe-soc/blob/main/aiidalab_qe_soc/socworkchain.py) , the special settings are in (https://github.com/AndresOrtegaGuerrero/aiidalab-qe-soc/blob/main/aiidalab_qe_soc/workchain.py) , one single thing is to replace the BandsWorkChain for the one you use for the projection |
Thanks, I'll give it a try. Probably I'll just do it via AiiDA-core as I'm used to it |
@t-reents Currently i am also working with a modification to the widget here #512 , the new feature is to allow the app to use tot_magnetization. When you use |
Different methods are refactored in this commit: * New functions to create the figures, add the different traces and to generate the final plot. Those replace the previous individual `_create..._plot` methods, to make things more compact * The methods to generate the axes were also refactored to avoid code duplication. * The bands are plotted in a single trace now, improving the performance of the widget
0b6d0c5
to
d3b487a
Compare
If `tot_magnetization` is specified, the results contain a fermi energy for each spin channel. The general support was added in aiidalab#512 and this commit introduces the required changes to the widget.
(False, 0): self.SETTINGS["bands_linecolor"], | ||
} | ||
fermi_energy_mapping = { | ||
(False, 0): self.fermi_energy.get("fermi_energy_up", None), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what happens when there is only one fermi_energy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The key would be (True, 0)
or (True, 1)
in that case but those are not present in the mapping. Therefore, the value for fermi_energy
would be returned as expected:
aiidalab-qe/src/aiidalab_qe/common/bandpdoswidget.py
Lines 267 to 270 in 25edba6
fermi_energy = fermi_energy_mapping.get( | |
("fermi_energy" in self.fermi_energy, spin), | |
self.fermi_energy.get("fermi_energy"), | |
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!, We did different tests and check the logic and test the qe app! It also improves the performance
This PR solved #626 |
Hi @unkcpz @AndresOrtegaGuerrero
As discussed, I worked on the support for the "fat bands" plots and I managed to merge this into the existing
BandPdosWidget
. While working on this, I also started to refactor some of the existing methods, see the commit message for more details, mainly to split things up in a more compact way.I have some further ideas, but I already wanted to share this version, to get further input. One thing that would be useful to address in my opinion, are different linestyles for the spin-up and spin-down projected bands, as the underlying red and blue linecolour is not always easily visible.
Important to note, the
Project bands
checkbox is only used for this first draft. This would be changed to something more properly formatted in the final version.One additional question @AndresOrtegaGuerrero: is it really necessary to have these nested loops to iterate each segment separately? At the moment, I don't really see the reason, please correct me if I'm wrong. As mentioned in the commit message, since this version relies on
BandsData._get_bandplot_data
, one could also plot the bands in a single trace (need to check how much this would improve performance).aiidalab-qe/src/aiidalab_qe/common/bandpdoswidget.py
Lines 262 to 266 in f64607c
The current implementation works for non-spin-polarized and spin-polarized calculations. Moreover, the projected bands can be used with and without the PDOS (and all kind of groupings are supported as well).
The orbital/atom contributions in the legend are grouped if the PDOS is plotted as well, so that the chosen contributions can be hidden in both subplots at the same time.