Skip to content

Release notes

The notes of every release, newest first. They are kept in release-notes/ of the repository and are the text of the GitHub releases.

Release notes for simrun 0.3.2

A release for the tests: the package is the same as 0.3.1.

Fixes

  • The k3d tests try the download of their tools (k3d, kubectl) again after a server error or a network error, up to five times with a growing pause, instead of failing at once: a gateway timeout of GitHub failed the cluster job of the release 0.3.1. An error of the client, e.g. a missing file, still fails at once.

Upgrading

  • Nothing to do.

Release notes for simrun 0.3.1

Faster images and a run on the k3d test cluster which takes about as long as on the machine itself: the smoke workflows run every analysis of sbmlsim and the HCTZ model of pkdb_models through simrun, and their timelines show where the time of a run goes. A retry with more memory, which never fitted its node, now does.

Features

  • Smoke workflows. tests/smoke/run.py runs the analyses of sbmlsim (simulate, fit, identifiability, fisher, report, petab, scan, sensitivity, uncertainty) and the simulations, a fit and the build of the models of pkdb_models through simrun, from the checkouts of both, locally (--local) or on the local test system (--k3d). After every run it prints the timeline of its tasks (tests/smoke/timeline.py): the wait for the dependencies, the pod, its admission and its start, the preparation, the work, the merge, the cpu and the CPU throttling of every task, and the seconds of the environment and the image. On the same machine sbmlsim takes 78 s on k3d and 60 s locally, pkdb_models about 250 s both. See Smoke workflows.
  • Faster images. The images compile the bytecode of their packages, so a pod no longer compiles at every import, and keep the downloads of uv in a cache of BuildKit, whose state is now on a volume and outlives its pod. A cold image of sbmlsim builds in 47 s instead of 85 s, an image after a change of simrun in 6 s, and is 378 MiB instead of 583 MiB.
  • Git in the images. The image of an environment installs git when a dependency is locked from a git repository, e.g. sbmlsim from GitHub in the lock of pkdb_models.
  • The reports of the workers. A report carries when its harness started, the seconds it prepared (the install of the sources, the restart, the imports), the cpu of its units and, in a pod, the seconds its CPU quota held it back (started, prepare_seconds, cpu_seconds, throttled_seconds). The service reads the report of a newer harness and ignores the fields it does not know. The coordinator logs the seconds of its merge.

Fixes

  • A retry with more memory waited for Kueue forever when its memory, e.g. 5 GiB times the retry factor, came out a hair above a whole GiB and was rounded up beyond the memory of every node: a pod is now sized to whole GiB without the noise of floating point.
  • A watch of the workflows which the API server or a proxy cut starts again at once with a note in the log, instead of with a warning after 5 s.
  • BuildKit asks for one core in k3d and may use four, so the controllers still fit the server node of a runner with four cores, and the setup of the k3d cluster fails at once on an error of the manifests instead of after ten minutes.

Upgrading

  • Apply deploy/cluster again: BuildKit gets the volume buildkitd-state (local-path, 50 GiB) and a rolling update of one pod at a time.
  • Every model builds its image once more on its first run, as the Dockerfile changed.

Release notes for simrun 0.3.0

Faster workflows on the cluster and the first models of pkdb_models on it: a split task gets only the pods its work pays for, the service follows Argo through a watch instead of a poll, and the images of the environments have the system library which every SBML model needs. Locally, simrun submit --local runs every task type of sbmlsim and the projects at the root of a checkout, e.g. the tutorial workflow of sbmlsim.

