DMRG major update

[afeiguin]

Summary

New optimizations, major speedup, and new methods that will facilitate onboarding other DMRG derivatives

Type of change

• Bug fix
• [X ] New feature or algorithm
• Documentation or tutorial improvement
• Build system / dependency update
• Refactor (no behaviour change)
• Other:

Testing

• [ X] Existing tests pass (ctest --output-on-failure)
• New tests added for changed behaviour
• [X ] Results verified against known reference values or published results
• Tested on Linux
• [ X] Tested on macOS

For simulation code changes

• Physical results match expected behaviour (describe briefly below)
• Parameter files / input format changes are documented
• Relevant tutorial or documentation updated

Checklist

• CI passes (build + tests on all platforms)
• [X ] No new compiler warnings (-Wall -Wextra)
• [X ] Code follows the style of the surrounding code
• [ X] Commit messages are descriptive and in the imperative mood

Related issues

[marcusr2ML]

Tutorials all run. DMRG-05 scripts were moving slower than old code at times it seems. There are spin-1/2's on the boundary too and so I think this throws off what the tutorial suggests should happen vs the plots we get. ALl other tutorials run faster, maybe this should be explored

I also had Claude check over the code and he flagged the issue below. Should be a quick fix if it is anything at all:

⏺ signal_emit(std::string) — undefined behavior (system.h:915)

int n = this->get_signal_id(signal_id);
if(n > 0) return this->signal_emit(n);
// no return when n <= 0

Control falls off the end of a non-void function. n > 0 should also be
n >= 0 — SYSTEM_SIGNAL_GS is pushed first in init_signals()
(system.h:237), so it's index 0, meaning emitting it by name takes the
broken path. get_signal_id() also returns -1 for an unknown name,
which isn't handled.

It doesn't crash — it returns a garbage value that changes with build
flags. I reproduced the same code shape with clang: 

┌───────┬─────────┬───────────────────────┐
│ build │ returns │ signal actually fired │
├───────┼─────────┼───────────────────────┤
│ -O0   │ false   │ no                    │
├───────┼─────────┼───────────────────────┤
│ -O3   │ true    │ no                    │
└───────┴─────────┴───────────────────────┘

That matters because callers use the result as
if (signal_emit(...)) measure(); — so a garbage true proceeds as if the
signal ran, and a garbage false skips the measurement. No error either way.

Fix: 

int n = this->get_signal_id(signal_id);
if(n < 0) return true;   // unknown signal: nothing vetoed
return this->signal_emit(static_cast<size_t>(n));

Not biting yet — nothing in-tree uses the string overload, and as an
uninstantiated template it's never checked, so no -Wreturn-type warning
appears in the build.

[afeiguin]

Hi Marc, I did a git pull and there are no dmrg-05 tutorials. Which ones are you running? So far the dmrg-03 examples work just fine here...

…

On Aug 7, 2026, at 9:55 PM, Marcus Rosales ***@***.***> wrote: @marcusr2ML requested changes on this pull request. Tutorials all run. DMRG-05 scripts were moving slower than old code at times it seems. There are spin-1/2's on the boundary too and so I think this throws off what the tutorial suggests should happen vs the plots we get. ALl other tutorials run faster, maybe this should be explored I also had Claude check over the code and he flagged the issue below. Should be a quick fix if it is anything at all: ⏺ signal_emit(std::string) — undefined behavior (system.h:915) int n = this->get_signal_id(signal_id); if(n > 0) return this->signal_emit(n); // no return when n <= 0 Control falls off the end of a non-void function. n > 0 should also be n >= 0 — SYSTEM_SIGNAL_GS is pushed first in init_signals() (system.h:237), so it's index 0, meaning emitting it by name takes the broken path. get_signal_id() also returns -1 for an unknown name, which isn't handled. It doesn't crash — it returns a garbage value that changes with build flags. I reproduced the same code shape with clang: ┌───────┬─────────┬───────────────────────┐ │ build │ returns │ signal actually fired │ ├───────┼─────────┼───────────────────────┤ │ -O0 │ false │ no │ ├───────┼─────────┼───────────────────────┤ │ -O3 │ true │ no │ └───────┴─────────┴───────────────────────┘ That matters because callers use the result as if (signal_emit(...)) measure(); — so a garbage true proceeds as if the signal ran, and a garbage false skips the measurement. No error either way. Fix: int n = this->get_signal_id(signal_id); if(n < 0) return true; // unknown signal: nothing vetoed return this->signal_emit(static_cast<size_t>(n)); Not biting yet — nothing in-tree uses the string overload, and as an uninstantiated template it's never checked, so no -Wreturn-type warning appears in the build. — Reply to this email directly, view it on GitHub <#119?email_source=notifications&email_token=ADLM2FISAM6K2AGIVVGYKUL5I2CC5A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIOBYG44DCMZSG432M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-4887813277>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADLM2FME4FKW7PFAIC2MT2L5I2CC5AVCNFSNUABFKJSXA33TNF2G64TZHM4DIOJZG43DEMRXHNEXG43VMU5TKMBZGEZDIOBWHEZKC5QC>. You are receiving this because you authored the thread.

A known bug that does not affect the results of the tutorial's simulations. Approving then reporting the bug as an issue gets things moving along faster.

[marcusr2ML]

Reproduces expected results from tutorials. Fixed prior issues, like violating sum rules and converges faster.