Redesign how hermiticity of a Hamiltonian is encoded

[pablosanjose]

Checking whether a very large Hamiltonian is Hermitian is inefficient, particularly for compressed-column sparse Hamiltonians which do not favor row access. Currently, we have no way to encode Hermiticity, and this is unfortunate.

We could add a field to a Hamiltonian that signals hermiticity when the original model is hermitian, and then force setindex! to preserve hermiticity. Alternatively we could wrap it in Hermitian. The latter would be the more Julian solution, but then we should make Hamiltonian satisfy the AbstractMatrix interface, which is probably not possible, as it is a more general object.

This issue is a reminder and an invitation to discuss possible designs.

[BacAmorim]

I think it is a good idea to add a field hermitian to a Hamiltonian declaring if the Hamiltonian should be Hermitian or not. Then this info can be passed to a Diagonalized algorithm and each algorithm will do what it wants with that info.

Also, I think it would be useful to add a method to ishermitian, which allows the user to test whether the Hamiltonian they have built actually is Hermitian or not and whether this contradicts the declared field.

Finally, I think the forcing of setindex! to preserve hermicity (by automatically adding a hopping B=>A, if we set a A=>B hopping), should be an option forcehermitian (which we might default to true if hermitian=true).

My reason to propose this as an optition is the output of Wannier calculation. The hoppings are returned without any concern of hermiticity. If we always force hermiticity in setindex! will add the same hopping twice, which would be a waist of time.

Just my €0.02.

[pablosanjose]

I think I agree. The main reason of the Hermitian wrapper is to be able to have type-stable diagonalize methods, that return either real or complex eigenvalues. The approach in pablosanjose/Elsa.jl#37 addresses this issue, and I think the decision there is solid. The ishermitian field would then not be used to determine the type of eigenvalues (they would always be of the same type of momenta), although it could be used to set the imaginary part to zero in the complex case.

The problem of having a field that promises hermiticity is that it could lie, unless we force the API everywhere to respect this. If we use a setindex! that does not forcehermitian on a Hamiltonian with ishermitian == true, should we update ishermitian to false? What if we then add the conjugate element to restore hermiticity?
One might think the solution is to set ishermitian to false, unless the conjugate of the element being set is present, in which case we set it to true. But that doesn't work, because if it is present we cannot be sure the entire matrix is hermitian.

I suspect the only way to solve this is to make the ishermitian property inmutable, and make setindex! respect it. In the Wannier case we can just set forcehermitian = false when building the original Hamiltonian, if we want to set all elements independently.

Finally, another reason to not encode hermiticity at the type level, and keep it as a Boolean struct field as you say, is that the package is already becoming slightly parametric-heavy. This is still not a problem for compilation time, but in the future I'd like to look into ways of simplifying the type parametrizations if possible.

[pablosanjose]

I'm less inclined since #38 to bake in privileged behavior for Hermitian matrices. As the package progresses it will become more and more common, I think, to consider open systems with non-Hermitian self-energies, or other uses beyond the strict tight-binding mindset. I'm currently working in a problem with a non-symmetric real "Hamiltonian" (in the sense of an inverse equation of motion Green's function) that benefits from all the Quantica machinery (including bandstructure calculation) without being Hermitian. I suggest we close this for the moment until we find a real need to impose/check hermiticity in a non-standard way. Otherwise, we should simply follow the Julia approach and extend the API with wrapped Hermitian(Hamiltonian)