Dominik Gresch

@giovannipizzi @sphuber do you know if that is a limitation that QE itself puts on the input file, or is it just a limitation of our parser?

> To be honest I don't know. I have not written these parser nor ever worked with them. Yeah, same here 😅 Also looking at the code quickly, it seems...

How was the tight-binding Hamiltonian generated? The easiest explanation would be that there is a small numerical difference already there.

Hi Jamin, No, in general Z2Pack doesn't enforce symmetries. The symmetrization feature in TBmodels also needs to be explicitly called, so that shouldn't have an impact here. It simply deletes...

> Is the recent version of Quantum Espresso compatible with pw2z2pack.f90? I'm not sure, but would be somewhat surprised if it was directly compatible. I haven't really modified the `pw2z2pack`...

No, this is not something that TBmodels can do natively. It takes the tight-binding form of the Hamiltonian as given, without keeping the connection to the underlying basis functions. Could...

I have a workaround for the issue, which is just to use ``get_kpoints_mesh(print_list=True)`` to create a new instance with explicit k-points. Maybe a lot of the problems would be solved...

Since the different 'kinds' of ``KpointsData`` (mesh, path, list) are constructed differently, and have a partially different subset of functionality, it makes more sense to me to make them different...

No, TBmodels doesn't contain an implementation for such a disentanglement routine. The current TB -> k.p conversion is just a straightforward Taylor expansion.

The `pw2z2pack.f90` module is based on `pw2wannier90` as it was shipped with QE 5.3.0. To the best of my knowledge, it's not compatible with other versions of QE.