Bands common workflow

[bosonie]

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?

[espenfl]

Thanks for raising the issue. Depends. How extensive do we want to be? In the VASP plugin we use the seekpath, but users can also pass explicit points. I suggest we keep it very simple but general if possible.

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.

[bosonie]

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 CommonRelaxWorkChain

• This allows to relax with one code and obtain bands with another.
• Enable use of seekpath in a straightforward way (Seekpath might change the cell to get the right kpoints along high symmetry lines)
• Simplify the implementation for codes where different executables are used for bands and for scf.
• Poses the challenge to find the best way to exploit quantities already obtained in the relaxation (density matrix / wave-functions) in case the same code is used for both bands and relaxation (see below).
• Will require a future creation of a further workchain (code agnostic?) that automatically do relaxation and then bands.

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:

• removal of the relaxation_type and reference_workchain inputs
• addition of a way to specify kpoints for bands and optional “start from a previous calculation” options. See next point.

There will be two mutually exclusive options for specifying the k-points:

1. SeeK-path parameters: In this case the input generator will use SeeK-path and the structure to find the primitive cell and corresponding high-symmetry paths. This will most likely adapt the structure (change of structure in the input generator!! In a calcfunc??) and an extra SCF will be needed before the band structure calculation to obtain the correct charge density.
2. Explicit k-points list (and attached labels for high symmetry points): In this case the structure will not be changed, and the k-points are expected to be defined in (direct) coordinates of the reciprocal space. This will also allow the user to optionally specify a remote_folder where a charge density / wave-functions to start from is stored. A check is needed that the remote_folder contains a calculation with the same code defined in engines.

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 <Code>CommonRelaxWorkChain inputs. Also, the translation between some <Code>CommonRelaxWorkChain outputs (e.g. magnetic moments) into inputs of the bands workflow is not encoded anywhere. To fix this issue will be task of the higher level workchain (relax+ bands), but maybe the best solution is to allow directly in input of the input generator a previously run <Code>CommonRelaxWorkChain. This will require logic to manage the interplay with other inputs (protocol, remote_folder, etc).

Number of bands in input? In any case should be an optional input. Since all-electron codes have a lot more bands, specifying the number of bands you want to calculate is not sensible as an input. Alternatives for specifying the number of bands:

• Specifying the energy range over which to calculate the bands: this is tricky because we do not know for e.g. Quantum ESPRESSO how many bands we need to obtain a certain energy range.
• Specifying the number of unoccupied bands?

Notes for the oxides project. How to compare bands

• Suggestion use the band distance of https://www.nature.com/articles/s41524-020-0312-y
• Calculate effective electron mass
• Comparing energies: where is your zero level? For metals: the fermi _level, for insulators: the highest occupied state.

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.

[espenfl]

Could not attend today, so here are some comments from me:

SeeK-path parameters: In this case the input generator will use SeeK-path and the structure to find the primitive cell and corresponding high-symmetry paths. This will most likely adapt the structure (change of structure in the input generator!! In a calcfunc??) and an extra SCF will be needed before the band structure calculation to obtain the correct charge density.

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.

Explicit k-points list (and attached labels for high symmetry points): In this case the structure will not be changed, and the k-points are expected to be defined in (direct) coordinates of the reciprocal space. This will also allow the user to optionally specify a remote_folder where a charge density / wave-functions to start from is stored. A check is needed that the remote_folder contains a calculation with the same code defined in engines.

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.

Number of bands in input? In any case should be an optional input.

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.

Calculate effective electron mass

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 kspclib, which plays nicely with spglib and seekpath.

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.

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.

[bosonie]

Thanks @espenfl for your comments.

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.

But if seekpath changes the structure, the charge density becames unusable, isn't it?

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 kspclib, which plays nicely with spglib and seekpath.

We will go back to that later in the development of the oxides project

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.

We meant solving crossing problems. Agree to start simple.

[giovannipizzi]

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:

• we have the common wf interface for bands not do any SCF/charge density calculation, but delegate this to some external routine (I think in general the common workflow, but [I think?] there is also interest in supporting users who run the first step without the common workflows?)
• Because of this above, the input should just be some reference to the previous SCF calculation: could be the CommonWF, similar to the reference_workchain; or, if we want to allow also non-common-wf calculations, the final RemoteData? If we want to cover this latter case, we need to check:
  1. that passing the final RemoteData is enough for all plugins to go back in the data provenance, and look at the inputs of the actual Calculation (not the common WF as this might even not have been run) to get all needed inputs? Or we need something more?
  2. adapt the Relax Common WF interface so that it also returns the final RemoteData (might be useful anyway), so that a user can just take the outputs of the Relax Common WF and pass it to the Common WF interface for bands
• add only needed inputs for bands: number of bands (in one or many forms), explicit list of k-points (i.e.: it's always an explicit list)

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:

• we remove code duplication (the common bands WF does not need to implement any logic for relaxation (and we don't need to duplicate features e.g. to adapt/override inputs of the calculation, e.g. if we want to do DFT+U: if we know how to do it for the common relax WF, then it would just work also for bands)
• if seekpath rotates the structure, the common workflows that combines relax+bands will know what to do (run first seekpath, then the relax/scf, then possibly a final time seekpath if it was a relax and possibly a final SCF, and then ask for the bands using the 'correct' seekpath input associated to the correct structure). If instead an explicit list is passed, no structure rotation is performed.

[giovannipizzi]

Regarding the point on selecting the number of bands:

• I think an optional input to select the number of bands would be useful for advanced users (a bit like we're now extending the selection of the k-points mesh density and smearing type, see e.g. #230).
• However, I think if we're also targeting "non-expert" users it would be good to:
  • have good defaults (e.g. only valance if the electronic type is 'insulator'? Or maybe also in that case compute a few conduction bands)
  • always compute e.g. 20% bands more than the # of valence bands as a default
  • have a way to specify the number of unoccupied bands, or change the percentage above (maybe percentage is easier for a user who does not know how many bands to expect?)
  • probably for KKR it' instead easier to have an energy range rather than a number of bands (I guess the energy range should be w.r.t. the Fermi energy?) @PhilippRue can you comment on this? If this is the case, we need to
    1. allow for both types of inputs
    2. since for most codes they can only accept one or the other way (either # bands or energy window) probably we need to define a machine-readable way to say what inputs are accepted

We could pack all these options into a Dict node, but then we need to clearly define a 'schema' to validate the content of the Dict together with the input specs (e.g. in #235)