Thanks, Anton and Dániel, for your insightful postings.
I think that, ultimately, there is not so much difference between the reduced and expanded approaches. The work that needs to be done to expand the reduced system is equivalent to the work to check that the expanded system indeed obeys the declared symmetries. (Or do you see any problem with the statement, Dániel?)
The one advantage of the reduced approach that I can see, and that could tip the scale, is that it works better with Kwant's value functions, i.e. functions that return bits of the Hamiltonian dynamically when given some optional parameters.
I think it’s more robust to specify that these functions will be only ever evaluated on the FD than to say that the functions will be evaluated on the UC, but their results must always respect the declared symmetries. In the latter case if some unitary transformations are involved, we might be forced to even do almost_equal checks up to some epsilon.
I’m not yet sure how to best handle symmetries that put constraints on the value of a single site or hopping. We still want value functions to return a matrix in that case I guess, so we would have to do the necessary consistency checks on that matrix. But probably that’s not different from requiring that onsite Hamiltonians are Hermitian, and that we already do.
Do you agree with the following? Even if we go the reduced way, we still want to have integer numberings of all the sites and hoppings in the expanded cell, so that
• solvers that don’t need point symmetries, don’t have to deal with them, • we can store quantities (e.g. observables) for the expanded unit cell.
So in that sense we can forget about the point symmetries when designing the API for expanded low-systems. All we need to make sure is that the API for expanded low-level systems can be implemented efficiently for reduced low-level systems as well.
smime.p7s
Description: S/MIME cryptographic signature
