Free practice is where a race team does its homework. Every lap is data, and back in the garage the engineers are asking one question: how much time is still out there?
Simulation is how teams answer that before the car goes back out. One of the most useful numbers it can produce is the theoretical perfect lap: the fastest the car could possibly go around the track without asking the tires or engine for more than they can give.
At JuliaCon 2026, Sebastian Micluța-Câmpeanu and Rajeev Voleti of JuliaHub set out to find that lap. They built the car in Dyad, JuliaHub's physics-based modeling platform, and solved it with ModelingToolkit, the open-source engine Dyad runs on. They raced their approach against a respected NASA-developed benchmark. Along the way, they ran into a false start, a head-to-head shootout and one lap that was too good to be true.
Why the perfect lap matters to a race team
A theoretical perfect lap is a yardstick. It tells you how much performance is left on the table, and where.
For a driver, comparing a real lap with the ideal one shows exactly where time goes: braking too early into a hairpin, or running wide on the exit of a fast corner. For engineers, it shows what a setup change is worth before anyone turns a wheel, because a different wing level or power map changes the perfect lap too.
It also travels well. In this project the track is a single swappable input, so the same car model can be pointed at a new layout and asked for its ideal lap without starting from scratch.
The catch is that the answer is only useful if you can trust it. A lap the car could never actually drive is worse than no answer at all.
The challenge: one lap, no cheating
Think of it as handing the car to a perfect virtual driver. That driver controls just two things: the throttle and brakes, and the steering. Everything else is set by physics.
The rules are the same ones any real car lives by:
The tires can only grip so much. Ask for too much braking or cornering force and the car slides.
The engine can only deliver so much power.
The lap has to join up. The car must finish the lap the same way it started it, so the result works lap after lap, not just once.
This is a deliberately simplified car. It captures the limits that matter most over a lap, grip and power, but it's nowhere near the full vehicle models a race team would use. It's a benchmark problem for comparing methods, and that's how to read the results that follow.
The benchmark for this challenge comes from Dymos, an optimization tool developed by NASA, which publishes a well-known race car example. That gave the JuliaHub team a respected reference time to chase: 22.27 seconds around the example track.
False start: planning the lap by the stopwatch
The obvious way to plan a lap is by time: what should the car be doing at 5 seconds, at 10 seconds, at 15? But there's a problem. The lap time is the very thing you're trying to find, so every point in the plan depends on a number you don't know yet. Change your guess for the lap time and the whole plan shifts with it.
That made the problem fragile. Of the three methods the team tried this way, one barely converged and two failed outright. Even when the team handed them the correct answer as a starting point, the struggling methods still couldn't settle on it. The trouble wasn't the solvers; it was the way the question was asked.
The fix is something every racing driver already knows. Drivers don't brake at "12.4 seconds into the lap." They brake at the 100-metre board. So the team rewrote the problem in terms of distance around the track instead of time. Now the plan is laid out over a fixed track length, and the lap time simply falls out at the end, like a stopwatch running alongside.
In the modeling tools behind Dyad, that switch took a single command, applied to the same car model. The methods that had stumbled are now solved cleanly.
The shootout
With the problem set up properly, it was time to race. The team ran the same Dyad car model through two different solving methods in ModelingToolkit and lined them up against the NASA benchmark, on the same computer with matched settings.
Approach | Perfect lap | Solver time |
Dymos (NASA benchmark) | 22.27 s | 242.6 s |
Dyad model, method 1 | 22.83 s | 6.3 s |
Dyad model, method 2 | 22.00 s | 1.43 s |
The lap times are within a fraction of a second, and that's the point: all three found the same racing line, with the same apexes, the same braking points and speeds between roughly 140 and 290 km/h. The small differences come from how finely each method samples the lap, not from finding different answers.
The real gap is in speed. The fastest method found the perfect lap in under a second and a half, about 170 times faster than the benchmark's four minutes. That's not because one programming language is quicker than another. Because the Dyad model is built from the physics equations themselves, ModelingToolkit can hand the solver exact information about how every input affects the result. The benchmark has to estimate that information, so it needs twice as many attempts, and each one is far more expensive.
For a race team, that's the difference between asking "what if?" a handful of times a weekend and asking it whenever you like.
One honest caveat: those are solver times only. The Dyad model has to be compiled before it can run that fast, and in the talk Sebastian put the full run, compilation included, at about 100 seconds. Dymos has much less setup overhead, so its full run stays close to its four-minute solver time. End to end, that puts the gap at about two and a half times rather than 170, and bringing compile time down is still on the team's list.
The lap that was too good to be true
Then a third method posted a stunning time: 21.84 seconds, comfortably faster than everything else. On a timing screen, that would put you top of the session.
It was also impossible.
This method only checked the rules at certain points around the lap. Between those checkpoints, nothing was watching. So right at the start of the lap, the optimizer found a loophole. It fired roughly 20 times the car's normal thrust, hit 115 m/s (over 400 km/h) and swung the engine's power wildly, all in the gap between two checks. It's the computer equivalent of cutting a chicane in the blind spot between track-limits sensors.
Nobody told the optimizer to cheat. It simply did what it was asked, ruthlessly, and the question had a hole in it. Once the team closed the loophole with proper limits on the controls and gave the solver a sensible starting point, the time settled at 22.02 seconds, right alongside the honest results. The loophole had been worth about 0.19 seconds, which in motorsport is a big gap.
Even the fastest honest method showed a smaller version of the same effect: brief steering spikes at corner exits, sitting between the 51 points where the limits were checked. The lesson for any team that relies on simulation is the same one stewards know well. If the rules are only enforced at certain points, something will find the gaps.
Pit-wall lessons
Getting a clean, trustworthy lap took more than a fast solver. Three lessons stood out, and they'll sound familiar to anyone who's worked a race weekend.
The first was keeping the numbers in proportion. The engine power figures in the model were about 100,000 times larger than the tire numbers, and left like that, the solver lost its way completely. Rescaling everything to a comparable size fixed it.
The second was where to start. Starting the solver right on the edge of a limit made it give up; starting comfortably inside the limits found the answer in 37 attempts.
The third was a single solver setting. With the defaults, the solver got stuck on a slow, corner-limited lap of 46.7 seconds, more than twice the real answer. Changing one setting found the true racing line from the very same starting point.
The encouraging part is that these are exactly the kinds of fixes a modeling tool can automate. If engineers record the typical size of each quantity in the model, the software can do the rescaling for them.
What's next: model in, racing line out
Today, finding the perfect lap still takes some specialist setup. JuliaHub plans to change that: a future version of Dyad's optimization tools will package this whole workflow into a single step. Describe the car and the track, and get the racing line back. It isn't available yet; the team is working on it for an upcoming release.
The same idea reaches well beyond motorsport. Any problem where you want to get from A to B as well as possible, within hard physical limits, works the same way: a drone's flight path, a spacecraft maneuver, or a robot arm's fastest safe motion. And as the too-good-to-be-true lap showed, the hard part isn't only finding a fast answer. It's being sure the answer obeys the physics.
