Prevent construction of multifusion tensors with incompatible coloring by borisdevos · Pull Request #515 · QuantumKitHub/TensorKit.jl

borisdevos · 2026-08-26T12:49:30Z

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 · 2026-08-26T14:07:27Z

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 · 2026-08-26T14:14:12Z

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

codecov · 2026-08-26T14:46:27Z

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
src/spaces/gradedspace.jl	`92.57% <100.00%> (+0.04%)`	⬆️
src/spaces/homspace.jl	`92.98% <100.00%> (+1.61%)`	⬆️
src/spaces/productspace.jl	`88.75% <100.00%> (+0.85%)`	⬆️
src/spaces/vectorspaces.jl	`71.31% <100.00%> (+1.63%)`	⬆️
src/tensors/tensoroperations.jl	`97.37% <100.00%> (ø)`

... and 8 files with indirect coverage changes

🚀 New features to boost your workflow:

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

This reverts commit 5f9e5be.

…into bd/fusiontree-iterate

lkdvos

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

lkdvos · 2026-09-06T07:00:28Z

+
+    @inbounds for i in 1:(N - 1)
+        _rightunit(spaces[i]) == _leftunit(spaces[i + 1]) ||
+            throw(ArgumentError(lazy"spaces $(i) and $(i + 1) have incompatible coloring"))


Do we want this to be SpaceMismatch, or should we just introduce a new error type for this? Do you also want to print which spaces are the offending ones?
This comment also holds for the HomSpace checks

Changed this to spacemismatch and return the spaces in both cases

lkdvos · 2026-09-06T07:06:40Z

+    return HomSpace{S, P1, P2}(codomain, domain)
+end
+
+function _check_unit_compatibility(codomain::ProductSpace{S}, domain::ProductSpace{S}) where {S <: ElementarySpace}


I think there are some missing edge cases that are not really handled correctly/consistently here, mostly for the case where leftunit or rightunit cannot be inferred. In principle it is allowed (?) to create 0-dimensional ElementarySpace objects, which in this implementation will always error even though no violation is detected. (In some sense this is because here you check for validity and error if it cant be proven, while you probably want to error if invalidity can be proven).

The only reason I can think of why this might be important is that if you have an SVD that accidentally kills all sectors, you end up with a 0-dim leg on the S which will now error on the space constructions, even though nothing really went wrong

You're right, I was also not dealing with length-1 product spaces correctly. My fix for the 0d ones fixed both automatically. Importantly though, I determined that when one of the spaces is 0d, there's no need to check colorings. This is based on the sectors of the total product space always being empty, regardless of valid or invalid coloring, and things like blocksectors and fusiontrees are built on this.

lkdvos · 2026-09-06T07:07:21Z

+semisimple unit structure, this returns `true` if `V` is isomorphic to either the left, right or
+semisimple unit space.


https://en.wikipedia.org/wiki/Semi-simplicity

[edit] it seems like wikipedia isn't even consistent with itself... (https://en.wikipedia.org/wiki/Semisimple_module)

The Bible doesn't hyphenate it, so I'll follow suit :)

Jutho · 2026-09-07T22:04:10Z


 function unitspace(S::Type{<:GradedSpace{I}}) where {I <: Sector}
+    UnitStyle(I) isa GenericUnit &&
+        throw(ArgumentError("Cannot construct unit space for sector types with semisimple unit structure."))


Would it be useful to actually check if length(allunits(I)) > 1 before erroring? That way simply declaring a normal fusion category as GenericUnit would not immediately trigger the error.

I think instead of this, we should add a test in the TKS testsuite checking that GenericUnit actually agrees with having length(allunits(I)) > 1, precisely to prevent normal fusion categories from having GenericUnit. I don't see why we would want that in the first place.

replace Nsymbol calls or add guards

5f9e5be

lkdvos reviewed Aug 26, 2026

View reviewed changes

borisdevos added 6 commits September 2, 2026 11:26

Revert "replace Nsymbol calls or add guards"

faf03b7

This reverts commit 5f9e5be.

don't allow calling unitspace for genericunit

4bd0615

check coloring in genericunit productspace construction

8c9ae8d

do the same for homspace

d400193

update tests on new unitspace behavior + new tests on color checks

e59dc01

Merge branch 'main' of https://github.com/QuantumKitHub/TensorKit.jl …

c01d76d

…into bd/fusiontree-iterate

borisdevos changed the title ~~Replace Nsymbol calls or add guards in fusion tree iteration~~ Prevent construction of multifusion tensors with incompatible coloring Sep 2, 2026

lkdvos reviewed Sep 6, 2026

View reviewed changes

borisdevos added 5 commits September 6, 2026 16:27

deal with 0-dimensional product spaces + single product spaces for free

3ba8b43

dual, better error messages

67262a0

update tests

4721ea1

update changelog

0f583d5

fix the easy tests to fix

da6d8b1

Jutho reviewed Sep 7, 2026

View reviewed changes

borisdevos added 2 commits September 8, 2026 10:38

don't pass intermediate spaces to the inner constructors

c452372

remove debugging code

bf97eb5

		semisimple unit structure, this returns `true` if `V` is isomorphic to either the left, right or
		semisimple unit space.

Uh oh!

Conversation

borisdevos commented Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lkdvos left a comment

Choose a reason for hiding this comment

Uh oh!

borisdevos commented Aug 26, 2026

Uh oh!

lkdvos commented Aug 26, 2026

Uh oh!

codecov Bot commented Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

lkdvos left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

borisdevos commented Aug 26, 2026 •

edited

Loading

codecov Bot commented Aug 26, 2026 •

edited

Loading