All work

AutoDyn Performance Lab

A theoretical vehicle-performance modeling app. It takes sourced specifications, a deterministic physics engine and an optional Gemini assistant, and compares a stock car with a hypothetical modified build — with every input labeled by where it came from.

Live appView code
Release
2.0, live on Vercel
Stack
Next.js 16, React 19, TypeScript
Physics
Deterministic, runs in the browser
AI
Google Gemini, proposals only

AutoDyn Performance Lab 2.0Results: 2015 C300 4MATIC, stock vs. a hypothetical +60 hp

Open the live app
AutoDyn results comparing a stock and a modified 2015 Mercedes-Benz C300 4MATIC. Inputs are labeled verified, user-provided, estimated or derived; simulated results list 0–60 mph of 6.19 s stock and 5.05 s modified, each with an indicative range.
  1. 1

    Inputs carry their source. Verified dataset specs, the user's +60 hp, an estimated torque curve and a derived test mass are each labeled as such.

  2. 2

    0–60 mph. 6.19 s stock, 5.05 s modified — each with an indicative range from input uncertainty.

  3. 3

    Simulated, not measured. Results are theoretical outputs of the deterministic model. “Verified” only ever applies to sourced specifications.

Comparing a modification on paper is easy to get wrong.

A “+60 hp” claim says nothing about torque, traction, gearing or mass. And once a number is on screen it is hard to tell which inputs were published, which were typed in, and which were guessed.

AutoDyn keeps those apart. Every value it uses carries a label — verified, user-provided, estimated, derived or calculated. The physics is deterministic and runs in the browser. The feasibility check says plainly what it can assess and what it cannot. The assistant can propose a configuration, but never a result.

How an analysis flows.

  1. 01

    Vehicle data

    Year, make, model and trim from a CarAPI dataset of 2015–2020 US trims, a VIN decoded through NHTSA vPIC, or manual entry.

  2. 02

    Configuration

    Peak power and curb weight are required. Thirteen further assumptions — gearing, aero, tires, conditions — have documented defaults that can be overridden.

  3. 03

    Proposal review

    Optionally, the assistant turns a request such as “+60 hp” into a proposal. Nothing changes until it is approved, edited or cancelled.

  4. 04

    Deterministic physics

    A time-step point-mass simulation, gear by gear, with traction, drag, rolling resistance and shift losses. No AI touches a number.

  5. 05

    Results

    Metrics with uncertainty ranges, stock-versus-modified deltas, charts, a feasibility assessment and full provenance.

  6. 06

    Saved analysis

    Every completed run is kept in the browser with its exact inputs, and exports as JSON, CSV or a printable report.

AI-assisted configuration.

The AI Build Assistant is an automotive specialist built on Google Gemini. It identifies a car from a description, interprets a modification request and structures it as a proposal. The user reviews that proposal: the requested change is marked user-provided, anything AutoDyn had to assume — here a torque curve scaled to match the new power — is marked estimated, and the configuration is validated before Apply to Simulation hands it to the physics engine.

Gemini does
  • Conversation about vehicles, parts, maintenance and modifications
  • Identifying a vehicle from a description, matched against the dataset
  • Interpreting a build request into structured, labeled changes
  • Explaining concepts and the simulation's own results
  • Citing verified external sources: EPA fuel economy, NHTSA recalls
Gemini does not
  • Produce performance numbers or vehicle specifications
  • Change the configuration without the user's approval
  • Run, alter or short-cut the physics simulation
  • Spend quota on off-topic requests — a local gate answers those
The assistant workspace: saved conversations, Gemini's write-up of the stock C300 and the +60 hp version, and the Review changes panel waiting for approval.
Gemini's write-up ends with its status: not simulated yet, the 301 hp not verified by AutoDyn, and the EPA listing it cited.
Review changes: 241 → 301 hp user-provided, torque 273 → 341 lb-ft estimated, a validation pass, then apply, edit or cancel.
Ownership questions are grounded in official services with the retrieval date shown; the fuel-cost arithmetic is AutoDyn's own, written out step by step.

The physics model.

A longitudinal point-mass model on a level road. The engine's full-load torque curve is synthesized from the rated peaks at their rpm points, wheel force is computed gear by gear through the drivetrain efficiency, and the run is integrated in time steps against the forces that resist it. Outputs: 0–60 mph, 0–100 km/h, 0–100 mph, quarter-mile time and trap speed, 50–70 mph, peak g, traction-limited share and theoretical top speed, each with an indicative range from input uncertainty.

Power and torque
Rated peaks and their rpm points define the synthesized full-load curve the simulation drives.
Mass
Curb weight plus an estimated driver and cargo gives the test mass, with a rotational-inertia factor on top.
Traction
A tire-grip coefficient and the driven axle's load, including load transfer, cap launch acceleration.
Gearing
Gear ratios, final drive and a short torque interruption per upshift set wheel force and shift points.
Aerodynamic drag
Half ρ·Cd·A·v², with air density from temperature and elevation: the dominant loss at speed.
Rolling resistance
A rolling-resistance coefficient on the test mass, present from the first metre.
Advanced settings for the stock C300. Verified values come from the dataset; every estimated one shows its default and the reasoning behind it.
The results page says what the model leaves out.

One scenario: a 2015 C300 4MATIC, plus 60 hp.

