Skip to content

Conversation

@pbrehmer
Copy link
Collaborator

@pbrehmer pbrehmer commented Jan 21, 2026

In this PR we will finally add a dedicated C4v CTMRG algorithm. I started with the standard version using eigh projectors but we can easily also implement a QR version by making a C4vQRProjector algorithm and the corresponding c4v_projector method. (@Yue-Zhengyuan said he would be up for doing this :-)) This C4v routine is completely differentiable using naive AD, :diffgauge and :fixed mode.

Note that I needed to generalize the gauge_fix method for CTMRGEnvs to not have separate methods for all the C4v stuff. Same thing is true for environment initialization, where it would be nice to have an initialize_environment method where one can dispatch on an algorithm. Here we'll have to wait until we merge #264.

Let me also say that it would eventually be nicer to have a dedicated C4vCTMRGEnv since this would make things cleaner. However, this would entail a larger rewrite of quite a few things, so I propose that I postpone this rewriting and cleaning up process until I have more resources for that again. (In general I feel like we should clean up and refactor some stuff again since the codebase has been growing quite a bit.) Anyways, for now it would be nice to have a working C4v CTMRG that people can use.

This is still very much under construction but I'll finish up things and adjust the test suite tomorrow.

@pbrehmer pbrehmer self-assigned this Jan 21, 2026
@pbrehmer pbrehmer marked this pull request as draft January 21, 2026 19:12
@github-actions
Copy link
Contributor

github-actions bot commented Jan 22, 2026

Your PR no longer requires formatting changes. Thank you for your contribution!

@codecov
Copy link

codecov bot commented Jan 22, 2026

Codecov Report

❌ Patch coverage is 5.01792% with 265 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
src/utility/eigh.jl 0.00% 127 Missing ⚠️
src/algorithms/ctmrg/c4v.jl 0.00% 54 Missing ⚠️
...rithms/optimization/fixed_point_differentiation.jl 0.00% 38 Missing ⚠️
src/algorithms/ctmrg/gaugefix.jl 0.00% 35 Missing ⚠️
src/algorithms/ctmrg/projectors.jl 61.11% 7 Missing ⚠️
src/algorithms/select_algorithm.jl 50.00% 2 Missing ⚠️
src/algorithms/ctmrg/ctmrg.jl 50.00% 1 Missing ⚠️
src/environments/ctmrg_environments.jl 0.00% 1 Missing ⚠️
Files with missing lines Coverage Δ
src/Defaults.jl 85.71% <ø> (ø)
src/PEPSKit.jl 100.00% <ø> (ø)
src/algorithms/ctmrg/sequential.jl 87.30% <ø> (-11.12%) ⬇️
src/algorithms/ctmrg/simultaneous.jl 82.35% <ø> (-17.65%) ⬇️
src/utility/svd.jl 82.99% <ø> (-4.51%) ⬇️
src/algorithms/ctmrg/ctmrg.jl 83.60% <50.00%> (-6.87%) ⬇️
src/environments/ctmrg_environments.jl 47.09% <0.00%> (-34.41%) ⬇️
src/algorithms/select_algorithm.jl 17.39% <50.00%> (-57.61%) ⬇️
src/algorithms/ctmrg/projectors.jl 50.84% <61.11%> (-32.18%) ⬇️
src/algorithms/ctmrg/gaugefix.jl 0.00% <0.00%> (-97.23%) ⬇️
... and 3 more

... and 28 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@Yue-Zhengyuan
Copy link
Member

This PR already involves lots of things. For QR CTMRG, besides getting projectors from QR instead of SVD, the way to enlarge corners is also different. Maybe we focus on the eigh version here only, and handle QR CTMRG in a separate PR.

@pbrehmer
Copy link
Collaborator Author

This PR already involves lots of things. For QR CTMRG, besides getting projectors from QR instead of SVD, the way to enlarge corners is also different. Maybe we focus on the eigh version here only, and handle QR CTMRG in a separate PR.

Completely agree, I anyway assumed this would go into a separate PR. Also I apologize for making this PR so big, I found it somewhat hard to split up the changes needed to make the whole apparatus compatible with C4v CTMRG.

@Yue-Zhengyuan
Copy link
Member

