search

JaviLoPiq / ConstrainTNet.jl

Constrained Tensor Networks
Other
0 stars 1 forks source link

Question about what was modified in ITensors.jl #1

Closed mtfishman closed 2 months ago

mtfishman commented 3 months ago

Hi @JaviLoPiq, Jing, I just noticed your preprint, it looks like a really interesting technique and a nice use of novel symmetries in tensor networks.

Out of curiousity, could you summarize what you needed to modify in ITensors.jl in order to implement this? It would be nice to know from our end so we can make it easier for advanced users like you to implement techniques like this without needing to fork the project, say by overloading some fusion rules.

JaviLoPiq commented 3 months ago

Hi @mtfishman, thanks for the interest in our work! Any feedback is welcome.

I'd love to help as much as possible porting out any features of the forked ITensors.jl version. First and foremost, note that it is built on top of v0.3.41, so that already may pose some backward compatibility issues.

The most important modification was the inclusion of a new QRegion struct, which is found in qn/qregion.jl. As explained in the paper it is a tensor block label, just as quantum numbers. However, unlike quantum numbers, these labels follow a different fusion rule. This requires modifying the flux function in indexset.jl, as well as nzblocks in qnindexset.jl.

A design choice was made in order to reuse the most out of what's already implemented for QNs. This required a new abstract type QNRegion in qn/qnregion.jl, having QRegion and QN as subtypes, and updating various function signatures that depended on QN to use the more general QNRegion. These updates were done in qnindexset.jl, qnindex.jl, and qnitensor.jl. Other important changes include making QNBlock a parametrized type in qnindex.jl to account for the two new subtypes of QNRegion. The rest of changes in qnindex.jl follow from this type change.

Happy to go in more detail.

mtfishman commented 3 months ago

The breaking changes in ITensors 0.4, 0.5, and 0.6 are fairly benign (https://github.com/ITensor/ITensors.jl?tab=readme-ov-file#news) so I wouldn't expect that upgrading would be a problem.

Thanks for the summary. We are currently rewriting the entire NDTensors.jl backend as well as the QN type to simplify the code, make it more composable and flexible, and incorporate non-abelian symmetries. I think our new design will make it easier to implement what you describe by allowing users to define a custom symmetry type and write custom fusion rules, which is how we are accommodating having different types of symmetries like abelian and non-abelian symmetries. Your algorithm will be good for us to keep in mind as a novel application that is outside of the usual symmetries considered in physics applications.