-
Notifications
You must be signed in to change notification settings - Fork 31
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
Bands common workflow #222
Comments
Thanks for raising the issue. Depends. How extensive do we want to be? In the VASP plugin we use the What is a bit important is that we have the option to pass an explicit list as sometimes that is needed. E.g. the pregenerated grid plus the points on which you want to calculate the bands. For some of the codes the numbers of bands might also be relevant. |
Some suggestions for the bands workflow implementation coming from the working group meeting on 28th Sept 2021. To have a standalone workflow for bands rather than simply extend the
The interface for the bands workchain is going to be similar to the relaxation workchain: based around the concept of inputs generator carrying the common interface. The only changes will be:
There will be two mutually exclusive options for specifying the k-points:
NOTE: In this scenario the running of a relaxation and a subsequent band calculation is not so smooth. In fact, for some codes, one would like to use all the inputs of the relaxation for the bands, plus the output structure, the final magnetic configuration, the addition of the remote folder. However, at the level of the common interface, the inputs of the relaxation are not accessible since they are not stored. Stored are only the Number of bands in input? In any case should be an optional input.
Notes for the oxides project. How to compare bands
Band reconstruction? This is not done by several codes, and not really an issue for comparing: we simply sort the energy levels in ascending order for each k-point and compare. |
Could not attend today, so here are some comments from me:
Yes, we need to make sure provenance is kept. What is nice with e.g. this approach is that for the configurations where multiple options are available for the representation, we settle on one.
Notice that we would also want to use the combination. E.g. fetch the high symmetry with seekpath and then fetch the explicit points and pass to the explicit list. This would typically be appended to the list used to generate the charge density.
Yes, we would like to be able to use this. Different scenarios where this is convenient. Optional is fine. We would run with some defaults then.
Which effective mass? There are different ways to calculate this. Density of states effective mass is fairly straightforward. We could do this based on density of states we calculate workflow side for the plugins/codes not having this intrinsically, or if we want to use a different method. Notice that e.g. the tetrahedron method is included in
You mean folding? Or do you mean solving the crossing problems? Yes, I think we should start simple. I would expect us to have plenty to do just getting the basics right across the code base for the bands etc. Thanks a lot for updating the issue after the meeting. The overall approach sounds good. |
Thanks @espenfl for your comments.
But if
We will go back to that later in the development of the oxides project
We meant solving crossing problems. Agree to start simple. |
Thanks for the feedback! I agree in general with all points above (start simple, allow to pass other kpoints, ...). I have a slightly different suggestion than the one in #235:
Then, we would immediately define a common WF that combines the common relax WF + common bands WF, and knows how to pass parameters between the two. This would expose the inputs of the common relax WF similarly to the EOS, and also the inputs of the common bands WF, and have two overrides for the two WFs; in addition, here it would allow to pass either an explicit k-points list, or allow to use seekpath. This solves some points:
|
Regarding the point on selecting the number of bands:
We could pack all these options into a |
Issue to discuss details of the implementation of a common workflows to compute electronic bands.
As a first question: what do we pass to the workflow in input? The structure and a list of high symmetry points (boundaries of band lines)? Or a complete list of kpoints?
The text was updated successfully, but these errors were encountered: