An example of what you build on lpspec. A capacity-expansion planner: the model is 69 lines of YAML, the job that solves and archives it 380 lines of Python, this site 1225 lines of Markdown and SQL over the parquet the job wrote, and the notebook 342 lines. All of it is in the source; nothing else is behind it.

A modelling session

The other pages are what lpspec produces unattended: a job solves, archives, and this site reads the archive. This page is the other half of the story, a marimo notebook in which the model is a document you edit by hand. Change the YAML and the typeset math, the validation and the solve follow. Change a number in the data table, or move a slider under the pathway, and the charts re-solve.

It runs in your browser. Python, the HiGHS solver, polars and lpspec itself load as WebAssembly, so nothing runs on a server and there is nothing to install. The first load fetches about 40 MB and takes a moment; after that every edit to the model, the data or the sliders re-solves on your machine. The code stays out of sight; edit mode, linked below, shows it and lets you change it.

It needs memory. After a solve the tab holds about 1 GB, measured in Chromium. A desktop browser takes that in its stride; a phone browser does not, and will reload the page rather than run it. The What if page answers the pathway's two sliders without any of that, from archives the job solved ahead of time.

Run it on your machine

The notebook is notebooks/session.py, a plain Python file. With a local kernel you can also edit the code, not only the model and the data:

git clone https://github.com/fluxopt/lpspec-showcase && cd lpspec-showcase
uv sync --all-extras
uv run marimo edit notebooks/session.py

As it ran at the last build

The same notebook, executed on the build machine and kept as a static page: outputs included, controls inert. This is the fallback, and what search engines see.