Show run status
run_statusMonitors a topology optimization run by returning its current status, last iteration, and one-line summary so you can check progress and decide next steps.
Instructions
Show the state of a run: status, last iteration, and a one-line summary.
Call it again to watch a run. Each call returns at once. Nothing calls you back when the run ends: call it again in this turn until the state is done, error or stopped, or process_alive is false, or end the turn and tell the user what to ask for the result. A promise of a later report cannot be kept. The numbers are facts; you decide what to do next.
run_dir: the run folder. Default: the last run that this server started.
job has the facts of the run process: state (running, done, stopped, failed with its exit code, or stale_lock when the process stopped without a marker), wall time and peak memory. history_facts names lines that were skipped.
state is stopped for a run that a request to stop (stop_run, topopt stop) ended at the end of a pass: the checkpoint is saved, there is no result/, and run_topopt with resume=true continues it. A process of this server can still be alive after that: it only serves the dashboard (process_alive true, job.state stopped). stop_request is the request in the run folder (null if none): while the job is running it means the run stops at the end of its current pass.
checkpoint (null if the folder has none, or the state is starting, error before any data, or none) gives the pass of the last checkpoint, complete (the run reached its last pass or a stop rule) and yaml_path: run_topopt with resume=true continues a run that stopped before its last pass.
verdict (null until the run ends) has the state (converged, iteration_limit, stopped_by_rule, stopped_by_request, unfinished), whether the constraint rows are met (feasible), the measures with their thresholds, the stop rule that fired, and the resume points. The same verdict is in metrics.json (run_result).
verdict.facts has the facts of the last pass, and the verdict text ends with "Facts: ..." for each fact that the run has: the volume used (the projected design, and the thresholded part at density 0.5; only with a volume row); the load path (which load regions the thresholded part does not join to a fixed, spring or joint region; in the text only when a region is not joined); for a run with objective mass, the material (volume and mass of the thresholded part; only with no volume row) and, when the grayness is above grayness_max, the grey design (volume and body count of the thresholded part at the cuts 0.4, 0.5 and 0.6, and the volume spread between 0.4 and 0.6 as a share of the volume at 0.5). They are facts: no test uses them. The run log has them at the end of each beta stage. The body count of final.stl comes after the post step: metrics.grey_design (see run_result).
A run that ended with no result also has log_tail, failure (facts: pid, exit code, signal, run data, whether this server stopped it,
peak memory, estimate, RAM), options and, after a signal or an unseen end with no message, possible_causes (not a verdict).
fine_run (the first folder of run_topopt with fine_pass=true): the folder and the state of the fine pass.
time_left (while the run is in its passes, from pass 2 of the run process) has left_s and up_to_s (seconds left if no stop rule or request to stop ends the run earlier) and basis. Else it is null, with the reason in time_left_note.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| run_dir | No |