Compatibility with multifusion categories

[borisdevos]

This PR provides the changes required to be able to consider the multifusion categories of (Multi)TensorKit.

All changes boil down to either

1. not being able to evaluate the unitspace of a BimoduleSector, or
2. not being able to use braiding tensors for BimoduleSector GradedSpaces,
   and finding ways around to this.

A potential thing to add is tests with BimoduleSector MPS/MPOs or so? For this, I would need to first complete benchmarking MultiTensorKit, hence the draft PR. I might also need to format.

[codecov]

Codecov Report

❌ Patch coverage is 90.62500% with 9 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/algorithms/fixedpoint.jl	0.00%	3 Missing ⚠️
src/operators/abstractmpo.jl	0.00%	2 Missing ⚠️
src/operators/mpohamiltonian.jl	94.28%	2 Missing ⚠️
...c/algorithms/excitation/quasiparticleexcitation.jl	75.00%	1 Missing ⚠️
src/algorithms/groundstate/gradient_grassmann.jl	0.00%	1 Missing ⚠️

Files with missing lines	Coverage Δ
src/algorithms/ED.jl	100.00% <100.00%> (ø)
src/algorithms/correlators.jl	90.90% <100.00%> (ø)
src/algorithms/excitation/chepigaansatz.jl	91.48% <100.00%> (ø)
src/algorithms/timestep/taylorcluster.jl	100.00% <100.00%> (ø)
src/algorithms/timestep/wii.jl	98.14% <100.00%> (ø)
src/algorithms/toolbox.jl	95.15% <100.00%> (ø)
src/environments/abstract_envs.jl	92.10% <100.00%> (ø)
src/operators/mpo.jl	87.38% <100.00%> (ø)
src/operators/ortho.jl	100.00% <100.00%> (ø)
src/states/abstractmps.jl	52.87% <100.00%> (+0.54%)	⬆️
... and 9 more

... and 3 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[lkdvos]

Could this also be leftunitspace?
This looks a bit funny to have V_left call rightunitspace.

To be completely fair, I'm actually surprised it would have to be left or right to begin with, since I always understood that as something you would multiply on the left or right respectively, and not something you can direct sum with, so I would guess that in this case you would have to have \boxtimes is only possible wheneveer leftunitspace = rightunitspace which is just unitspace?
I might be completely wrong here though, this is a bit more intuition based than actual strong thinking based

[borisdevos]

The Hamiltonian itself is diagonal, meaning its virtual spaces are graded the same way as the physical space. In that sense, taking the left or right unit space is the same. I haven't thought too much about direct summing between different gradings and whether that makes sense.
Either way, unitspace is not the way to go, because we've designed that now to return all the units of a given sector.

[lkdvos]

Ah right, I forgot about that! Would this mean that we could take the left unit space of the physical space instead? That at least sounds spatially correct in my head 😂

[borisdevos]

I can do that, and will do so in other places where MPOHamiltonian is involved. I'd like to add an assertion to make sure this is fine. However, for MPOs I'd like to keep the freedom of potential off-diagonal virtual spaces, even though I haven't tested those yet.

[lkdvos]

I don't really know what diagonal and off-diagonal means in the context of hamiltonians to be honest, I know you guys keep saying this but I never really got what this is about 😉

[borisdevos]

anyonchainCMD.pdf
I'd like to preface that what I'm going to say is untested in MPSKit, so it might not even work, but I'll just sketch what should in general be possible.

I attached an image of how a multifusion MPS looks like. The physical spaces are graded by some fusion category $$D$$, while the virtual ones are in general now some (bi)module category which I call $$M$$, such that the symmetries/excitations are labeled by $$D^*_M \equiv C$$. What I mean by Hamiltonians being diagonal is that the operator at the level of the fusion tree is only graded by objects in $$D$$. However, in general one should be able to consider MPOs where this isn't the case, i.e. off-diagonal, which result in e.g. duality operators which change $$M$$ to some other (bi)module category $$N$$. In general, when "us guys" talk about the diagonal (or regular, because you can't have enough words for the same thing 😄) case, we mean the usual case where you don't consider bimodule categories.

Again, this is untested, and is also the reason why a lot of parts in the code involving MPOs still just have a bunch of unitspaces instead of left/rightunitspaces.

[github-actions]

Your PR no longer requires formatting changes. Thank you for your contribution!

[lkdvos]

I think this looks quite good, almost ready to go.
Apologies if I already asked this before, I'm trying to keep up but I sometimes forget:
I'm a bit confused about the usage of unitspace in many places now. If I understood this correctly, this should give you a space with all the units, and I'm surprised this shows up here at all.
Do we not expect that we should mostly be able to correctly find out which unit we need in the MPS algorithms?

Otherwise I am happy to merge this.

[borisdevos]

I answered this above, but I'll say it again that yes, in principle you should always know which unit is the relevant one for some algorithm. Looking into where this occurs, I realise I've been lazy in certain parts. I thought I tested everything concerning MPOHamiltonians, but that's not true. I'll look more into this.

Looking into other places where unitspace still appears, there's just the FiniteMPS constructor. There, the left and right keyword arguments still default to unitspace simply because it's really annoying (and maybe even impossible) to put a possible off-diagonal virtual space. So the user just needs to fill in those keyword arguments manually with a potentially off-diagonal virtual space.