From 4ada8e85ce0f0ba8ef18a05c42ebcbbf1733a98f Mon Sep 17 00:00:00 2001 From: x01dc Date: Tue, 21 Jul 2026 03:20:55 +0200 Subject: [PATCH] docs/document tomo_queue_reacquire and tomo_queue_resume Add both to the tomo-queue command reference in flomni.md and lamni.md: tomo_queue_resume() as an alias for tomo_queue_execute(), and tomo_queue_reacquire(job_index, projection_number) for reopening a job (including an already-"done" one) at an earlier projection and cascading later jobs to pending, mirroring the code added in the previous commit. Co-Authored-By: Claude Sonnet 5 --- docs/user/ptychography/flomni.md | 33 ++++++++++++++++++++++++++++++++ docs/user/ptychography/lamni.md | 32 +++++++++++++++++++++++++++++++ 2 files changed, 65 insertions(+) diff --git a/docs/user/ptychography/flomni.md b/docs/user/ptychography/flomni.md index 948e41f..eceda96 100644 --- a/docs/user/ptychography/flomni.md +++ b/docs/user/ptychography/flomni.md @@ -345,6 +345,7 @@ Several tomo parameter sets can be queued and run sequentially on the same sampl | `flomni.tomo_queue_delete(*indices)` | Delete one or more jobs by index. | | `flomni.tomo_queue_clear()` | Empty the queue. | | `flomni.tomo_queue_execute(start_index=0)` | Run all pending jobs in sequence, on the current sample. | +| `flomni.tomo_queue_resume(start_index=0)` | Alias for `tomo_queue_execute()` — identical behavior, just a name that matches `tomo_scan_resume()`. | The queue is persisted (it survives a BEC client restart). Each job's status is one of `pending`, `running`, `incomplete`, or `done`. A job that did not run to completion (an exception was caught, or the BEC client itself crashed mid-scan) is automatically resumed - rather than restarted - the next time `flomni.tomo_queue_execute()` is called. @@ -375,6 +376,38 @@ open in the panel. If you have an unsaved edit open and click the queue window's button instead of the panel's, it warns and names the correct one before proceeding, since it would otherwise queue your last-submitted values, not what you just typed. +**Reacquiring from an earlier projection.** A resumed job normally picks up +exactly where it stopped. If a beamline problem means earlier projections need +redoing too — even in a job that's already marked `done` — use: + +`flomni.tomo_queue_reacquire(job_index, projection_number)` + +`job_index` is the job's position, same indexing as `tomo_queue_show()`. +`projection_number` is a flat, 0-indexed projection count that works the same +way for all three tomography modes — for "8 sub-tomograms" it counts straight +through all 8 in order (subtomogram 1's projections first, then subtomogram +2's, ...), exactly matching the running `projection` counter already shown in +the live progress report / `flomni.progress["projection"]`; for the +golden-ratio modes it's the same projection number those already use. This +reopens the job at that point and resets every job queued *after* it — +tomograms and command jobs alike, regardless of their own current status — to +`pending`, so the next `flomni.tomo_queue_resume()` (or `tomo_queue_execute()`) +call re-runs everything from there forward, in order. It does not run +anything itself. + +Example — job 0 already finished, but its last few projections (and the jobs +queued after it) need redoing: +``` +flomni.tomo_queue_show() # find the job index and the projection number to restart at +flomni.tomo_queue_reacquire(0, 130) # reopen job 0 at projection 130; jobs 1+ reset to pending +flomni.tomo_queue_resume() # actually re-run, in order +``` + +Refuses (raises) if `job_index` points at a command job (nothing to +reacquire), or if some *other* job in the queue is already `incomplete`/ +`running` — only one job's progress can be tracked at a time, so resolve that +one first (or pass its own index instead). + #### Command jobs — reconfiguring the beamline between scans In addition to tomogram jobs, the same queue can hold **command jobs**: an ordered diff --git a/docs/user/ptychography/lamni.md b/docs/user/ptychography/lamni.md index 5dee5c1..b8df89b 100644 --- a/docs/user/ptychography/lamni.md +++ b/docs/user/ptychography/lamni.md @@ -113,6 +113,7 @@ Several tomo parameter sets can be queued and run sequentially on the same sampl | `lamni.tomo_queue_delete(*indices)` | Delete one or more jobs by index. | | `lamni.tomo_queue_clear()` | Empty the queue. | | `lamni.tomo_queue_execute(start_index=0)` | Run all pending jobs in sequence, on the current sample. | +| `lamni.tomo_queue_resume(start_index=0)` | Alias for `tomo_queue_execute()` — identical behavior, just a name that matches `tomo_scan_resume()`. | The queue is persisted (it survives a BEC client restart). Each job's status is one of `pending`, `running`, `incomplete`, or `done`. A job that did not run to completion (an exception was caught, or the BEC client itself crashed mid-scan) is automatically resumed - rather than restarted - the next time `lamni.tomo_queue_execute()` is called. @@ -149,6 +150,37 @@ of the queue, labeled with `_dup` appended, status reset to `pending`. Useful fo re-running a job with the same settings without re-typing them, or as a starting point to tweak via "Load into editor". +**Reacquiring from an earlier projection.** A resumed job normally picks up +exactly where it stopped. If a beamline problem means earlier projections need +redoing too — even in a job that's already marked `done` — use: + +`lamni.tomo_queue_reacquire(job_index, projection_number)` + +`job_index` is the job's position, same indexing as `tomo_queue_show()`. +`projection_number` is a flat, 0-indexed projection count that works the same +way for all three tomography modes — for "8 sub-tomograms" it counts straight +through all 8 in order (subtomogram 1's projections first, then subtomogram +2's, ...), exactly matching the running `projection` counter already shown in +the live progress report / `lamni.progress["projection"]`; for the golden-ratio +modes it's the same projection number those already use. This reopens the job +at that point and resets every job queued *after* it — tomograms and command +jobs alike, regardless of their own current status — to `pending`, so the next +`lamni.tomo_queue_resume()` (or `tomo_queue_execute()`) call re-runs everything +from there forward, in order. It does not run anything itself. + +Example — job 0 already finished, but its last few projections (and the jobs +queued after it) need redoing: +``` +lamni.tomo_queue_show() # find the job index and the projection number to restart at +lamni.tomo_queue_reacquire(0, 130) # reopen job 0 at projection 130; jobs 1+ reset to pending +lamni.tomo_queue_resume() # actually re-run, in order +``` + +Refuses (raises) if `job_index` points at a command job (nothing to +reacquire), or if some *other* job in the queue is already `incomplete`/ +`running` — only one job's progress can be tracked at a time, so resolve that +one first (or pass its own index instead). + #### Command jobs — reconfiguring the beamline between scans In addition to tomogram jobs, the same queue can hold **command jobs**: an ordered