Modular parameter for transfer matrices

[Yue-Zhengyuan]

This PR adds ability to extract the modular parameter of transfer matrices.

• The most basic question is calculating the "elementary" modular parameter for a square (L x L) patch of the network, which is now included as an additional field of CFTData. This is done by the new function extract_tau_and_c, which can also get the central charge as a by-product.
• The correct modular parameter for the various transfer matrices ([1, 4, 1], [1, 8, 1], etc.) are calculated from the elementary τ0.

In particular, this resolves issues of extracting CFT data for anisotropic models whose elementary modular parameter is not equal to i (example: anisotropic Ising model). Thanks to @Chenqitrg for helpful discussions!

Secondary changes

• A new struct CFTTransferMatrix is introduced to better organize the related code and reduce redundancy.
• StructuredVector gains convenient constructors from TensorKit.SectorVector or Dict and broadcasting support, making manipulation of CFT transfer matrix eigenvalues cleaner.
• The scaling dimensions returned from shape [1, 1, 0] is now also a StructuredVector grouped by symmetry sectors.

Remark

When τ0 ≠ i, the quartet [h, L, x, τ0] alone is actually not enough to fully determine the modular parameter of the transfer matrix. One also need to know its orientation.

There are four orientations which, in the isotropic case, are related by 90-degree rotations and therefore equivalent. But after we tilt the spacetime with non-isotropic τ0, the four orientations become different. For now we just accept that the orientation is implicitly determined by how we construct it in the code.

TODO

For TRG/loop-TNR, one RG step rotates the network in counter-clockwise direction by 45/135 degrees. One then knows that τ0 will be mapped to (τ₀ - 1) / (τ₀ + 1) (TRG) or (1 + τ₀) / (1 - τ₀) (loop-TNR). This difference annoys me - we may consider unify them in the future.

[codecov]

Codecov Report

❌ Patch coverage is 87.87879% with 32 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/utility/transfer_matrix.jl	83.58%	22 Missing ⚠️
src/utility/structuredvector.jl	80.00%	6 Missing ⚠️
src/utility/cft.jl	96.00%	4 Missing ⚠️

Files with missing lines	Coverage Δ
src/schemes/looptnr.jl	97.96% <ø> (ø)
src/schemes/trg.jl	91.66% <ø> (ø)
src/utility/cft.jl	91.66% <96.00%> (+3.04%)	⬆️
src/utility/structuredvector.jl	80.00% <80.00%> (+16.66%)	⬆️
src/utility/transfer_matrix.jl	83.58% <83.58%> (ø)

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

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

[VictorVanthilt]

I find it quite hard to follow what's going on here, can you provide me with a (couple of) good reference(s) on this topic?

[Yue-Zhengyuan]

I wrote a note here. It is inspired by a PhD thesis (not available online) of one of our former group member, but even there the details are not fleshed out clearly. If you think it's good we can add it to the package documentation.

I have also figured out the cause of test error with XY model:

• In the KT phase, the second eigenvalue in the Trivial sector becomes small, causing numerical inaccuracies. I need to use the leading eigenvalue from another sector.
• In the symmetric phase (c = 0), all eigenvalues of the four 2x2 transfer matrices are zero except the leading one. So the formula for τ doesn't work. In this case I we can only immediately return τ = i if we detected c = 0 (which can be recognized when the leading eigenvalues from the four 2x2 transfer matrices are almost equal - see the note for the reason).

[Yue-Zhengyuan]

The XY case should now be fixed by using a better way to solve for τ, which now only need the leading eigenvalue from the transfer matrices. Actually, it can already extract the central charge as well. It is explained in my updated note.

[VictorVanthilt]

Do you want to add the central charge extraction, or can i merge this in this state?

[Yue-Zhengyuan]

It can be merged as is. Central charge can be handled later when I figure out how to do it correctly for fermions.

[Yue-Zhengyuan]

@lkdvos Is it a known issue that things inside a @tensor begin ... end block are unable to be covered by codecov?

[Yue-Zhengyuan]

@VictorVanthilt Some new ideas:

• Do you think it will be more efficient to use four 1-row x 2-column (instead of 2x2) transfer matrices to extract τ and c without losing precision? This can be done with some minor modifications.
• I have successfully tested elementary_modular_parameter for fermions elsewhere. If you can wait a bit longer I can include a central charge test with Gross-Neveu.

[VictorVanthilt]

I believe the accuracy of the spectrum is not affected by the amount of rows, only by the amount of columns (circumference of the tube geometry). So I can imagine the calculation would be faster if we only use 1x2 patches instead of 2x2.

Do you have any idea if the elementary_modular_parameter calculation adds a lot of time to the CFTData calculation time right now?

[lkdvos]

I definitely didn't know that this was an issue, I never noticed it and we definitely do similar constructions in other places. Might be worth trying to come up with a minimal example to double check

[leburgel]

@lkdvos Is it a known issue that things inside a @tensor begin ... end block are unable to be covered by codecov?

I've also noticed this in PEPSKit.jl (see for example here), but never managed to work around this.

[lkdvos]

Hmmm, it might actually be about how the macro works, ill have a look to see if I can patch something

[lkdvos]

Could someone open an issue on the TensorOperations repository for this so I don't forget

[Yue-Zhengyuan]

@lkdvos Now opened at QuantumKitHub/TensorOperations.jl#280.

[Yue-Zhengyuan]

Do you have any idea if the elementary_modular_parameter calculation adds a lot of time to the CFTData calculation time right now?

I need some time to do a proper benchmark...

[Yue-Zhengyuan]

@VictorVanthilt Now that elementary_modular_parameter is going to return both tau and c, do you suggest a better name for the function?

[VictorVanthilt]

get_tau_and_c? 😅

[Yue-Zhengyuan]

get_tau_and_c? 😅

Guess I have no better choices...

For benchmark with D = 12, shape = [sqrt(2), 2sqrt(2), 0], the modular parameter calculation takes almost half of the time (actually kind of expected, because the diagonal transfer matrices have size $D^4 \times D^4$):

area_term:                4.274 ms
elementary_modular_param: 45.270 ms
spec:                     75.128 ms
CFTData total:            121.082 ms

elementary_modular_parameter is 37.4% of CFTData time

For larger shapes the numbers will look better. I'll still try to push the limits.

[Yue-Zhengyuan]

I now have a faster way to get tau, using two [1, 2, 1] and two [√2, √2, 0] (@Chenqitrg's idea) transfer matrices. In the same benchmark, it only uses ~ 7 ms (compared to ~ 45 ms previously). However, since [√2, √2, 0] have a smaller width, the accuracy is slightly degraded and some tests cannot pass.

Maybe we provide both options, with the faster 1x2 based method as default?

[VictorVanthilt]

This is great work, I especially like the new internals for CFTTransferMatrix, very clean.
Thanks a lot!