Adding LEM to CANTERA — a research engineer's rite of passage
How a Linear Eddy Model went into the open-source CANTERA library — across C++, Fortran and Python — and what that taught me about shipping into other people's codebases.
CANTERA is the thermodynamic-chemistry library a lot of combustion researchers reach for. It is well-engineered, multi-decade, multi-language — and largely written by people who will never meet you. Adding a Linear Eddy Model sub-grid closure to it sounded, on paper, like writing a sub-model. In practice it was a six-month exercise in respecting a codebase.
The LEM idea is simple to state: in a turbulent reactive flow, the eddies that dominate the chemistry happen at scales smaller than any practical Large Eddy Simulation can resolve. So you embed a one-dimensional sub-grid solver inside each LES cell, advance it in lock-step, and feed its statistics back to the LES. The result is a closure that captures the small-scale chemistry without trying to resolve it.
Writing the LEM kernel was the fast part. Ten weeks of C++, with the Fortran integrators wrapped by F2C and the Python bindings glued on top. The slow part was making it accept the same input formats CANTERA already accepted. The slow part was making it interoperate with the chemistry kernels somebody else had written six years earlier. The slow part was the regression tests that nobody had updated in two releases.
The rule I learned, the hard way: before you open a pull request to an open-source project, read a hundred merged pull requests. Read what the maintainers ask for. Read which conventions they reject. Read which test files they insist on. The maintainers are not gatekeeping out of spite — they are protecting twenty years of accumulated stability against the bright new contributor who knows the model but not the codebase. You earn the merge by spending a week being boring: matching naming conventions, fixing your line endings, writing the unit test in their style.
The LEM additions produced a PDF (probability density function) and an SDR (scalar dissipation rate) output pipeline for a premix methane Bunsen burner. The paper followed two years later — the one on Pulsating Heat Pipes that bears my name as third author — and the lessons from the codebase work bled forward into every industrial AI project I have shipped since.
The meta-lesson is that the cleanest LEM kernel in the world is worth nothing if it does not slot into the existing tooling. This is the same lesson that comes back at Dekali (the AI must live where the workflow lives) and at Extrema (the chatbot must answer in the same UI the customer is already in). Research-engineer instincts translate to industrial-engineer instincts surprisingly well — both require you to remember that you are the temporary visitor, and the existing system was here first.