You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is meant to discuss the various aspects of the DOS implementation in the project.
The first import decision to take is how to support the DOS calculations. Two possibilities:
To have code-dependent workchains (with common interface) that directly return the DOS. This means that it is the responsibility of the single developers to implement the various steps that from the inputs leads to the DOS curve.
To create common functions to obtain the DOS from a set of energies (on a kpoints mesh) calculated by each implementation. This means that the code-dependent implementations are only required to implement the methods for the BZ integration and return the KS eigenvalues for a set of kpoints. Then external common function will take care to create the DOS curve from the data.
The second possibility looks appealing however poses some challenges:
All the kpoints of the set and the eigenvalues must be stored in the database.
High level of control on the kpoints to use for the calculation of the eigenvalues would be desirable.
If and how to support the tetrahedron method to the BZ integration.
The text was updated successfully, but these errors were encountered:
Once again KKR is a special case here. We don't diagonalize a Hamiltonian but we compute the Greens function and from there we then also get the DOS. Therefore option 2 is not really possible for us but 1 is easy (and exist already in the plugin).
This issue is meant to discuss the various aspects of the DOS implementation in the project.
The first import decision to take is how to support the DOS calculations. Two possibilities:
The second possibility looks appealing however poses some challenges:
The text was updated successfully, but these errors were encountered: