How I approach engineering.
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.
Drag to disturb the flow.
Flow past a cylinder. A live incompressible solver: change the Reynolds number and watch the wake change regime.
My work has spanned fluid mechanics, solid mechanics, heat transfer, thermodynamics and fire engineering. Although the applications differ, much of the underlying framework is shared: conservation laws, constitutive relationships, transport phenomena, numerical methods and experimental data.
Understanding that foundation makes it easier to move between disciplines and, more importantly, to understand the limits of the methods being used. In simulation, that means knowing what the governing equations and numerical model can represent. In engineering practice, it means understanding the physics and evidence behind a calculation, correlation or code requirement before applying it to a design. Taking that understanding and turning it into something that works in practice is what I call physics into practice.
Different fields. The same governing mathematics.
The method
From problem to answer.
My method varies with the problem, but the principles remain consistent. I start by defining what actually needs to be resolved, then reduce the problem to its fundamentals and understand the governing physics, constraints and available evidence. From there, I select the method that best fits the question: a numerical model, an engineering calculation, a code based assessment, experimental data, or sometimes a combination of them.
I then test the result against the available evidence and interpret it within the assumptions and limitations of the method. Engineering judgement runs through the entire process, from selecting the method to interpreting the result. The final step is turning the analysis into practice: a defensible engineering decision, a clear recommendation, or documentation that others can approve, design or build from.
From problem to answer
- 01
Define the problem
- 02
Understand the physics
- 03
Select the right method
- 04
Verify and apply judgement
- 05
Turn the answer into practice
Physics into practice.
Research-grade depth · Industry-grade answers
The new round
Machine intelligence, from the mathematics up.
Every generation of engineers is handed new tools. Mine includes machine learning, and I refuse to treat it as a black box. Neural networks are matrices, gradients and optimisation working together. Training is numerics. Backpropagation is the chain rule applied repeatedly across a network. Beneath the terminology, much of it rests on the same mathematical foundation I have worked with throughout computational engineering.
That is why I build with it rather than just prompt it. I wrote solvers in Fortran and C++ when my work centred on numerical methods, moved them onto GPUs when performance required parallel computing, and now build agents and automated workflows around AI models. Building the underlying systems helps me use them more effectively, streamline technical workflows, and create tools that make engineering work faster and more capable.
epoch 000 · loss 2.0000 · lr 3e-4
A network training. Matrices, gradients, and an optimiser walking a loss surface. The same foundation.
The old machinery and the new. Same instinct.
In practice
One example in practice.
The approach above is not specific to one discipline. To make it concrete, here is a simple example from fire safety engineering, one of the areas I work in.
Consider a room fire and a straightforward engineering question: how long will it take for a sprinkler to respond? The answer starts with the physics. As the fire grows, a plume carries hot gases towards the ceiling, where they spread outward as a ceiling jet. The temperature and velocity of that flow, together with the sprinkler's location and thermal response characteristics, determine how quickly the sprinkler heats and activates.
The interactive model applies a simplified version of that process. Select a fire growth rate and follow how the heat release rate, ceiling jet conditions and predicted sprinkler response develop with time. Change the input and the resulting response changes with it.
Select a fire growth rate to see how the predicted response changes.
A growing design fire and the predicted thermal response of a sprinkler.
This is only one small fire engineering example, but it illustrates the wider process: define the question, understand the underlying physics, select an appropriate method, interpret the result with engineering judgement, and turn it into something that can inform a practical decision. The physics and tools change from one field to another; the approach does not.
The toolbox
Tools are part of the method.
I have always seen engineering tools as an extension of the underlying method. Depending on the problem, I may need a simulation, a calculation, a standard, experimental data or a small piece of code written specifically for the task. The important part is not having more tools, but understanding which one fits the problem and how far its result can be trusted.
Over time, I started turning many of those methods into reusable tools. That eventually became EngToolbox: a free engineering platform containing calculators, technical references, data sheets and articles across fire safety, CFD and general engineering.
EngToolbox is a public extension of the same approach I use in my own work: turning engineering knowledge into practical, reusable tools that are understood, tested and applied properly.
Built to solve.
Behind the work.
I am a Sydney based mechanical engineer with a PhD in Mechanical Engineering from UNSW and a career spanning research and engineering practice. I continue to work across computational mechanics, fluid dynamics, numerical methods, fire safety engineering and machine learning, often bringing these areas together within the same problem.
What interests me most are problems that need more than one way of thinking. I like moving between physics, computation, standards and practical constraints, and bringing them together into a solution that is technically sound and useful in practice.
If you have an interesting engineering problem, research idea or potential collaboration, I would be glad to hear about it. Get in touch.
- Location
- Sydney, Australia
- Background
- Mechanical Engineering
- Education
- PhD Mechanical Engineering (UNSW) · Grad Dip Fire Safety Engineering · MSc · BSc
- Fire safety engineering
- Performance-based design · Fire & smoke modelling
- Computational mechanics
- Numerical methods · Solver development · HPC
- Programming
- Python · C++