Renormalizer interface for TRG#193
Conversation
Yue-Zhengyuan
commented
Jun 18, 2026
- TRG is now a pure algorithm struct (@kwdef, kwargs-only) storing trunc and maxiter
- New Renormalizer type holds algorithm state (TRGState) and is iterable via Base.iterate
- _renorm_step! dispatches on algorithm type, making the interface extensible
- step! wraps Base.iterate; run! returns (final_state, norms)
- TRGState holds the network tensor; get_tensor extracts it
- Finalizer no longer needed for TRG — users inspect intermediate states via iteration
- gs_degeneracy.jl refactored: primary methods take tensors directly, scheme wrappers delegate
- simple_scheme union updated (TRG removed)
- All tests, examples, and docs updated
- TRG is now a pure algorithm struct (@kwdef, kwargs-only) storing trunc and maxiter - New Renormalizer type holds algorithm state (TRGState) and is iterable via Base.iterate - _renorm_step! dispatches on algorithm type, making the interface extensible - step! wraps Base.iterate; run! returns (final_state, norms) - TRGState holds the network tensor; get_tensor extracts it - Finalizer no longer needed for TRG — users inspect intermediate states via iteration - gs_degeneracy.jl refactored: primary methods take tensors directly, scheme wrappers delegate - simple_scheme union updated (TRG removed) - All tests, examples, and docs updated Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
... and 10 files with indirect coverage changes 🚀 New features to boost your workflow:
|
b943cdc to
5ab04ec
Compare
Yue-Zhengyuan
left a comment
There was a problem hiding this comment.
There are a few things I'm not sure about GSD calculation.
| # Compute normalized eigenvalues | ||
| D, _ = eig_full(T) | ||
| function ground_state_degeneracy(T::AbstractTensorMap, unitcell::Int = 1) | ||
| tm = _row_transfer_matrix(T, unitcell) |
There was a problem hiding this comment.
Do we have examples to check if anti-PBC (NS sector) should be used for fermionic systems?
5ab04ec to
e2c9e50
Compare
|
I suggest to make a release before you decide to merge this PR. |
|
Loop-TNR with the new interface is available at https://github.com/QuantumKitHub/TNRKit.jl/tree/iterable-looptnr. You may also want to have a look if TRG is too simple to justify some design choices. |
|
At this point I'm not conviced this new interface actually gains us anything. The code to run a simulation is now strictly more complicated. We just published a paper in Scipost codebase with code examples that use the run! and finalizer interface. What can you achieve by making the schemes an iterable, that you cannot with the current interface? Either way, if we were to add the iterable interaface as an "expert mode" the previous interface of |
Strictly speaking, nothing is unique the new interface if one uses One of my main goals is getting rid of the finalizers, which only have access to the network tensors at the current RG step, and need users to know in advance its return type in order to construct. The iterator can be |
One of my design philosophy is that the TNR algorithms only stores the parameters, not the tensors. So Anyway, I understand that this is quite a big breaking change. If not accepted in the end, I can still backport some deduplication I made in the process. |
- Rename TNRAlgorithm → TNRParams (pure parameter descriptors)
- New TRGParams <: TNRParams with @kwdef defaults (trunc, maxiter)
- Old TRG{E,S,TT} <: TNRScheme{E,S} restored as state type
- Renormalizer wraps TRGParams + TRG for iterable RG stepping
- Legacy run!(::TRG, trunc, criterion) delegates to new interface
- Add iterable TRG test set alongside restored old-style tests
- Finalizer support removed from TRG run!; use iterable for per-step data
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Your PR no longer requires formatting changes. Thank you for your contribution! |
|
Close in favor of #195. |
|
Discussed with @Yue-Zhengyuan yesterday and feel it is really breaking. But it is natural in the following sense:
|