Start an optimization run

Start a topology optimization run in the background. Returns at once.

Use after check_problem and after you state your assumptions to the user. If the user gave no load (no object, no mass and no force), ask first. Then run_status to watch it, and run_result when it is done. Nothing calls you back when the run ends: call run_status in this turn, or end the turn and tell the user what to ask. It also returns assumptions (the strings of the YAML) and derived (forces in N, voxel size, minimum feature size, volume fraction), so you can show them. Reply keys: resource topopt://replies/run_topopt (the meaning of each key, and the fine pass: fine_from, fine_pass).

yaml_path: the problem YAML (relative paths start at the work folder; environment shows it). out_dir: the run folder. Default: runs/live in the work folder (the dashboard shows it). Without resume, a folder that holds the checkpoint of a run that did not finish loses it: the reply then has earlier_checkpoint (the pass and a note), and the run goes on. override_lock: a live process can hold the job lock of the run folder (the reply names its pid and start time). Give true to run anyway. A lock of a stopped process is replaced without it. proceed_without_brief: a YAML with a case file (made by record_brief) can have no brief, or a stale brief (a changed STL file or requirement key). Then the reply is {"state": "awaiting_user", "facts", "options", "override"} and nothing starts. Give true to run anyway: the case log records it. resume: continue the run of out_dir from its last checkpoint (run_status shows checkpoint). The history and the snapshots after it are dropped. The YAML and the region files are read again: if they or the settings changed, the reply is an error with the changes in resume.facts, and nothing is written. A run that stop_run stopped is continued the same way, with no allow_changed_inputs. continue_from: add passes to a run in a NEW run folder (out_dir); this folder is the parent and is only read. more_iterations (with continue_from): the number of passes to add (a whole number of 1 or more, no upper limit). The new run starts from the last checkpoint of the parent (pass K) and has K + more_iterations passes (settings.iterations is not used). The reply has continue. The card run_topopt:continue_from has the rest. allow_changed_inputs: with resume or continue_from, go on with the changed inputs. The run log and the verdict name the changes. With resume=true the stop of proceed_without_brief names both overrides in one option (this one and allow_changed_inputs=true). On a finished run a resume runs the post step only: a key that only it reads (for example settings.mesh_method) takes effect in seconds; a key of the passes is accepted, the part stays, and the reply has resume (with pass_keys). stop_rules: true turns the stop rules on, false turns them off. None: as settings.stop_rules of the YAML says (off by default). A rule ends the run at a pass that only measures. The verdict names the rule and its numbers. With resume, a run that was killed gives the same result as one that was not (bit-equal with one thread and a direct solver). The lost force is in check_problem (before) and in run_result or run.json (after). A moment, a remote force, a pressure or a per-axis support gives extended in check_problem; the stiffness of such a case is null with a reason.

Who decides a change of the YAML: a method setting (penal, beta schedule, solver, voxel size, iterations, a voxel guard: the memory estimate against the RAM first, above it the machine can freeze) you change without asking, and report what, why and the price. A user requirement (loads, supports, keep-outs, material, stress limits and safety factors, a mass target, print limits, symmetry) you may tighten without asking, with a report and its measured price; you loosen it only with the user's consent, and you bring the facts. A key that can be either follows its origin in record_brief. Cards: topopt://levers.