Model Hamiltonians

[wavefunction91]

Adding model hamiltonians

[CarlosMejZ]

Maybe it would be worth making the chemical potential an argument with default value? I could imagine people wanting to shift it, even if it's a finite 1d-chain.

[wavefunction91]

This was something I wasn't sure on, glad to know it's a flexible parameter. Is there a general form for this Hamiltonian that we could document so we can be precise in what we're supposed to be doing here?

[CarlosMejZ]

A common form for the interaction in the particle-hole symmetric case is:

U/2 \sum_i (n_i - 1)^2

Where n_i is the full particle number operator in site i, adding spin up and down. This automatically adds the chemical potential term of -U/2, and also a constant energy term of U/2 which of course does not affect the physics. So, a meaningful option would be to accept the chemical potential deviation away from half-filling as input, in other words a \mu such that the full Hamiltonian is

[hopping] + U/2 \sum_i (n_i - 1)^2 + mu \sum_i n_i

What do you think?

[CarlosMejZ]

For model Hamiltonians like this one, it will make sense to add a new HamiltonianGenerator class that implements the single/double search instead of the double loop (Incidentally, it could make sense to add it to this branch. I could take charge of that, since I've already implemented something in these lines). This is especially true since many of the model systems have an extremely sparse V tensor, which makes this type of Hamiltonian build very efficient. To this end, we could consider the option of having these "integral building functions" return a vector listing the orbitals which have a non-sparse V sub-tensor. In the example of the Hubbard model, this will always be empty, since V is completely diagonal, and hence does not generate any double (or single) excitations. For an impurity model, this would be just the impurity.

[wavefunction91]

This is a good idea, If you can mock something up and push to this branch, that would be helpful. We can iterate on the design once something is in place.

Re Sparse vs dense storage, that's a good point. I'm hesitant to do this ad hoc though, if we're going to support sparse integrals, we should build up proper sparse tensor infrastructure (sparsexx can already cover the Matrix case, we would just need to generalize the CSR/CSV/COO to tensors which is relatively straight forward). However, even for some the largest cases that folks can do ED on for these types of problems (26-28 sites), integral storage is trivial compared to the CI vectors, so this kind of optimization may be premature. But I can definitely see the desire to have this in general, so we should figure out how to do it properly - I would say we should punt on that for a bit and maybe open an issue so we don't forget to cover it eventually.

[CarlosMejZ]

Sure, I'll put what I have and push it in.

I didn't mean using a sparse tensor for the V's, I agree that's a bit premature (though useful at some point). I was thinking of storing the dense V, full of zeros, but having the HamiltonianGenerator instance only look for doubles/singles among a subset of orbitals. For example, in the Hubbard model, you want to tell it to look for singles everywhere, but for doubles nowhere (there are no doubles, at least in real space). This will dramatically reduce the cost of the Hamiltonian build. For impurity models, you want to look for singles everywhere, and for doubles only among the impurity orbitals (since the bath is non-interacting by construction, at least in DMFT). Since the impurity is typically much smaller than the bath, this again is an important speed-up.