Skip to content

Solver Tracing: "Why wasn't this pairing built?"

The most common support ticket an airline Rave developer receives from the business is: "Flight A arrives in Oslo at 10:00. Flight B departs Oslo at 12:00. Why didn't the optimizer put them in the same pairing?"

To answer this, you cannot just look at the code. You must trace the generator's search tree to find exactly which rule or cost penalty killed that specific connection during the Subproblem phase.

1. The Challenge of Multi-Stage Debugging

Because the optimization process is a multi-stage transformation (building legs into duties, duties into trips, and assessing costs), debugging the overall transformation can become hard.

If a connection wasn't built, one of three things happened:

  1. Pruned by a Final Rule: A hard legality check killed the branch.
  2. Killed by a Heuristic: The generator determined the branch was mathematically unpromising before it finished.
  3. Priced Out: The pairing was generated, but the Master Problem determined another pairing was cheaper.

2. Using Tracing Tools

To debug this, developers use solver tracing tools. These tools keep all intermediate models around for debugging purposes, allowing the developer to inspect the trace and find out where the element was transformed or rejected.

sequenceDiagram
    participant Dev as Rave Developer
    participant Trace as Trace Log / Debugger
    participant Gen as Pairing Generator

    Dev->>Gen: Run generation for Flight A -> Flight B only
    Gen->>Trace: Output rule evaluation log
    Trace-->>Dev: "Rule 'min_sit_time' evaluated to False"
    Dev->>Dev: Inspect trace: Sit time was 29 mins, rule requires 30.

3. The "Forced Pairing" Strategy

The ultimate debugging technique is the Forced Pairing Strategy.

If the business asks why a specific pairing wasn't built naturally by the optimizer, you configure the solver to force the creation of that exact pairing, bypassing normal heuristics.

  • If it fails to build: The trace log will spit out the exact Rave CONSTRAINT that evaluated to False. You now know it's a legality issue.
  • If it builds successfully: You look at the PROPERTY cost of the forced pairing. You will often find a massive soft penalty (e.g., a penalty for a short layover) that made it too expensive for the optimizer to choose naturally. You now know it's a cost/tuning issue.