Prevent construction of multifusion tensors with incompatible coloring

[borisdevos]

Deals with #514, at least partially.
Now we have

julia> Wis
(Vect[IsingBimodule]((1, 1, 0) => 1) ⊗ Vect[IsingBimodule]((1, 1, 0) => 1)) ← Vect[IsingBimodule]((2, 2, 0) => 1)

julia> blocksectors(Wis)
0-element Dictionaries.Indices{IsingBimodule}

which behaves the same way as

julia> Wu1
Rep[U₁](1 => 1) ← (Rep[U₁](0 => 1) ⊗ Rep[U₁](0 => 1))

julia> blocksectors(Wu1)
0-element Dictionaries.Indices{U1Irrep}

Edit: decided to actually prevent construction of these kinds of tensors at the level of the product space and hom space.
Since this was incompatible with the previous implementation of unitspace, this now errors for GenericUnit sector types.

[lkdvos]

I do think this is probably quite a big performance hit right in the hot path of the fusiontree constructors though, I don't think there is typically a fast implementation of this. Additionally, I was kind of expecting to convert more things to Nsymbol, to actually make them error if the fusion is disallowed?

[borisdevos]

I'm misunderstanding then what kind of behavior we want. So we want Nsymbol checks there, such that forbidden fusion trees shouldn't ever be able to be looked at? And then at the tensor construction level, when colors mismatch this should throw an error, thus preventing constructing forbidden tensors?

[lkdvos]

I think that was what I was expecting, especially since we decided Nsymbol errors instead of returning 0

[codecov]

Codecov Report

❌ Patch coverage is 94.28571% with 4 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/spaces/vectorspaces.jl	84.21%	3 Missing ⚠️
src/spaces/homspace.jl	96.29%	1 Missing ⚠️

Files with missing lines	Coverage Δ
src/spaces/gradedspace.jl	72.52% <100.00%> (-20.01%)	⬇️
src/spaces/productspace.jl	81.54% <100.00%> (-6.36%)	⬇️
src/tensors/tensoroperations.jl	96.53% <100.00%> (ø)
src/spaces/homspace.jl	89.63% <96.29%> (-1.74%)	⬇️
src/spaces/vectorspaces.jl	65.07% <84.21%> (-4.60%)	⬇️

... and 21 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]

Other than the comments, looks good, thanks for looking into this!

[lkdvos]

I made another small change that handles more edge cases, in particular I was kind of worried about your any(isempty(...))) checks, in the sense that while these don't allow us to check that particular factor, it still means we can check the other ones, so I've slightly refactored that, basically treating isempty spaces as a wildcard.

[Jutho]

I would be more explicit and call this function _leftrightunit

[Jutho]

Also, since we are now checking a lot, I think the question is whether this check should already appear in the GradedSpace constructors. Currently, I can still construct something like GradedSpace(c=>1 for c in allunits(I)), but as soon as I take tensor products with this space, I get errors? That does not sound like the correct behaviour.

[lkdvos]

implemented. This was slightly annoying since our tests were not fully compatible with that, but I think I managed to bypass this.

[borisdevos]

Just to motivate why I didn't do it at the GradedSpace level: I treat GradedSpace as some semi-simple object of a sector type. Only from ProductSpace onwards is it really seen as "a leg of a tensor". But it's fine as-is

[Jutho]

Seems to cause an error in some tests, but I don't understand/see where it is coming from. The line numbers in test/symmetries/singletree.jl seem off.

[lkdvos]

Can confirm the test failures are solely due to v1 switching from 1.12 to 1.13, so I'll address these in separate PRs to keep things contained. This should then be good to go once the other tests turn green, and I'll merge.

[borisdevos]

Thanks a lot for your help on this!

[lkdvos]

rebase/remerge is not necessary, will just wait for tests to run and then merge into main directly.