Features

  • The split sized by the work. A task of the split mode fastest gets no pod without a unit for each of its processes, and once the seconds of a unit are learned, a further pod only while every pod still has at least pod_start_s of work (new in ClusterConfig, 10 s). A pod which started after the others had taken the units only held cores. demo.squares learns per sleep_s. See Split modes.
  • A watch of the workflows. The service watches the workflows of the runs and reconciles a run as soon as Argo changes it; poll_s is the fallback. The event streams of the web app check the store every events_poll_s (new, 0.5 s) instead of every poll_s. Argo requeues a workflow after 1 s instead of 2 s, so the next task of a workflow starts about a second earlier. A workflow of two split tasks and a command takes 35 to 38 s on the k3d test cluster instead of 40 s; most of the rest is the start of the pods.
  • System packages in the images. The images of the environments install the Debian packages of ClusterConfig.system_packages on the base image, by default libexpat1, which the wheel of python-libsbml links. A fit of a pkdb_models model failed on the cluster without it. An image is named by its Dockerfile as well, so another base image or other system packages give a new image.
  • Projects at the root of a checkout. A task imports from the root of the model first, as python -m in its checkout: the projects at the root of a checkout which no package installs, e.g. the examples of sbmlsim, run through simrun, and the client plans with the same path (SourceProvenance.path, new).
  • The settings form of the Editor. It leaves out the fields the JSON Schema marks readOnly, which the plan of a type sets, e.g. units, and shows no placeholder null. The logs of a task in the inspector can wrap their lines at its width (wrap lines).
  • Tables on 80 columns. The tables of the command line have a rule under the header instead of a frame and keep every value whole: a long value wraps in its column, numbers are right-aligned. The list of runs has no columns for the agent and the time of creation, which the submitter and the run id carry.

Fixes

  • An unsplit task of a plugin type, e.g. sbmlsim.simulate or sbmlsim.report, failed on the local backend with needs the image of the run, and the run has none: a local run has no image, and the argv of the task is now built without one (podspec.unsplit_argv).
  • A local task runs with the environment of the service activated, so the command of a plugin (python -m ...) finds its python also when the service runs from a virtual environment which is not activated.
  • A pod of a split task has no more processes than the task has units, so the other cores stay free for other tasks; an identifiability analysis of three parameters took every core of the machine before.
  • The manifest, the Dockerfile and the deployment documentation of the service named simrun 0.1.0; bump-my-version now updates them with the version.

Upgrading

  • Apply deploy/cluster again: the controller of Argo gets DEFAULT_REQUEUE_TIME=1s. The Role of the service grants watch on workflows already.
  • Every model builds its image once more on its first run, as the images are named anew; the images of 0.2.0 lack libexpat.
  • events_poll_s, pod_start_s and system_packages are optional settings with defaults.

Release notes for simrun 0.2.0

Workflows without a cluster: --local runs a workflow on this machine through a local simrun service, with the same planner, harness, records and web app as on the cluster, at the speed of running the code directly. The cluster gets faster split tasks and a client which needs no mount of the store.

Features

  • The local mode. simrun submit fit.yaml --source model=. --local runs on this machine, the same command without --local on the cluster. A local backend runs the tasks of a run as processes (a split task on the cores of the machine, several runs sharing them, a command with its args directly or in its image with --docker), and the service of a project lives in .simrun/ next to the workflow: started on demand by any --local command, on 127.0.0.1 only, stopped after 30 idle minutes or with simrun serve --local --stop, and restarted when the python environment, the simrun version or the task types change. Sources are recorded (branch, commit, uncommitted files) without copying; --snapshot installs them into an environment of the run instead. A run of three tasks takes 4.8 s for 4.6 s of work. See Local mode.
  • The web app locally. The service of a project serves the web app at /ui/, Executions and Editor (simrun edit --local); the wheel ships the built app.
  • submit --wait and simrun outputs. submit --wait follows a run with a live table per task and exits like wait, the default with --local; simrun outputs RUN TASK [--to DIR] lists or downloads the outputs of a task through the API.
  • Snapshots through the API. Without SIMRUN_STORE the client uploads the files of a working tree to the service, only those the store lacks, so a laptop on the VPN needs a URL and a token only. The snapshots and their hashes are those of 0.1.0.
  • The coordinator merges. A split task has no merge pod any more: its coordinator merges once its ledger is complete and checks the ledger every 0.5 s instead of 5 s, which saves several seconds per split task; a coordinator which succeeded without merging (an image with the harness of 0.1.0) fails its task after a grace of two minutes.
  • The web app. Why a task failed (the exit of its last pod, also in the message of the run), the phase instead of a dash (starting, merging), a worker whose unit or command failed shown as failed, one short name per server, the lines of the Argo executor hidden unless asked for and errors in red; in the Editor the planned memory per worker, a + handle to add an input of a command, the inputs of a command in its inspector, older closed sessions behind Show older. The documentation shows the views.

