Add Hubbard model

[lkdvos]

This overloads the Hubbard model from MPSKitModels.jl

TODO:

• find some benchmarkdata to test
• implement fixed particle number

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 7 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/operators/models.jl	0.00%	6 Missing ⚠️
src/operators/lattices/squarelattice.jl	0.00%	1 Missing ⚠️

Files with missing lines	Coverage Δ
src/operators/lattices/squarelattice.jl	95.00% <0.00%> (-5.00%)	⬇️
src/operators/models.jl	70.58% <0.00%> (-9.42%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Yue-Zhengyuan]

Why is fixed particle number still not implemented? I think there is already FermionNumber symmetry class。

For benchmarking, maybe you can have a look at https://yastn.github.io/yastn/quickstart/hubbard_purification.html#d-fermi-hubbard-model-at-finite-temperature

[lkdvos]

I should probably be a little more careful with what I meant. Indeed, there is no problem using this function with imposing FermionNumber, which is just a combination of U1 and FermionParity. The subtlety lies in how symmetric tensors work: all tensors always have to have total charge 0. In essence, this means that imposing FermionNumber automatically makes you impose total particle number 0.
It is definitely possible to select a different filling, but this requires injection of U1 charges per site, typically also resulting in unit cells, and while I know how to achieve this, I have not yet figured out a good interface to do this.

[leburgel]

It seems a Hubbard Hamiltonian was added in #97, so this is probably superseded? The TODOs still remain valid though, would it be better to keep this open, or to close and move the TODOs to an issue?

[lkdvos]

Either is fine, I'd say pick the thing that gives the least headaches with merging/branching/...

[leburgel]

I filed an issue about the fixed particle number density, but we should anyway only look at that after it's been implemented in MPSKitModels.jl itself in the first place. Regarding the benchmark data, there's a comparison to an auxiliary field Monte Carlo result in the examples (it's not in the actual tests just because the runtime is very long). So I'm in favor of closing this.