Move the DMRG checkpoint logic out of dmtk (#262)?

Open
  • Is something wrong?
#267 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 3 days

@marcusr2ML is already working on this.

Since Oct 28, 2026.

Assessment

This issue has not been assessed yet.

Description

discussion

For discussion, about #262 (DMRG checkpoints). This would be a refactor with no change in behavior. It is not a request to change #262 now.

What #262 does

dmrg keeps its sweep files (block_*, rho_*, gs_*, system.dat) in <task>.checkpoint/ and commits them after every sweep iteration, so a failed run can be resumed. Lines added at a97c5dcbf:

file lines in dmtk?
dmrg/checkpoint_cache.h (new) +439 no
dmrg/dmrg.h +95 no
dmrg/dmtk/filelist.h +179 yes
dmrg/dmtk/system.h +43 yes
tests, CHANGELOG the rest no

About 220 lines go into dmtk. Most of them are in FileList, which grows from a temp-file registry into the checkpoint store: open_entry, commit, the progress file format, staged and committed bookkeeping, sync_path and write_atomically.

The qualm

Most of that is file handling, not DMRG, and it would be easier to maintain outside dmtk. dmtk would keep only what it alone can do:

  1. system.h: separate read and write file names, six one-word changes (get_filename becomes get_write_filename / get_read_filename in write_* / read_* for gs, rho and block). This cannot move out. dmtk overwrites its files in place, and the checkpoint relies on writes going to <name>.new.<gen> and being renamed at commit.
  2. filelist.h: a hook, meaning a small interface (read name, write name, cleanup) whose default does what FileList does on master.

Everything else in the filelist.h changes (about 160 lines) would move to checkpoint_cache.h.

Two changes in #262 could be separate PRs either way:

  • the System::resume() fix (with START_SWEEP, only the first sweep starts at START_DIR / START_ITER), already listed under "Fixed";
  • write_failed: dmtk currently prints "Could not open file" and continues with an empty block.

For

  • dmtk changes shrink from about 220 lines to about 25, so what was changed in dmtk is visible at a glance.
  • All checkpoint logic is in one file. Reviewing, changing or removing the feature means checkpoint_cache.h plus the hook.
  • FileList stays a temp-file registry.

Against

  • Lifetimes around a global. dmtk::tmp_files is a global, and the checkpoint Cache is owned by the task. With a hook, the global calls into an object owned by Cache. That object has to stay alive and attached until the last tmp_files.cleanup(), including on the failure path in DMRGTask::run (dmrg.h:624-629 at a97c5dcbf: checkpoint.failed(); dmtk::tmp_files.cleanup();). Today FileList owns all of this state, so the order cannot go wrong. After the refactor it can.
  • Behavior must be identical. For example, reads within an iteration must see that iteration's staged writes. dmrg_checkpoint_cache.cmake covers kill, resume and corrupted entries end to end. dmrg_temporary_files.cpp tests FileList directly and would have to be rewritten.
  • Boilerplate. An abstract interface and a default implementation add about 20-30 lines. That is less than what leaves dmtk, but it is new indirection.
Dominant language
C++
Stars
32
Forks
10
Avg merge
4d 5h
Merged PRs (30d)
52

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ALPSim/ALPS

All issues in ALPSim/ALPS

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.