--- title: Architecture at a glance summary: A case specification flows through one pipeline — mesh, discretization, discipline — that every interface shares. The service wraps that pipeline in isolated worker processes and exposes it to programs, people and agents. section: overview order: 2 level: 1 keywords: [architecture, service, discipline, layers] --- Gyre has three layers. The **numerical core** turns a state and a geometry into residuals and outputs, differentiably. The **discipline** adds solvers and exposes the contract an MDO framework expects. The **service** makes the discipline reachable — by HTTP, by pipeline, by agent — and serves the documentation you are reading.

Every interface reaches the numerical core through the same discipline layer.

**[L2 Practice] From request to result** 1. A **case specification** (`CaseSpec`: mesh generator or mesh file, flow conditions, discretization, solver controls, reference quantities) arrives as a preset name with overrides or as a full document. Its canonical JSON is hashed (for a mesh file, with the file's contents in place of its name); the digest identifies the analysis in job, session and result records, and the service's result cache is keyed by that JSON together with the requested gradients, error estimates and order selection, the contents of a mesh file and a fingerprint of the code. 2. `Case` builds the curved mesh, or reads it from a file, the `Discretization` (operators, index tables, boundary conditions) and a `FlowDiscipline`. 3. The discipline converges the flow with the Newton–Krylov solver, evaluates outputs, and on request solves adjoint or direct linear systems for derivatives and error estimates. With an order selection (`adapt`) this step is repeated at rising polynomial degree until the estimated error of one output meets a tolerance. 4. The **runner** collects everything into one self-describing result record: outputs, convergence history, gradients, surface distributions, timings and provenance (version, commit, device). **[L3 Mechanics] Process model of the service**

Solver work is isolated in subprocesses; the API process stays responsive and device-free.

* **Jobs** are one-shot analyses. Each runs in a fresh subprocess, so a crash or an out-of-memory condition cannot take the service down, the device is chosen per job, and cancelling is a process termination. Progress is appended to an event log and streamed as Server-Sent Events. * **Sessions** are long-lived solver processes for design loops: kernels stay compiled, every solve is warm-started from the last state, and derivative products are available between evaluations. * The **store** is plain files — inspectable, restart-safe, and the source of truth for the result cache. Mesh files that clients upload are kept in the same data directory, in the **mesh store**; a case refers to them by name, and no request makes the service open a path of its own choosing. **[L3 Mechanics] Deployments carry their own documentation** `tools/deploy.py up` refuses a port that is already served, builds this site from the working tree, stamps it with the commit, starts the service on all interfaces, and smoke-tests docs, API, a real solver job (which bypasses the result cache) and the MCP endpoint through the tailnet address. The footer of every page shows which deployment is serving it.