Stack position
6 of 6. This PR should be based on the QUBODrivers/JuMP exposure PR.
Goal
Add documentation, examples, and benchmark coverage that make it clear when the PEPS backend should be used, how it compares to the current DMRG backend, and what limitations come from the SpinGlassPEPS paper.
Context
The integration should not imply that SpinGlassPEPS supersedes TenSolver. The paper reports that the PEPS branch-and-bound approach is useful for structured quasi-2D Ising/Potts problems but has stability/performance limitations on large random Pegasus/Zephyr instances. It can be competitive or better on simpler square/king-style lattices and some planted/tile-style instances.
Docs and benchmarks should set user expectations correctly.
Documentation tasks
Add or update docs covering:
-
Backend overview
- DMRG backend: default, general QUBO/PUBO path.
- PEPS backend: optional, experimental, structured quasi-2D path.
-
Installation
- Explain any optional extension or bridge package installation.
- Note Julia compatibility requirements if the PEPS bridge requires Julia 1.11.
- Note GPU dependencies are optional and not required for small CPU tests.
-
Supported topologies
- square grid
- king grid
- Pegasus if implemented
- Zephyr if implemented
-
Usage examples
- direct Julia API example for a small square grid
- JuMP/QUBODrivers example selecting
backend = :peps
- metadata inspection example
-
Parameter guide
beta: higher values sharpen low-energy resolution but can destabilize contraction.
bond_dim: larger boundary MPS bond dimension can improve contraction but increases cost.
max_states: branch-and-bound width.
cutoff_prob: pruning threshold.
- transformations: trying lattice rotations/reflections can improve results.
- truncation/local dimension reduction: can reduce cost but may remove globally optimal configurations.
-
Limitations
- PEPS is not appropriate for arbitrary dense QUBOs.
- Approximate contraction can fail.
- Randomized SVD/zipper methods may introduce run-to-run variability.
- GPU memory can limit feasible bond dimensions on Pegasus/Zephyr.
- Current TenSolver DMRG remains the default general-purpose backend.
Benchmark tasks
Add reproducible benchmark scripts under a non-CI path, for example:
benchmarks/peps_square.jl
benchmarks/peps_king.jl
benchmarks/peps_pegasus_small.jl if Pegasus support exists
Benchmarks should compare:
- TenSolver DMRG backend
- PEPS backend
- brute force for tiny instances only
Metrics:
- best objective value
- objective gap from brute force when available
- runtime
- number of returned states
- PEPS metadata such as largest discarded probability and selected transformation
Keep benchmark scripts deterministic where possible:
- set random seeds
- use CPU defaults unless explicitly testing GPU
- clearly annotate expected runtime
Tests
Do not add long benchmarks to normal CI.
Add lightweight doc or smoke tests only:
- small example runs within a short time budget
- PEPS examples gated if optional dependency is unavailable
- DMRG docs continue to run without optional PEPS dependencies
Acceptance criteria
- Docs explain backend selection and limitations clearly.
- At least one direct API PEPS example is documented.
- At least one JuMP/QUBODrivers PEPS example is documented if PR 5 implemented that path.
- Benchmark scripts exist but are not part of default CI.
- Existing docs for the DMRG backend remain accurate.
Out of scope
- Claiming performance superiority.
- Reproducing the full arXiv benchmark suite.
- Requiring CUDA in normal CI.
Stack position
6 of 6. This PR should be based on the QUBODrivers/JuMP exposure PR.
Goal
Add documentation, examples, and benchmark coverage that make it clear when the PEPS backend should be used, how it compares to the current DMRG backend, and what limitations come from the SpinGlassPEPS paper.
Context
The integration should not imply that SpinGlassPEPS supersedes TenSolver. The paper reports that the PEPS branch-and-bound approach is useful for structured quasi-2D Ising/Potts problems but has stability/performance limitations on large random Pegasus/Zephyr instances. It can be competitive or better on simpler square/king-style lattices and some planted/tile-style instances.
Docs and benchmarks should set user expectations correctly.
Documentation tasks
Add or update docs covering:
Backend overview
Installation
Supported topologies
Usage examples
backend = :pepsParameter guide
beta: higher values sharpen low-energy resolution but can destabilize contraction.bond_dim: larger boundary MPS bond dimension can improve contraction but increases cost.max_states: branch-and-bound width.cutoff_prob: pruning threshold.Limitations
Benchmark tasks
Add reproducible benchmark scripts under a non-CI path, for example:
benchmarks/peps_square.jlbenchmarks/peps_king.jlbenchmarks/peps_pegasus_small.jlif Pegasus support existsBenchmarks should compare:
Metrics:
Keep benchmark scripts deterministic where possible:
Tests
Do not add long benchmarks to normal CI.
Add lightweight doc or smoke tests only:
Acceptance criteria
Out of scope