Project Architecture
Website design
Simulation

Inspiration

Most simulation tools are either code-heavy for non-experts or black-box AI wrappers that hide the physics. We wanted a middle ground — describe a problem in plain English, but still see a real, inspectable computation underneath it, not an LLM guessing numbers.

What it does

ThermoLingo turns plain-English descriptions of heat-conduction problems into live physics simulations, using an LLM to parse specs and explain results grounded in real computed data.

How we built it

FastAPI backend, NumPy finite-difference solver for the 1D heat equation, Pydantic for spec validation, Google Gemini via an OpenAI-compatible client for the two LLM calls, and a lightweight HTML/JS + Plotly frontend with no build step.

Tech stack Layer Tool Backend Python, FastAPI Numerics NumPy (explicit finite-difference solver) LLM inference Google Gemini API (OpenAI-compatible endpoint) via the openai Python SDK Validation Pydantic Frontend Vanilla HTML/JS, Plotly.js (CDN, no build step)

Challenges we ran into

The main challenge was making the LLM genuinely useful rather than decorative. Two things mattered most: (1) forcing the second LLM call to explain results using only the computed numbers we pass it, rather than letting it invent plausible-sounding physics — this required carefully scoping the prompt and testing it against edge cases where initial and boundary temperatures were close together. (2) Making sure LLM-supplied physical parameters (like thermal diffusivity) could never make the numerical solver unstable — solved by implementing the CFL condition as an explicit, automatic time-step clamp rather than trusting the LLM's output blindly. Keeping the pipeline transparent (surfacing the parsed spec in the UI) was also a deliberate choice so judges — and any user — can see the LLM's work rather than treat it as a black box.

Accomplishments that we're proud of

A pipeline where the LLM's work is fully visible — the parsed spec, the raw simulation, and the explanation are all shown separately — so it's clear the physics is real, not just an LLM narrating a plausible-sounding answer.

What we learned

How much design effort goes into making an LLM call trustworthy rather than just functional — schema validation, numerical safety nets, and grounding prompts strictly in computed data all mattered more than the LLM call itself.

What's next for ThermoLingo

Support more boundary condition types (Neumann, Robin), extend beyond 1D heat conduction to other PDE/ODE families like wave or reaction-diffusion equations, and add an implicit solver option for larger time steps.