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 79.34783% with 19 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/algorithms/toolbox.jl	0.00%	6 Missing ⚠️
src/algorithms/fixedpoint.jl	0.00%	3 Missing ⚠️
src/algorithms/excitation/chepigaansatz.jl	0.00%	2 Missing ⚠️
src/algorithms/timestep/wii.jl	0.00%	2 Missing ⚠️
src/operators/abstractmpo.jl	0.00%	2 Missing ⚠️
src/operators/mpohamiltonian.jl	94.28%	2 Missing ⚠️
src/algorithms/correlators.jl	0.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%> (ø)
...c/algorithms/excitation/quasiparticleexcitation.jl	44.52% <ø> (-32.12%)	⬇️
src/algorithms/timestep/taylorcluster.jl	100.00% <100.00%> (ø)
src/environments/abstract_envs.jl	71.05% <100.00%> (-21.06%)	⬇️
src/operators/mpo.jl	78.82% <100.00%> (-8.56%)	⬇️
src/operators/ortho.jl	100.00% <100.00%> (ø)
src/states/abstractmps.jl	49.42% <100.00%> (-2.91%)	⬇️
src/states/finitemps.jl	86.10% <100.00%> (-8.54%)	⬇️
src/states/quasiparticle_state.jl	79.08% <100.00%> (-7.61%)	⬇️
src/utility/plotting.jl	86.36% <100.00%> (ø)
... and 9 more

... and 48 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[borisdevos]

I may have added some confusing terminology with the recent commits, so let me clarify as much as possible.

First of all, I defined a left/rightunit for MPS and MPO. For the MPS this makes most sense, as my virtual space will in general be graded by module objects, so the "coloring" to the left and right of this is different. So in our convention of physical legs down, rightunit captures the coloring of the physical space, while leftunit captures the coloring of auxiliary legs such as in excitations, transfer_spectrum, etc.
For MPOs I'm still on the fence, because while in general my MPO's virtual space can also be graded by module objects, the only thing I've tested up till now is Hamiltonians where it's fully colored by the rightunit of the corresponding MPS. So this notation is introduced to ease notation mostly. I can deal with not having this; this appears only in the keyword argument of exact_diagonalization.

Connected to the last remark, many functions construct an MPS given an MPO based on the latter's virtual spaces. Since the MPOs I've considered up till now don't have different colorings on its virtual spaces, there is currently no difference between the left unit and right unit of an MPO. Thus, there's no difference between the leftunitspace and rightunitspace of the virtual space of an MPO, and I simply systematically chose to put rightunitspace to accentuate the "physicalness" of the coloring.

I've also replaced the remaining oneunits with unitspaces, where I didn't think too hard whether it was a leftunitspace or rightunitspace because I'd have to fiddle a bit everywhere to actually get the information of the coloring (reminder that left/rightunitspace can't be called on a space type), and in my usage I didn't encounter these constructors. If this is wished, I can more extensively test how these behave with a multifusion sector. Most are easy to tell beforehand that they can't be used. For example, anything requiring non-trivial braiding cannot be done.

[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.

[lkdvos]

This should also just be replaced with insertleftunit and insertrightunit calls

[lkdvos]

Same comment here about removeunit