About

Engineering is the art of finding answers in the unknown.

Every real problem I have encountered starts the same way: as a pool of unknowns. A complex engineering problem never arrives whole. It arrives tangled: many interconnected parts, incomplete data, constraints pulling against each other. The way I see it, engineering begins right there. You sit with the problem, break it into its pieces, and digest each one until the connections start to show.

Then comes the craft: holding the ambiguity without freezing, testing a hypothesis, following a lead through the noise until a thread appears. From there the work becomes assembly. Piece by piece a path takes shape, and at the end of it stands an answer you can defend. That is how I see engineering: solving the most complex problems one connected piece at a time. It is also the part of the work I love most.

The foundation

One foundation underneath.

Re = 100 · flow past a cylinder

measuring wake

Drag to disturb the flow.

Flow past a cylinder. A live incompressible solver: change the Reynolds number and watch the wake change regime.

I have spent my career moving between fluid mechanics, solid mechanics, heat transfer, thermodynamics and fire. Different names, different industries, different codebooks. Underneath, they all stand on the same foundation: governing equations, numerical methods, data, codes of practice, and judgement.

Go deep enough into that foundation and the walls between fields get thin. Derive the equations and you know what a solver can and cannot see. Trace a code clause back to the physics and the test data behind it and you know exactly how far it stretches. That is the depth I work from. It is what lets me carry the same thinking from a turbulence model to a fire strategy to a neural network. It is what I call physics into practice.

∂u/∂t + (u·∇)u = −∇p/ρ + ν∇²u · ∇·σ + ρb = ρü · ∂T/∂t = α∇²T · fᵢ(x + cᵢΔt, t + Δt) − fᵢ(x, t) = Ωᵢ · Q̇ = ṁ cₚ ΔT · ∂u/∂t + (u·∇)u = −∇p/ρ + ν∇²u · ∇·σ + ρb = ρü · ∂T/∂t = α∇²T · fᵢ(x + cᵢΔt, t + Δt) − fᵢ(x, t) = Ωᵢ · Q̇ = ṁ cₚ ΔT ·

L(θ) = −Σ y log ŷ · θ ← θ − η ∇L · Re = ρUL/μ · ∇²φ = 0 · q″ = −k ∇T · L(θ) = −Σ y log ŷ · θ ← θ − η ∇L · Re = ρUL/μ · ∇²φ = 0 · q″ = −k ∇T ·

Different fields. The same governing mathematics.

The method

From problem to answer.

The method is the same on every job, whatever the field. Strip the problem back to first principles. Pick the right instrument: sometimes a simulation, sometimes a code pathway, sometimes a test or a calculation that fits on one page. Verify the result against reality. Then judge, carefully, where the instrument ends, because every model, clause and correlation ends somewhere, and everything past that line is engineering, not procedure.

The last step is the one people pay for: delivering the answer in a form someone can act on. A number with its limits stated. A report an authority will accept. A drawing a builder can follow. Anything less is analysis, not engineering.

From problem to answer

01

Strip it to first principles
02

Pick the right instrument
03

Verify against reality
04

Judge where the instrument ends
05

Deliver an answer people can act on

The new round

Machine intelligence, from the mathematics up.

Every generation of engineers gets handed a new instrument. Mine is machine learning, and I refuse to treat it as a black box. A neural network is not magic. It is matrices, gradients, and an optimiser walking a loss surface. Training is numerics. Backpropagation is the chain rule at industrial scale. It is the same foundation again, wearing its newest clothes.

That is why I build with it rather than just prompt it. I wrote solvers in Fortran when the machinery was numerics. I moved them onto GPUs when the machinery was hardware. Now the machinery is learning to think, so I build agents and automated workflows around the models, inside engineering and beyond it. When you build the machinery yourself, you know what it can tell you, what it cannot, and where it will quietly mislead you.

epoch 000 · loss 2.0000 · lr 3e-4

A network training. Matrices, gradients, and an optimiser walking a loss surface. The same foundation.

solver.f90

$ ./solve --case duct_turbulent

reading mesh: 4.2M cells

iter 100 residual 4.1e-03

iter 200 residual 8.7e-05

iter 300 residual 2.2e-06

iter 400 residual 3.5e-08

converged.

writing fields... done

agent.run

$ agent run --task "check tenability report"

plan: extract results, test against criteria

act: parsing 14 output files

check: 2 exceedances found, flagged

revise: rerun scenario B, finer mesh

verify: all criteria met

done: report drafted for review

The old machinery and the new. Same instinct.

In practice

Solve it, and stand behind it.

In practice the work rarely starts with a model. It starts with a building, a code, and a question the code does not quite answer. Some days the instrument is a simulation. More days it is the clauses of the code, a Performance Solution, a report that has to stand in front of a fire authority. Every instrument ends somewhere, and everything past that line is judgement: checking results against reality, saying plainly what the analysis cannot say, and signing your name to the difference, because in my field the consequences of a wrong answer are measured in lives, not percentages.

Here is the kind of question that sits behind that sentence. A fire starts in a room. Hot gases rise, hit the ceiling, and spread. Above them, a sprinkler head waits for the air around it to reach 68 degrees. Everything about life safety turns on timing: how fast the fire grows, how soon the system responds, and what people can do with the seconds in between.

See it for yourself. Pick a growth rate and watch the race between the fire and the sprinkler. A slow fire gives the head minutes. An ultrafast one gives it seconds. That gap is the difference between a room you walk out of and a room you do not.

α = 0.0469 kW/s² (fast)

t = 0 s · Q̇ = αt² = 0 kW

T_jet at head ≈ 20 °C · growing

A design fire, growing at αt². The sprinkler ends it.

Every number in that panel is real. The growth coefficients come from the codes I work with. The head activates at a standard response temperature. The ceiling jet spreads the way ceiling jets spread. And still, the model is the easy half. The hard half is judgement: knowing when the model applies, when it does not, and signing your name to the difference. It is what makes someone hand over the problem that has been sitting on their desk for months. Bring me that one.

The toolbox

The right tool for the right problem.

Insight alone is not enough. To turn understanding into action you need tools: the right ones, sharp and ready. I think of an engineer's mind as a toolbox. Every discipline mastered, every method learned, every standard understood is another tool in the box. The wider the box, the more problems you can reach. The deeper the mastery of each tool, the better the answers get.

I took that idea literally and built it. EngToolbox is a free, vendor neutral engineering platform: hundreds of validated calculators, primary sourced data sheets and reference material across fire, CFD and general engineering. Designed, built and written solo, from the brand to the numerics. Open the box below.

EngToolbox is the toolbox made public. The one behind it comes with me onto every project.

Built to solve.

What is in the box?

Behind the work.

Sydney, Australia. Mechanical engineer by training, PhD in computational mechanics from UNSW, a decade across research and industry. The day job is performance based fire engineering on real buildings. Outside it I am always building: platforms, channels, models, tools, whatever the current problem needs. The disciplines change. The momentum does not.

If there is a problem on your desk that refuses to fit a template, I would like to hear about it. Get in touch.

Location: Sydney, Australia
Background: Mechanical engineering
Education: PhD (UNSW) · Grad Dip Fire Safety · MSc · BSc
Fire safety engineering: 3 years
Numerical methods & CFD: 7 years
Languages: Python · C++

Short CV View work View experience