Fixes

  • A run with the simrun repository as a source failed in every pod: the harness now restarts after installing the sources.
  • A failure which is not a stop is no longer retried a hundred times: only a pod which was stopped (no exit code, 137, 143) is retried, and the message of the run names the failed pod and its exit.
  • The args of a command get {input}, {out} and {settings} as a plugin command does; a command cannot stage its inputs.
  • The image of an environment is named also by the hash of the simrun wheel, so a new wheel of the same version builds a new image.
  • Argo requeues a workflow after 2 s instead of 10 s, so a run shows running soon after its pods start.

Upgrading

  • Add lookupcache=positive to the mountOptions of the existing PersistentVolume of the store and restart the pods (deploy/cluster/store.yaml has it for new installs; see Cluster deployment).
  • Runs recorded by 0.2.0 carry coordinator_merges and merge_pending, which a service of 0.1.0 cannot read: the service cannot be rolled back to 0.1.0 once it recorded runs.
  • Runs of 0.1.0 still in flight keep their merge pod.

Release notes for simrun 0.1.0

The first release of simrun, a runner of simulation workflows on a small k3s cluster with Argo Workflows and Kueue, for people and agents (sbmlsim#440).

Features

  • Workflows of tasks with ports. A workflow is a YAML file of tasks of task types from plugins, whose inputs read the output ports (out/<port>) of other tasks; the settings of a task are validated with the settings model of its type, so a misspelled setting is an error. The built-in type command runs a command in an image of its own.
  • Split tasks on a ledger. A task type with count_units, compute_unit and merge is split into units, which the workers of its pods claim from a ledger of atomic renames in the run store. A coordinator returns once the ledger is complete and computes the units of dead workers, extra workers spread over the idle servers (fastest, at most eight pods) or the task stays on one server (single-server), and the merge runs once every unit is done; the result does not depend on the number of pods.
  • Priorities, preemption and take-back. The runs of the owner of the cluster and the owner's agents, of the other people and of their agents have three priorities, each a base and a lower extra priority of Kueue, so a run of a higher priority preempts the runs of lower ones and a new run takes back the extra workers of the running runs of its own priority. A node can be reserved for one run.
  • Learned resources. The memory of a pod is learned from the anonymous memory of the cgroups of earlier runs of its task type, model and cost setting; a pod killed for memory is retried once with 1.5 times the memory per process, and estimate predicts the duration of a split task from the seconds of its units.
  • Snapshots and environments. The client snapshots the working trees of the model and its libraries, uncommitted changes included, into the run store with their provenance; the service locks their third party dependencies with uv, builds the image of the environment with BuildKit only when the registry does not have it, and the pods install the read-only snapshots editable at their start.
  • Plans and provenance of tasks. A task type can plan its settings before a run is submitted (plan, called by the client where the type is installed, also for estimate and validate); every task gets the provenance of the sources of its run (provenance.json, SIMRUN_PROVENANCE), and a command reads its inputs through {input}, a staged input from a local copy on the scratch of the node.
  • The service, the command line and the MCP server. A FastAPI service with bearer tokens of people and agents submits a run in the background and returns its id at once, follows the workflows with a stateless controller, keeps the logs of the pods and an index of the runs in SQLite beside the store; the command line simrun and the MCP server simrun-mcp of the agents submit, wait for, list, compare, cancel and clean up runs.
  • Cluster deployment. deploy/cluster is the cluster as a kustomization (Kueue v0.20.5, Argo Workflows v4.1.6, the run store on NFS, Zot, BuildKit and the service), deploy/k3d the overlay of the integration tests on k3d, which verify the design on a real cluster. The same run exports as a CWL workflow for cwltool (the extra cwl).
  • The web app. The service serves a web app (Vue 3, Vue Flow, Tailwind) at /ui/, live by server-sent events. Executions: the runs of people and agents with filters and groups and their progress, the capacity of the cluster, a strip of the servers with the cores and memory of every run, the canvas of a run with the state, units and workers of every task, and an inspector with the workers, outputs and live logs. Editor: simrun edit <workflow.yaml> on the machine with the code opens the workflow in the browser, which may run on another machine; a palette of the task types of the service, a canvas to add and connect tasks, the settings as a form of their JSON Schema, the resources with the estimate; Save writes the file next to the code, Run snapshots the working trees again; a file changed on disk is a conflict, not an overwrite; Rerun with changes opens a run in the Editor.
  • A local test system. tests/cluster/local.py up keeps the k3d cluster of the integration tests as a local system with the service on the host, for the command line, the MCP server and the web app (examples/squares.yaml).