Closed phibeck closed 1 year ago
Thanks @phibeck for the report and the discussions! The current implementation works well for Vasp+Wannier90, where the orbitals seem to be ordered differently than in QuantumEspresso+Wannier90. I will implement a flag to switch between the two behaviors. Reading the nnkp file would not help here because in the Vasp+Wannier90 workflow, the order in the nnkp file does not seem to correspond to the order in, e.g., the _hr.dat file.
Can we close the issue now? Or should we think about a more advanced solution reading the orbital order from that output file for each code? If I understand correctly we could try to read this from the nnkp file?
I think we can close it for now. It would be some effort to read it in and for most cases it's probably not necessary, although there would definitely be some benefit to checking it somehow. For now it's entirely up to the user to make sure this is all in order, which can get cumbersome for larger systems in particular.
Okay thanks than I will close it for now
Description
There are two problems in the current version of the Wannier90Converter when using spin-orbit coupling:
Steps to Reproduce
When using a Wannier90 Hamiltonian with:
(u,d)
Expected behavior:
seedname.nnkp
file to reorder only if necessary.Actual behavior: Everything gets reordered as one big impurity, and irrespective of whether the orbital ordering was already correct.
Versions
Unstable branch of dft_tools.
Thank you Olivier Gingras for reporting. @merkelm - should we read
seedname.nnkp
to remove this risk?