Interests

Process systems engineering (opens in a new tab) looks at a plant as one connected system rather than a row of separate units: reactors, separators and heat exchangers, each with its own physics, tied together by streams, recycles and constraints. It asks for rigorous modeling and a practical decision at the same time.

Separation is often where most of the energy goes, and even the order of the cuts is a design decision. A four-component feed can be split by three simple columns in five different sequences; the direct sequence, which takes the lightest component off the top first, is only one of them.

Underneath every model is hardware that moves fluids and holds a setpoint. A control loop ends in a valve: the controller computes an opening, and a quarter turn of a ball sets how much of the line is open.

Most of the plants I think about are energy systems in the end. The questions I keep returning to are where the heat goes, how much of it can be won back, and how to make the same product with less energy and fewer emissions.

Once a process can be written down, designing it becomes a question of choosing. Optimization makes the choice exact: variables, constraints and an objective, and a solver that searches a space far too large to try by hand. I like how much engineering judgment turns out to fit in that form.

The discrete choices are what make it hard. Whether to build a unit at all is a yes-or-no variable, so a design problem becomes a mixed-integer program, and the solver has to reason about a lattice of integer points instead of a smooth region.

A superstructure takes that to the whole flowsheet. It holds every candidate technology and every link between them, and the solver keeps only the ones worth building.

Real objectives also pull against each other. Cost and emissions rarely fall together, so the useful answer is the whole curve of trade-offs, and a decision maker picks a point on it.

Optimization quietly assumes the numbers are known. They rarely are: renewable supply moves by the hour, prices and demand drift, and a plant designed for the average day can fail on the real one. Stochastic models put that randomness into the problem itself.

My favourite form is the two-stage program. Fix the design now, let the operation adapt once each scenario plays out, and optimize the expected cost over all of them together. The value of doing so can be measured as the gap between the stochastic answer and the deterministic one. It was the core of my undergraduate research.

The same idea carries into control. Model predictive control solves a small optimization at every step over a moving horizon, applies only the first move, and plans again once new measurements arrive, which is how it absorbs disturbances it could not predict.

I came to machine learning from the computer engineering half of my degree and stayed because it changes the modeling question. Where a first-principles model is weak or too slow, a learned one can fill the gap, as long as it respects the physics and the constraints around it. Underneath almost all of it is one loop: follow the gradient of a loss downhill, a small step at a time.

The simplest learners are still the clearest way to see what a model does. k-nearest neighbours has no training step at all: a new point takes the vote of the k closest examples, and the decision boundary is simply where that vote changes.

Knowing how sure a model is matters as much as the prediction, which is where learning meets the stochastic side again. Conformal prediction wraps any forecaster in an interval with guaranteed coverage, built from nothing but its past errors.

Language models are the newest piece, and the one I use every day. Inside, a transformer is attention repeated many times: each token looks back at the ones before it and takes a weighted mix of what it finds.

What interests me most is putting them to work on science, reading papers at scale and turning text into data that other models can use.

Outside research I build the software I want to use, mostly for the Mac and iPhone in Swift, and I care as much about how it feels as about what it does.

Right now that means SnapLayouts, Seemantic and Quotlas. They are on the work page.

I studied chemical and biological engineering alongside computer engineering, and I want to be an interdisciplinary, architect-minded generalist who connects fields and turns ideas into well-designed systems.

My degree tracks were Energy and Process Systems Engineering on one side and Artificial Intelligence on the other, and this page sits between the two.