Skip to content

maint: vram-first validation sweep + batch-size provenance (polish phase 2) #54

Description

@Jammy2211

Overview

Phase 2 of the polish series (parent: PyAutoMind maintenance/autolens_profiling/polish.md; phase 1: #52 / PR #53). Validate the VRAM/vmap story before the PreOptimizationTimes campaign burns A100 hours: the parent prompt's instruction is "run vram first so memory issues don't sidetrack the campaign". Autonomy: --auto at effective level supervised (plan approved interactively in-session; checkpoint-and-continue per PyAutoBrain/AUTONOMY.md).

Plan

  • Coverage + staleness auditvram/config.py fully covers the phase-3 matrix (its Nones are documented intentional blocks), but every row was probed 2026-05-24 against older source; add per-row provenance (probe date + PyAutoLens version) and flag the rows the campaign relies on.
  • Local CPU validation sweep — run every phase-3 cell script once on CPU with its cheapest instrument preset to flush functional bugs while it's cheap; exercise --vmap-probe end-to-end locally and confirm vmap_probe.json lands in the new results/runtime/<class>/<model>/ layout.
  • Sparse-path batch sizes — extend the batch lookup with an inversion-path axis (dense default, back-compatible vmap_batch_for), since phase 3 vmaps imaging sparse-vs-mapping and the table has no sparse dimension.
  • Close the probe→runtime gap — A100 submits re-probe in Phase A but Phase B reads the static table; runtime cells will prefer a fresh same-cell vmap_probe.json over the table (logged), so a stale table can't OOM a job.
  • Docs + dispatch prep — fix the stale z_projects probe path in vram/README.md; stage probe-only A100 submits (multi-point (1,4,16) for mge/pixelization, single-point (1,) for delaunay, sparse variants included).
  • A100 leg (human/HPC-blocked) — submits + ingest instructions staged; dispatch happens on RAL (HPC checkout must pull the phase-1 merge first); probe JSONs then ingested into the table with provenance.
Detailed implementation plan

Affected Repositories

  • autolens_profiling (primary, only)

Branch Survey

Repository Current Branch Dirty?
./autolens_profiling main clean

Suggested branch: feature/profiling-vram-validation
Work Classification: Workspace
Worktree root: ~/Code/PyAutoLabs-wt/profiling-vram-validation/

Implementation Steps

  1. vram/config.py: key (dataset, model, instrument)(dataset, model, instrument, path) with back-compatible vmap_batch_for(..., path="dense"); add PROBED provenance mapping; extend test/test_vram_probe.py.
  2. likelihood_runtime/<class>/<model>.py: batch-size resolution order — fresh vmap_probe.json in the cell output dir → vram/config table → skip-with-reason (log which source won).
  3. hpc/batch_gpu/: probe-only submits for the campaign's vmap cells incl. sparse variants.
  4. Local CPU sweep of all phase-3 cells (smallest instrument, CPU-pinned, scratch results); triage any failures — fix in-repo if small, else file bug/ prompts without sidetracking (parent-prompt rule).
  5. vram/README.md stale-path fix + in-repo probe→config workflow doc.

Key Files

  • vram/config.py, vram/probe.py, test/test_vram_probe.py
  • likelihood_runtime/{imaging,interferometer,datacube}/*.py
  • hpc/batch_gpu/, vram/README.md

Original Prompt

Click to expand starting prompt

polish phase 2 — vram-first validation sweep

Type: maintenance
Target: autolens_profiling
Difficulty: medium
Autonomy: supervised
Priority: normal
Status: formalised

Phase 2 of 4 of polish.md (see parent for full intent). Depends on phase 1
(design locked).

Profiling runs have historically flagged memory/VRAM issues that side-tracked
the campaign into source fixes. To avoid that, run the vram package first,
across the imaging, interferometer and datacube configs that phase 3 will
profile, so memory issues and other bugs surface now rather than mid-campaign.

Deliverables:

  • vram results for the phase-3 config matrix, saved per the phase-1 results
    conventions (.json + .md).
  • The computed vmap batch sizes per config — phase 3's likelihood_runtime
    sweeps are vmap-only and consume these batch sizes.
  • Any memory/VRAM bugs found are triaged: fix here only if small and in-repo;
    otherwise file as separate bug/ prompts and do not side-track the campaign.

Out of scope: runtime/breakdown sweeps (phases 3–4); searches; point_source;
laptop GPU.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions