Measure the build time and peak RSS of a penn-full table with band-bottom rate refinement (operator-run) #360

Split from #357 (part b). Measurement only; no code change. Operator-run because a full-Penn table build is the workload suspected of exhausting host memory in an earlier session; no automated agent should run it.

What to measure

Wall time and peak RSS of one model = "penn-full" electron table build for a material with a band, with band-bottom rate refinement on (RateRefinement::default(), which lindhard run now applies to every material with a band, #355), against the same build with refinement off if a switch is available (otherwise against the row count alone). Each refinement level evaluates 3 to 4 scalar rates per tested cell and adds roughly 5 to 25 rows; the question is how much that adds to a full-Penn build.

Command (adjust paths; run on an otherwise idle host)

cp examples/electron/e_10keV_si.toml /tmp/penn_full_timing.toml   # edit: model = "penn-full"; keep its [band]
RAYON_NUM_THREADS=2 timeout 3600 /usr/bin/time -l \
  cargo run --release -p lindhard-cli -- run /tmp/penn_full_timing.toml \
  --out /tmp/penn_full_timing_out/ --ions 1 --seed 1 --threads 2 \
  --table-cache /tmp/penn_full_timing_cache/

Caps: two rayon threads, one process, a one-hour timeout, nothing else building. /usr/bin/time -l reports "maximum resident set size" (bytes on macOS); record it. Stop (Ctrl-C) and record the RSS so far if resident memory passes about a quarter of host RAM. Do not run concurrently with a sweep.

Report

Post a comment here with: material and ELF file, --ions, row count of the built table (cache entry or the run summary), wall time, peak RSS, host RAM. Then close.

Acceptance criteria

• One measured build recorded in a comment (time, peak RSS, rows, host).
• If the added cost is large, file a follow-up; otherwise close.

loom dashboard