sim — docs — 96×32
// sim — the container runtime for physics simulations
sim@svdailab ~/docs  man sim
Today's CAD and CAE software was built for engineers clicking through GUIs. Tomorrow's user is an LLM agent — and it needs a way in. Like a container runtime standardized how Kubernetes talks to containers, sim standardizes how agents talk to solvers.
sim@svdailab ~/docs  why
LLM agents already know how to write PyFluent, MATLAB, COMSOL, and OpenFOAM scripts — training data is full of them. What they don't have is a standard way to launch a solver, drive it step by step, and observe what happened before deciding the next move. Today's options:
  • fire-and-forget scripts — 200 lines, one run, an error at line 30 surfaces as garbage at line 200
  • bespoke wrappers per solver — every team rebuilds the same launch/exec/inspect loop in a different shape
  • closed proprietary glue — vendor SDKs that don't compose, don't share a vocabulary, don't speak HTTP
sim is the missing layer: one CLI, one HTTP protocol, a growing driver registry, persistent sessions agents can introspect between every step, and companion skills that teach LLMs how to drive each backend safely.
sim@svdailab ~/docs  arch
sim architecture CLIENT SIDE sim CLI Click app · `sim connect/exec/inspect` runs on agent host or laptop SIM_HOST · SIM_PORT one-shot mode sim run script.py --solver X stored as numbered run in .sim/runs/ HTTP / JSON stdout · result · diagnostics SOLVER WORKSTATION sim serve FastAPI · port 7600 one global session DriverProtocol • fluent (PyFluent · sessions) • comsol (JPype) • openfoam (Linux subprocess) • matlab (matlabengine) • … more in the registry • + your driver here (~200 LOC, register in drivers/__init__.py) src/sim/drivers/<name>/driver.py register in drivers/__init__.py Live solver process Fluent GUI · COMSOL · MATLAB ANSA · Flotherm · OpenFOAM engineer can watch in real time launched once, snippets at will
Two execution modes from the same CLI, sharing the same DriverProtocol:
modecommandwhen
persistent sim serve + connect / exec / inspect long, stateful workflows the agent inspects between steps
one-shot sim run script.py --solver X whole-script jobs stored as a numbered run in .sim/runs/
sim@svdailab ~/docs  cmd --essentials
commandwhat it doeslike
sim check detect solver installs, resolve a profile docker info
sim serve start the HTTP server (cross-machine) ollama serve
sim connect launch a solver, open a session docker start
sim exec run a Python snippet in the live session docker exec
sim inspect query live session state docker inspect
sim screenshot grab a PNG of the solver GUI
see all 13 commands in the README  ↗
sim@svdailab ~/docs  vs scripts
fire-and-forget scriptsim
write the whole thing, run, hope it converges connect → execute → observe → decide next step
error at step 2 surfaces at step 12 each step verified before the next is sent
agent has no view of solver state sim inspect between every action
solver restarts on every iteration one persistent session, snippets at will
GUI invisible to the human engineer watches the GUI while the agent drives
output parsing reinvented per project driver.parse_output() returns structured fields
sim@svdailab ~/docs  exit
sim@svdailab ~/docs