Every capture on this page comes from one analysis. The Mercedes-Benz C300 4MATIC enters with verified dataset specifications — 241 hp, 273 lb-ft and a 3,594 lb curb weight. The hypothetical modification asks for 60 hp more, so peak power becomes 301 hp. Because only power was specified, AutoDyn scales the whole torque curve by the same +24.9% and labels the resulting 341 lb-ft estimated: a modeling assumption, not a dyno figure.

The simulated result: 0–60 mph falls from 6.19 s to 5.05 s and the quarter mile from 14.70 s to 13.65 s. A 24.9% increase in power buys an 18.4% improvement, not a proportional one. The launch is traction-limited — 6% of the stock run, 11% of the modified one — two upshifts each cost 0.12 s, and drag grows with the square of speed.

The engineering analysis is generated deterministically from the computed results and the model's assumptions — including how much the estimated inputs widen the range.
Speed vs. time. Stock in blue, modified in dashed orange; the vertical lines mark each run's quarter-mile finish.
Acceleration vs. speed. The flat start is the 0.95 g traction limit; the dips are gear changes.
Torque and power vs. rpm, as synthesized from the rated peaks. This is the curve the simulation used, not dyno data.
Impact of mass on 0–60 mph. Each point is a separate simulation with the curb mass changed and everything else held constant.
Sensitivity of the modified build's 0–60 time to each input. Engine output and mass matter most — which is also where the estimated inputs sit.

Feasibility is a modeled assessment, and says so.

The two verdicts for this scenario, computed without AI.

Each scenario is classified feasible, questionable, non-feasible or insufficient data from deterministic checks: data provenance, power–torque consistency, specific output, the traction bound against drive force, speed range, the acceleration envelope and any component ratings entered.

The stock car passes every evaluated constraint. The modified build is rated questionable: its torque curve is an assumption and no engine, transmission, axle or cooling ratings were given, so the two checks that depend on them need verification. A rating does not establish durability, cooling capacity, drivetrain strength, emissions compliance, road legality or real-world safety — and the app repeats that on every result.

Every metric also carries an indicative range from input uncertainty: verified ratings ±2–3%, user values ±5%, estimates wider. Stock 0–60 reads 6.19 s with a range of 5.52–6.95 s.

What is missing for the modified build, and what would narrow the range: a measured torque figure, or a drivetrain rating.
The modified build's assessment: six constraints satisfied, two need verification, each with the figures it was judged on.

One label travels with every value.

The same five labels appear in setup, the assistant, the review panel, the results, saved analyses and exports, so a number never looks more certain than its inputs.

Verified
A sourced specification from the vehicle dataset. EPA data verifies fuel economy only — never horsepower, torque or weight.
User-provided
What the user entered or requested, such as the +60 hp.
Estimated
An AutoDyn assumption: the scaled torque curve, the 176 lb driver and cargo, the gearing, drag and grip defaults.
Derived
Combined from the above, such as the 3,770 lb test mass — verified curb weight plus the estimated driver.
Calculated
An output of the physics model: 0–60, quarter mile, top speed, the charts. Always theoretical, never labeled verified.
The results table shows the source beside every input before any calculated number: verified specs, the user's 301 hp, an estimated torque, and a test mass derived from a verified curb weight and an estimated driver.
The provenance panel lists every input, where it came from, and how each estimate was made — including the ×1.249 torque scaling.
Saved analyses, with backup export and import. Opening one restores its exact inputs and results.

Saved locally, exported plainly.

Every completed run is saved automatically in the browser's IndexedDB with its inputs, vehicle identity, provenance, results, chart series, feasibility assessment and the physics-engine version that produced it. The workspace links to one saved analysis like an open document; Duplicate and Save as keep separate copies, and an analysis from an older engine version is shown as historical rather than silently recomputed.

There are no accounts and no server storage. Backups export and import as validated JSON, and any result exports as JSON, CSV or a printable report.

How it is built.

Framework
Next.js 16 App Router, React 19 and TypeScript, styled with Tailwind CSS 4. Charts are drawn with Recharts.
Deterministic engine
Pure TypeScript in SI units: a resolver fills missing inputs with labeled estimates, a time-step simulation produces the metrics, and uncertainty bands, sensitivity, the mass sweep and change attribution are computed from it.
Scenario state
Modified is stored as Stock plus overrides, so the baseline is never mutated. A pure reducer with revision-based staleness marks results outdated the moment an input changes.
AI layer
A server-only route calls Gemini with JSON-schema structured output, validates it with Zod, resolves any named vehicle against the dataset before the model answers, and strips figures the engine did not compute.
API controls
A local automotive-relevance gate runs before any provider call. Per-client and global rate limits, duplicate-request IDs, an 800-character message cap, bounded history, a 20 s timeout and no retries; with Upstash Redis configured the limits are shared across serverless instances.
Persistence
Local-first. Saved analyses and conversations live in IndexedDB and are validated with Zod on read; the working draft sits in localStorage; backups import and export as validated JSON. No accounts, no server storage.
Data
A CarAPI dataset of 2015–2020 US trims compiled into a static index by a build script; NHTSA vPIC for identification and VIN decode; EPA fueleconomy.gov and NHTSA recalls as cited external sources.
Testing
Vitest unit tests with the Gemini call mocked, plus real-browser layout checks at 360 and 390 px against the production build.