Repository navigation
Conversation
Codecov Report❌ Patch coverage is
... and 1 file with indirect coverage changes 🚀 New features to boost your workflow:
|
Keep full-MPO environment transfers and cache independent effective-Hamiltonian sides and fixed Jordan data for the duration of the solve. Advance environments at each local window and prepare only the two-site terms needed by plain DMRG2. Consolidate cache ownership, constrained preparation types, shared operator storage, expansion handling, and regression coverage.
Add nearest-neighbor, sparse, and chemistry-surrogate workloads, scaling measurements, isolated operator-construction accounting, profiles, and numerical agreement checks.
Collect full-MPO transfer comparisons, sweep and construction timing, CPU and allocation profiles, GC accounting, and pair-only preparation results with numerical agreement checks.
Add isolated snapshot orchestration, shared serialized inputs, dependency and compilation audits, complete-call and four-sweep timings, GC-aware stage profiles, state validation, and reproducible raw results.
…fy the cache The cached AC2 preparation contracted the full GL*A (and A*GR) intermediate with B (and C). Block contractions permute every stored channel block of that large intermediate, making AB and CA 3-4x slower than the original constructor, which contracts the small operator-only products A1*B2 and C1*A2 first. Cache those products per pair and contract them with GL/GR, and build the restricted continuing terms directly. One cached preparation now costs at most one original construction, so the cache does half the work per sweep. Also simplify the cache: records keep only the prepared sides (unprepared queries rebuild from GL/GR), DMRG with expansion caches one-site contributions only, and the local_only refresh and shared-intermediate plumbing are removed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Generated outputs (CSVs, figures, profiles, results write-ups, metadata) now live in the ignored benchmark/results directory. Remove the one-off investigation scripts and the remainder/profile leftovers in dmrg_cache.jl, keeping the shared models, the ordinary-versus-cached sweep benchmark, and the main comparison harness with its frozen manifest and self-contained setup instructions. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…riven absorbs
- Replace the one_site/two_site flags with nsites; records hold a single
contribution field, consistently typed as Union{Missing, P}.
- Drop JordanOperatorData and the per-site JordanSiteData: the cache keeps only
the operator-only pair products (built for DMRG2 only) and side builders take
the JordanMPOTensor directly, like the original constructors.
- Replace the per-algorithm absorb schedule with center_window!, which absorbs
the neighbours of a window only if they changed since the records were built.
The cache tracks its own dependencies, since read-only callbacks may refresh
the ordinary manager's. Absorb counts and results match the previous schedule.
- leftenv/rightenv use something(), restoring type stability with a clear error.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…action tests - Build the fresh Jordan AC/AC2 constructors from the same left/right halves the sweep cache prepares, removing the duplicated term construction. - Move the sweep cache into src/environments/dmrg_sweep_cache.jl. - Rebuild the cache with a warning when a finalizer modifies the state or environments, instead of asserting. - Test cached effective Hamiltonians against fresh environments at every local window and ground-state energies against exact diagonalization; check operator reuse structurally instead of with an instrumented backend. - Stop tracking the benchmark scripts. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Generic MPO derivatives prepare their left and right halves through `left_half`/`right_half`, dispatched on the derivative type, as the Jordan derivatives do. - Rename the sweep cache to `DMRGEnvironments` (src/environments/dmrg_envs.jl). It keeps only the prepared halves and reads `GL`/`GR` from its parent `FiniteEnvironments`; site transfers are `transfer_leftenv!`/`transfer_rightenv!` as for the infinite environments. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each prepared half is rebuilt when queried if the environment it was prepared from has been replaced; the environments themselves come from the parent `FiniteEnvironments` and its dependency tracking. This removes the explicit window updates, the separate dependency vectors and the finalizer check. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
FiniteEnvironments now stores the prepared left and right halves of the AC and AC2 effective Hamiltonians, with an interface `lefthalf`/`righthalf` on top of `leftenv`/`rightenv`. Halves are prepared lazily per kind and rebuilt when the environment they were prepared from is replaced, so every algorithm on finite environments reuses them and DMRGEnvironments, together with its wrapping in the DMRG driver, is removed. The storage types are derived from the environment and operator types. The Jordan MPO derivatives no longer require the bra and ket to be equal: the not-started left and finished right environments are kept as explicit boundary tensors when they are not identities. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
calc_galerkin takes `prepare = false`; with `prepare = true` and environments that cache prepared halves, the single-site derivative is assembled from those halves, which the effective Hamiltonian at that site reuses when they are still current (after bond expansion, the half on the unchanged side). Single-site DMRG passes `prepare = true` and otherwise matches main. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each half of a JordanMPO derivative now folds its onsite, not-started and finished
terms into its own largest term when it is built, so prepare_operator!! only prepares
the continuing term, and the fresh and cached constructions share the same builders.
The half helpers dispatch on the window size Val{N} and are named after their callers
(prepare_operator_left/right, jordan_hamiltonian_left/right), the four
_*_hamiltonian_from_halves methods become hamiltonian_from_halves, and the Galerkin
error in DMRG is computed inline.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With OptimalExpand, single-site DMRG takes the Galerkin error from the projected two-site update the expansion forms anyway, contracted with the isometry on the other site of the bond, instead of building the single-site derivative separately. The expansion itself is split off as expand_from_projection!. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Folding the onsite, not-started, finished and operator-only terms into the largest term of each half allocates a temporary of that term's size per fold, and only pays off for an operator that is applied repeatedly. Unprepared derivatives (`AC_projection`, `AC2_projection`, `calc_galerkin`) now keep these terms separate, as before the halves were introduced, while the cached halves and `prepare = true` still fold them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
FiniteEnvironmentsnow caches the prepared left and right halves of theACandAC2effective Hamiltonians, so finite algorithms stop re-preparing the same operator halves at every local update.Changes
lefthalf/righthalf(Val(N), envs, site, ψ)sit on top ofleftenv/rightenv. Each half is prepared lazily and rebuilt when the environment it came from is replaced.AC_hamiltonian/AC2_hamiltonianwithprepare = trueassemble the operator from the cached halves throughhamiltonian_from_halveswhenever the environments provide them.prepare_operator_left/prepare_operator_righthalves, joined byassemble_operator_halves.prepare_operator!!only prepares the continuing term. Unprepared derivatives are applied only once, so they skip the folding.jordan_hamiltonian_left/jordan_hamiltonian_right.calc_galerkintakesprepare = false. Withprepare = true, it builds the derivative from the cached halves, which the effective Hamiltonian built afterwards at the same site reuses. Single-site DMRG without bond expansion uses this, so the error costs no separate projection.OptimalExpand, the single-site derivative is the two-site projection the expansion forms anyway, contracted with the isometry on the other site of the bond.changebond!forOptimalExpandis split intoAC2_projectionandexpand_from_projection!, and DMRG feeds one projection to both the error and the expansion.test/hamiltonian/prepared_halves.jlcompares cached against freshly built effective Hamiltonians at every window, for several operator types including bra ≠ ket, and checks DMRG with and without expansion.Performance
Measured on Rusty: exclusive genoa nodes (AMD EPYC 9474F), single-threaded, Julia 1.13.2, main at 76a58d7 with identical dependency versions.
Models:
DMRG and DMRG2 without expansion
This table was measured at de162e56. The later commits only touch the Galerkin error and
OptimalExpand, and a separate run of single-site DMRG at the final commit matched it to within 0.5% for every model.In single-site DMRG, preparing the halves moves time from the eigensolver to the update, where the halves are now built, and the eigensolver gains more than that.
Single-site DMRG with
OptimalExpandThis uses
alg_expand = OptimalExpand(; trunc = truncrank(χ ÷ 8))andtrunc = truncrank(χ). Most of the gain comes from reusing the expansion's projection for the Galerkin error, which removes about a fifth of the time outside the eigensolver. Computing the error from the cached halves instead was slower, because the expansion leaves half of what it prepared stale.Trade-offs
AC_projection,AC2_projection,calc_galerkinover a whole chain) allocate as on main with BlockTensorKit ≥ 0.3.22, and their run time is within the benchmark's resolution.BlockTensorMapslices used to allocate a full set of blocks only to discard them; Slice dense block tensors without allocating blocks BlockTensorKit.jl#88 (released in 0.3.22) removed that.AC_projectionAC2_projectioncalc_galerkinAC_projectionAC2_projectioncalc_galerkinAC_projectionAC2_projectioncalc_galerkinThe per-run times of both overlap at χ = 256.
🤖 Generated with Claude Code