Numerical analysis · Scientific computing

When can a fast approximation be trusted?

Complex scientific and engineering problems often require calculations that are too slow or costly to repeat. Faster methods can provide an answer, but how do we know when that answer can be trusted without running the full calculation?

This research develops methods that provide that assurance.

One number to keep in mind
0
solves for a brute-force parameter sweep
0
solves for the adaptive method — with an error certificate

Same accuracy target, orders of magnitude less compute — and you get a bound telling you where the answer is trustworthy. Play the sampling game →

Three problems this work solves

All three revolve around eigenvalues — the natural frequencies and patterns a design responds with when it is pushed, loaded, or shaken. Start with the background, with sound →

Problem 1

My simulations are too expensive to run for the desired design and operating conditions.

An adaptive method decides which cases require a full simulation — and certifies the cases that can safely be skipped.
Problem 2

My fast surrogate is great… until it silently isn't.

Where systems change character — frequencies collide, modes swap — smooth shortcuts fail. This method flags exactly those regions.
Problem 3

My model reasons from similar past cases. Should I trust it?

A certificate that grades the evidence behind a prediction: if the supporting cases churn when the input wiggles, don't trust it.
Background · one concept

Every design has its own frequencies

When you design something that has to work in the real world, you decide how it is shaped, what it is made of, how it is supported, and the conditions in which it must operate. Those choices determine how it will respond when it is pushed, loaded, shaken, or otherwise disturbed.

That response is not arbitrary: every design has particular patterns in which it naturally tends to move or deform, each occurring at its own frequency. If one of those frequencies lies near the forces the design will encounter in operation, vibration can build, instability can appear — and a design that looked sound on paper may fail in practice.

These characteristic frequencies and patterns are what mathematicians call eigenvalues and eigenvectors — the vocabulary used throughout this page.

Designing successfully therefore means understanding and steering these frequencies:

That tracking-and-certifying problem is what this work solves.

Move the partition

Below is a miniature two-chamber instrument: a pipe divided by a movable partition, with a small opening coupling the two chambers. Moving the partition drives the chambers' resonant frequencies in opposite directions — one chamber lengthens and its frequencies fall, the other shortens and its frequencies rise. With the opening closed the two families can meet and cross exactly; with it open, the chambers interact and the crossing is avoided. (Under the hood it's the honest discrete version: two four-mass strings joined by a flexible bridge, solved live.)

Try it: set the opening to zero and watch two curves pass straight through each other. Open it and watch them repel instead. Then park the partition near the closest approach and listen — the two tones beat, slower as the gap closes, but never stopping while the chambers are coupled.

Curve color shows where each mode lives: left chamber, right chamber, in between — mixed. Follow one curve through an avoided crossing and watch its color swap: "the second-lowest frequency" and "the mode that began in the left chamber" part ways there. That is why tracking eigenvalues by their sorted order is not the same as tracking the physical mode — and it is exactly what breaks fast surrogates.

Sound plays only when you press the button — it plays the two closest modes together so the beats are audible.

The catch that motivates everything here: computing these frequencies for a real design (a full aircraft panel, a reactor coil) takes minutes-to-hours per design variant — and design spaces have thousands of variants. That cost is what the adaptive method attacks.
Problem 1 · expensive simulations

Spend solves like money

You have a design space — say, two knobs on a component — and each evaluation of a design is an expensive simulation. You can't afford the full sweep. Where do you spend your solves?

Level 1 — you place the solves

Click (or tap) up to 12 points in the design space below. The heatmap then reveals where your reconstruction is still wrong. The ridge you'll probably miss is where two eigenvalues nearly collide — precisely where behaviour changes fastest.

0
solves spent
—
worst remaining error

Level 2 — the adaptive method places them

Now watch the greedy algorithm from the research: each step, it asks a cheap error indicator "where am I most wrong?", solves there, and updates. Shaded regions are certified: the indicator bounds the error below the target, so no further solve is spent on them.

0
solves spent
—
worst remaining error
0%
of design space certified
The point is not that the algorithm beats your intuition on a toy — it's that it does this in six-dimensional design spaces, where intuition has no picture to look at, and returns a certificate instead of a hope.
Problem 2 · silent surrogate failure

Where the shortcut breaks — and how to know

You met avoided crossings in the background: eigenvalue curves repel at close range and their modes swap character. Fast surrogates assume the world changes smoothly — which is exactly what stops being true there. The result is a shortcut that tracks the wrong thing, confidently.

Watch a smooth surrogate miss the gap

The demo solves a small system live as you drag the design parameter. The symmetry toggle switches the interaction's character: with symmetry enforced the two curves cross cleanly; break it, and they repel — the avoided crossing again, this time seen through the eyes of an approximation.

Now add a lazy surrogate

The dashed line is what a cheap interpolant built from a few samples believes. Away from the collision it's fine. Near it, it's wrong exactly where the design is most sensitive — and nothing in the surrogate itself warns you. The shaded band is the region the research's error indicator flags: "do a real solve here."

Silent failure is the expensive kind: a flutter margin or a filter passband missed not because the model was bad everywhere, but because it was bad in the one narrow region that mattered.
Problem 3 · trust by analogy

We don't grade the answer — we grade the evidence

Many production models reason by analogy: to value this house, look at similar recent sales; to judge this claim, look at similar past claims. The prediction inherits its credibility from the supporting cases. So interrogate the support.

Wiggle the input

Below, a toy predictor estimates a value from its k nearest past cases (highlighted). Drag the query point. The trust light doesn't watch the prediction — it watches the support set: if a tiny wiggle in the input swaps out the cases the answer rests on, the evidence was fragile, whatever the number says.

stable evidence

This is a certificate on the evidence, orthogonal to the model: it can ride on top of any similarity-based system without retraining it. Stable support doesn't make a prediction right — but churning support tells you, cheaply and before the fact, that this particular answer isn't resting on anything solid.
About

Who's behind this

I'm Moataz Alghamdi — PhD in applied mathematics (KAUST, 2025), working on certified model reduction for parametric eigenvalue problems and on certificates for similarity-based evidence.

This site is the intuitive face of the work. The technical record — algorithms, proofs, convergence studies, reproducible figures — lives in the figure book, which every demo here links back to.

What I'm looking for

Conversations with teams whose pain matches the problems: expensive parametric simulations, surrogates that fail near mode interactions, or similarity-based predictions that need a trust layer. If one of the three problems sounded like your Tuesday, I'd like to hear about it.

Contact

Email: moatazalghamdi@gmail.com
GitHub: github.com/Moatazg