Skip to content

Refactor _step_hotrg(3d)_x(y)#107

Merged
VictorVanthilt merged 3 commits intoQuantumKitHub:masterfrom
Yue-Zhengyuan:refactor-hotrg
Oct 17, 2025
Merged

Refactor _step_hotrg(3d)_x(y)#107
VictorVanthilt merged 3 commits intoQuantumKitHub:masterfrom
Yue-Zhengyuan:refactor-hotrg

Conversation

@Yue-Zhengyuan
Copy link
Copy Markdown
Member

This PR refactors the functions _step_hotrg(3d)_x(y) by moving the part to find the projectors out of them, so they can be reused by impurity HOTRG (motivated by #105).

@Yue-Zhengyuan Yue-Zhengyuan mentioned this pull request Oct 14, 2025
@Yue-Zhengyuan
Copy link
Copy Markdown
Member Author

Yue-Zhengyuan commented Oct 14, 2025

@VictorVanthilt I now tend to believe that the macOS test failure (again on the accuracy of Ising scaling dimension) is caused by Julia 1.12. Maybe you can follow other QuantumKitHub packages to set up test with the LTS version (currently it is 1.10.10) of Julia?

@VictorVanthilt
Copy link
Copy Markdown
Member

We had issues like this before, where mac os was actually the only one not failing. There is some difference in between apple silicon and intel/amd chips when it comes to floating point arithmetic. Previously it was showing up because we were dividing really small (on the order of machine precision) numbers.

I will add testing with LTS to the test suite to check if it is indeed a julia 1.12 issue.

@Yue-Zhengyuan
Copy link
Copy Markdown
Member Author

Before that let's refrain from merging master into this branch.

@VictorVanthilt
Copy link
Copy Markdown
Member

#108

@Adwait-Naravane
Copy link
Copy Markdown
Contributor

I think this _get_hotrg_projector() function needs to be generalised at some point to allow for different algorithms to construct projectors like in the anisotropic case, using QR decompositions to construct oblique projectors (like in appendix A of the Boundary TRG paper).

@VictorVanthilt
Copy link
Copy Markdown
Member

Can you merge the TNRKit master branch into this one, then I can merge this.

@Yue-Zhengyuan
Copy link
Copy Markdown
Member Author

Considering @Adwait-Naravane's comment, should we rename BTRG to BwTRG to avoid ambiguity? (Bond-weighted vs boundary)

@VictorVanthilt
Copy link
Copy Markdown
Member

The Boundary TRG paper was first (2019) at calling their method BTRG, the Bond-weighted TRG paper also calls their method BTRG but only did so in 2020.

So @dartsushi, what do you think?
I suggest that if we implement the Boundary Tensor Renormalization Group:

  • We use BWTRG for what is now called BTRG in TRNKit.
  • We call Boundary Tensor Renormalization Group BoundaryTRG

For now keeping BTRG as is okay for me.

@VictorVanthilt VictorVanthilt merged commit 98b1fd0 into QuantumKitHub:master Oct 17, 2025
8 checks passed
@dartsushi
Copy link
Copy Markdown
Contributor

I believe people refer to Bond-weighted TRG as BTRG more often nowadays. I would like to call this the other as BoundaryTRG and keep BTRG as it is

@VictorVanthilt
Copy link
Copy Markdown
Member

Okay thanks!

@Yue-Zhengyuan Yue-Zhengyuan deleted the refactor-hotrg branch October 17, 2025 08:20
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