Race Conditions¶
The Race Conditions component defines how you race the lap — the energy you are allowed to spend, whether the car has a push-to-pass boost available, and whether the racing line is re-optimised for the run.
These settings used to live in the run dialog
Energy budget, push-to-pass and racing line re-optimisation were previously set inside the Lap Time run form and reset after every run. They are now a vehicle component in their own right, so they save, version and duplicate alongside the rest of your setup. The run form shows a one-line summary of the race conditions in effect, with an Edit link through to this page.
Overview¶
The Race Conditions setup defines:
- Energy - A cap on propulsive energy delivered at the wheels over a lap
- Push-to-Pass - A temporary higher torque map, deployed automatically to a budget or placed by hand
- Racing Line - Whether to re-optimise the line for this run rather than driving the stored one
Because Race Conditions is a component like any other, it can be selected, published and swept. See Component Hierarchy and Component Publishing.
Energy¶
An Energy Budget caps the total propulsive energy delivered at the wheels over a single lap. Rather than refusing to exceed the cap, the solver returns the fastest lap achievable within it, deciding for itself where on the lap to save.
Leave the field empty for an unconstrained lap. The unit is selectable.
What counts against the budget
Only propulsive energy at the wheels is counted. Regeneration is not credited back against the budget.
Because the cap applies per lap, the budget only applies when Lap Count is 1.
Push-to-Pass¶
Push-to-Pass models a temporary engine boost — the "overtake" button used in series such as Formula Regional, IndyCar and Super Formula. The engine switches to a second, higher torque map for a limited part of the lap.
The Push-to-Pass section only becomes available once the vehicle's engine has a Push-to-Pass Torque Curve defined (Powertrain → Engine). It is a single-lap feature.
| Mode | What it does |
|---|---|
| Budget | Enter a number of seconds of deployment. The solver finds where on the lap those seconds buy the most lap time and deploys there automatically. A budget of 0 runs the lap without push-to-pass. |
| Place zones manually | Turn on Place zones manually and define each activation yourself as a start distance and a duration in seconds, on a track map. Useful for comparing your own strategy against the automatic one. |
Deployment is measured in time, not distance: because the boost makes the car faster, a fixed distance is covered in less time, so the budget is the seconds actually spent boosting.
Manual zones and an energy budget cannot be combined
An energy budget asks the solver to decide where to spend energy, while manual zones fix that decision in advance. Setting both is blocked with an explanation — choose one.
Two output channels report what happened:
| Channel | Description |
|---|---|
| BPushToPassActive | 1 where the boosted map is active, 0 otherwise |
| tPushToPassTotal | Cumulative deployment time — the final value is the total spent on the lap |
Balance of Performance¶
Balance of Performance models a regulated power restriction that varies with road speed — the rule used in LMGT3 and GTD, where the car is held to a percentage of its homologated power curve, and that percentage changes above a given speed.
The rule splits across two components. The homologated ceiling itself is Max Power on Powertrain → Engine, because it is a property of the car. The event-specific percentage lives here, because it changes from race to race.
Turn on Power adjustment to enable it.
| Field | Description | Unit |
|---|---|---|
| Power below V1 | Percentage of Max Power allowed below the first speed threshold. | % |
| V1 | The first speed threshold. | km/h |
| Power above V2 | Percentage of Max Power allowed above the second speed threshold. | % |
| V2 | The second speed threshold. | km/h |
Between V1 and V2 the allowed fraction ramps in a straight line between the two percentages. Setting V1 equal to V2 produces a single step, which is the shape WEC and IMSA actually publish — 200 km/h in WEC LMGT3, 205 km/h in the FIA GT World Cup.
A live chart draws the resulting power fraction against speed as you type, so a step reads differently from a ramp at a glance, and a mistyped decimal (0.985 where 98.5 was meant) shows up immediately as an implausible shape rather than a silently wrong answer. Values more than 50% away from an unrestricted car are flagged.
Converting a published BoP table
Published tables give a P-number — the percentage taken off the base curve — and a separate high-speed gain expressed relative to the low-speed figure, rather than the two absolute percentages this form wants. The helper text on the field walks through the conversion.
Both percentages at 100%
If both are 100%, the run is effectively unrestricted: Max Power still applies as the car's ceiling, but nothing scales it down. The panel tells you so.
Requires Max Power on the Engine
The Balance of Performance panel stays disabled until Max Power is set on the Engine, and links to where to set it. There is no percentage to apply without a ceiling to apply it to.
One output channel reports what happened:
| Channel | Description |
|---|---|
| PPowertrainLimitBop | The regulation's power cap over the lap, in kW, whether or not it was binding |
Racing Line¶
By default the simulation drives whichever line is stored on the track — the centreline, or an optimised line saved from the Track page's Racing Line panel.
Turn on Re-optimise for this run to compute a fresh line for this run's vehicle and, if set, its energy budget, instead of driving the stored one. Use it when a setup or vehicle change is significant enough to move the fastest trajectory through the corridor.
Re-optimised runs are not line-comparable
Runs with this enabled are slower, and their lap times are no longer comparable with runs on the stored line, because the trajectory itself has changed. Leave it off when comparing setups against each other with the line held constant.
Requires track width
Racing line optimisation needs a track corridor to work within, so it is only available on tracks that carry width data. See Track.
Replaying a Logged Lap¶
Instead of solving for a lap, the simulation can replay one you logged. Point Race Conditions at an uploaded telemetry lap and the solver follows its speed trace around the track.
This is the core correlation workflow: the lap time is the one you measured, so everything the model computes on top of it — tyre loads, ride heights, damper travel, grip usage — can be compared directly against the same lap's logged channels, with no lap-time difference confusing the picture.
Use Browse to pick a lap from your uploaded results, or upload one from the panel. Replaying can be stopped at any time to return to a normally solved lap.
Choosing What the Lap Imposes¶
Two channels from the log can be imposed on the model instead of being computed. Each is optional, and each is offered only when the lap actually carries that channel — a channel your lap does not have is shown but disabled, so you can see what logging it would unlock.
| Option | Channel | Effect |
|---|---|---|
| Use the logged line | nYaw |
Cornering loads come from the logged yaw rate, so they describe the path actually driven rather than the racing line the solver would have picked. |
| Use the logged gear | NGear |
Engine speed follows the driver rather than the model's shift map. The lap time does not change, since the speed is already fixed by the trace. |
Anything not imposed stays the model's own, and is therefore something you can compare against the log rather than something you have handed it.
Placement and Confidence¶
Before it can run, the lap has to be placed on the track's geometry — this is what decides which corner's curvature each telemetry sample is evaluated against. Getting it wrong produces results that look plausible and are not, so the panel reports what placement did rather than doing it silently.
When placement succeeds, the panel tells you how far into the track the lap begins, along with the offset to apply in the results viewer. This matters because a replay is drawn against track distance while the logged lap is drawn against the logger's own, so the two do not overlay until you shift one by that amount.
Approximate placement
If the logged and simulated trajectories align only approximately, the panel says so. Cornering loads are computed against the racing line, so the offset lands in lateral acceleration and can push it to unrealistic values. Re-optimise the line on the Track page to match how the car was driven, or upload a lap carrying a yaw-rate channel so the path can be reconstructed.
Laps that cannot be placed on speed alone
A lap whose speed varies too little cannot be placed against the track's corners by itself. Check it against the track by eye before running, or upload a lap with a yaw-rate channel.
Sweeping Race Conditions¶
Race Conditions appears as its own category in the sweep parameter selector, so you can compare energy budgets or push-to-pass strategies across a sweep in the same way as any other component. See Parameter Sweeps.
Next Steps¶
- Lap Time Simulation - How each setting affects the solved lap
- Track - Storing and optimising a racing line
- Parameter Sweeps - Sweeping race conditions across runs
- Results Upload - Uploading the telemetry laps used for replay