Repository navigation
Construct fusion tree blocks from the shorter side, and group the cached trees in fusionblocks
#581
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
6c14e69
2130dc3
5d26ce3
c643ae2
5837d51
2cb2bf7
ed344a5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -210,13 +210,19 @@ grouped by their uncoupled charges. | |
| function fusionblocks(W::HomSpace) | ||
| I = sectortype(W) | ||
| N₁, N₂ = numout(W), numin(W) | ||
| isdual_src = (map(isdual, codomain(W)), map(isdual, domain(W))) | ||
| fblocks = Vector{FusionTreeBlock{I, N₁, N₂, fusiontreetype(I, N₁, N₂)}}() | ||
| for dom_uncoupled_src in sectors(domain(W)), cod_uncoupled_src in sectors(codomain(W)) | ||
| fs_src = FusionTreeBlock{I}((cod_uncoupled_src, dom_uncoupled_src), isdual_src) | ||
| isempty(fs_src) || push!(fblocks, fs_src) | ||
| F = fusiontreetype(I, N₁, N₂) | ||
| # group the (cached) fusion trees of `W` by their uncoupled sectors | ||
| groups = Dict{Tuple{NTuple{N₁, I}, NTuple{N₂, I}}, Vector{F}}() | ||
| for (f₁, f₂) in fusiontrees(W) | ||
| push!(get!(Vector{F}, groups, (f₁.uncoupled, f₂.uncoupled)), (f₁, f₂)) | ||
| end | ||
| return fblocks | ||
| # in the order of `sectors(domain(W))` (outer) and `sectors(codomain(W))` (inner), each of | ||
| # which runs fastest over its first space | ||
| position(V) = Dict{I, Int}(s => i for (i, s) in enumerate(sectors(V))) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we need to map every sector to an
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We could do this, but I checked and the Also note I fixed an issue with the sorting below, where previously the
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. let me investigate if we can actually speed up the comparisons a bit, I think there are quite a few fast paths that might be able to get this closer together. It's also just about this looking a bit "ugly" or complicated, if we could just use comparison it's a bit easier to read
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this specifically for the SU(3) case by the way? I would guess the
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. QuantumKitHub/TensorKitSectors.jl#115 Mind giving it a go with that included? |
||
| codpos, dompos = map(position, codomain(W)), map(position, domain(W)) | ||
| rank((u₁, u₂)) = (reverse(map(getindex, dompos, u₂)), reverse(map(getindex, codpos, u₁))) | ||
| us = collect(keys(groups)) | ||
| return map(i -> FusionTreeBlock(groups[us[i]]), sortperm(map(rank, us))) # each rank computed once | ||
| end | ||
|
|
||
| function diagonalblockstructure(W::HomSpace) | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have an idea how much time this takes? If it is too much, there might be a point in caching the combination of
fusiontreesandfusionblocksfor non-abelian tensorsThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After c643ae2: 0.43 s (fℤ₂ × U(1) × SU(3)) and 4.15 s (fℤ₂ × U(1) × SU(2) × U(1)) for all spaces of one CTMRG iteration. With #580 that is 4–8 % of building the braid transformers, and it runs before the threaded part. One iteration calls
fusionblocks550 times on 396 distinct spaces, so caching alone saves about 30 %. Caching it together withsectorstructurewould also give the tree indices of each block, which saves thegettokenlookups of the source trees inGenericTreeTransformer.Do you think it's worth looking into that for a follow-up?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might actually be worth it, and feels a bit more uniform since very often
fusionblocksis actually what you want for the non-abelian things while we are only cachingfusiontrees