it would eventually be nicer to have a dedicated C4vCTMRGEnv since this would make things cleaner. However, this would entail a larger rewrite of quite a few things

One approach is to make C4vCTMRGEnv (and associated functions) independent from general CTMRG routines (behave like a self-sufficient submodule) for now and just provide a C4vCTMRGEnv-to-CTMRGEnv converter. At least the forward pass should be concise enough. We can think about reusing or rewriting existing CTMRG functions in later PRs. Does this still need a large rewrite?

@codecov
Copy link

codecov bot commented Jan 23, 2026

Codecov Report

❌ Patch coverage is 87.94788% with 37 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
src/utility/eigh.jl 84.96% 20 Missing ⚠️
src/algorithms/ctmrg/c4v.jl 79.71% 14 Missing ⚠️
src/algorithms/select_algorithm.jl 71.42% 2 Missing ⚠️
src/algorithms/ctmrg/projectors.jl 94.73% 1 Missing ⚠️
Files with missing lines Coverage Δ
src/Defaults.jl 85.71% <ø> (ø)
src/PEPSKit.jl 100.00% <ø> (ø)
src/algorithms/ctmrg/ctmrg.jl 90.76% <100.00%> (+0.29%) ⬆️
src/algorithms/ctmrg/gaugefix.jl 97.87% <100.00%> (+0.65%) ⬆️
src/algorithms/ctmrg/sequential.jl 98.41% <ø> (ø)
src/algorithms/ctmrg/simultaneous.jl 100.00% <ø> (ø)
...rithms/optimization/fixed_point_differentiation.jl 93.18% <100.00%> (+1.45%) ⬆️
src/algorithms/truncation/truncationschemes.jl 75.00% <ø> (ø)
src/environments/ctmrg_environments.jl 81.50% <100.00%> (ø)
src/environments/vumps_environments.jl 100.00% <ø> (ø)
... and 5 more

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@pbrehmer
Copy link
Collaborator Author

pbrehmer commented Feb 2, 2026

This is good to go for me now, let me know what you think!

@pbrehmer pbrehmer requested a review from lkdvos February 2, 2026 16:41
@Yue-Zhengyuan
Copy link
Member

I'll unlink issue #258 until we also implement the QR-CTMRG.

Comment on lines 142 to 145
function c4v_renormalize(network, env, projector)
new_edge = renormalize_north_edge(env.edges[1], projector, projector', network[1, 1])
return new_edge / norm(new_edge)
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to further project_hermitian the updated edge with respect to the two environment indices to eliminate numerical errors?

See also the QR-CTM code which does this step.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, I would add a leading underscore (_project_hermitian) to avoid conflict with MAK. But it's just my opinion...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In addition, do we have tests with fermions to see if project_hermitian for edges is correctly defined? I'm not quite confident on the usage of flip there unless it's proven correct.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, thanks! Probably doesn't make too much of a difference but it should stabilize the method.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In addition, do we have tests with fermions to see if project_hermitian for edges is correctly defined? I'm not quite confident on the usage of flip there unless it's proven correct.

Good point, I'm also not sure if flip and _dag work for fermions right away. Would you have an idea for a quick test? (I wouldn't want to add too much more to this PR.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's leave the fermions for a follow up, it will be easier to review what is going on that way.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test idea is simple: create a random fermionic state with C4v, converge the environment with both C4v and asymmetric CTMRG, and evaluate the expectation value of a random operator, which should be the same for both cases. But frankly, I'm not even sure if the current symmetrize! plays nicely with permutation signs from FermionParity.

Copy link
Member

@lkdvos lkdvos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some small final comments, but otherwise good to go!

Comment on lines 142 to 145
function c4v_renormalize(network, env, projector)
new_edge = renormalize_north_edge(env.edges[1], projector, projector', network[1, 1])
return new_edge / norm(new_edge)
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's leave the fermions for a follow up, it will be easier to review what is going on that way.

@pbrehmer
Copy link
Collaborator Author

pbrehmer commented Feb 4, 2026

Should be mergeable now!

@pbrehmer pbrehmer enabled auto-merge (squash) February 4, 2026 15:21
@pbrehmer pbrehmer merged commit 81be8c0 into master Feb 4, 2026
63 checks passed
@pbrehmer pbrehmer deleted the c4v-ctmrg branch February 4, 2026 17:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants