From a35036560693cf9e2db74bf2fe6975e09b3de20c Mon Sep 17 00:00:00 2001 From: Jammy2211 Date: Mon, 13 Jul 2026 20:46:08 +0100 Subject: [PATCH] docs: guide choosing iterations_per_quick_update for quick result inspection MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit al_configure_search: prompt the assistant to actively pick iterations_per_quick_update so the user always gets early, regular fit/sample inspection without visualisation overhead dominating throughput. Rules of thumb (lower for slow/expensive likelihoods e.g. big MGE / pixelised / GPU / high n_live; raise only for very fast likelihoods), and the HPC note that the same value governs what a sync pull surfaces — pick it before submitting. Co-Authored-By: Claude Opus 4.8 Claude-Session: https://claude.ai/code/session_01HD3ZkpFRydshFLeu2V6xDi --- skills/al_configure_search.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/skills/al_configure_search.md b/skills/al_configure_search.md index 63117fb..1666014 100644 --- a/skills/al_configure_search.md +++ b/skills/al_configure_search.md @@ -54,6 +54,16 @@ Knobs to know: - `number_of_cores` — set to your CPU core count for parallel likelihood eval. - `iterations_per_full_update` / `iterations_per_quick_update` — how often the search writes full output (samples, visualisation) vs quick intermediate updates to disk. + **Actively choose `iterations_per_quick_update` so the user always has quick access to + result inspection** — don't just take the default. Judge it against the likelihood cost so + the first on-the-fly `fit.png` / `samples` lands within a few minutes and refreshes + regularly, but not so often that per-update visualisation overhead eats into throughput. + Rules of thumb: ~500–1000 is a good interactive default; **lower it for a slow/expensive + likelihood** (large MGE, pixelised source, GPU-batched fit, high `n_live`) so an inspection + point still appears early; only **raise it** (≈2500–5000) when the likelihood is very fast + and frequent updates would measurably dominate runtime. A common failure is leaving it high + on a heavy fit, so the run shows *nothing* to inspect for an hour — avoid that. On HPC/batch + runs the same value governs what a `sync pull` surfaces, so pick it before submitting. ## Branch — Dynesty