Scans and executors

A scan runs one simulation per point of a grid of parameters, and an executor decides where and how those points run. The scan manual works through a pressure–energy example and states the retention, seed and serialisation rules; the modules involved are:

• solprop.driver.scan: Scan (ordered variables and their global points), ScanPoint and run_scan;

• solprop.driver.executors: the execution policies — Local, a spawned process Pool, a lockstep Batch, a durable Queue and Slurm;

• solprop.processing.scans: the reductions a worker evaluates for each point (energy in a band, a spectrum, mode energies, a custom reduction) and the reader of a collected scan (open, ScanOutput);

• solprop.output.scan: the scan file, into which the controller commits each completed point;

Backend and storage interfaces below are mainly for contributors extending an executor:

• solprop.output.scan_artifacts: the validated per-point results a durable queue stores;

• solprop.driver.executors.queue: collecting a queue’s results, safely repeatable;

• solprop.driver.executors.slurm: writing and submitting a Slurm array script;

• solprop.driver.batch: grouping compatible points into a batch and splitting its output back into one run per point;

• solprop.driver.executors.batch: the controls of a fixed-schedule batch;

• solprop.backends.host.group: the backend side of a batch on the NumPy reference, in which every member takes the same fixed steps and is observed on its own. On the native backend a batch runs in the native group session (solprop_native.group), one native execution session per member.