Grading date: 2026-05-18 17:42
Automated feedback for Assignment 1. Open a case to see what was expected, what your submission produced, and which files to inspect next.
Run scope: Full run across the loaded DARP and Watertaxi cases (43 total).
Case outcomes: 14 fully correct, 29 partial, 0 with no passing checks, 0 not assessed after an earlier run or output problem, 0 reduced-scope, 0 otherwise not assessed.
Automated checks passed: 340 / 409 (83%)
Compatibility handling: In 5 cases, the grader accepted an alternate flag, file, or entrypoint layout before checking correctness. This affected 35 passing checks.
| Check Area | Passed | Needs Work | Not Assessed | Counts Toward Grade? |
|---|---|---|---|---|
| Execution | 48 / 48 | 0 | 0 | No |
| Output format | 2 / 2 | 0 | 0 | No |
| Correctness | 290 / 451 | 69 | 92 | Yes |
Start with the most widespread problem first. Fixing one root cause often clears several cases at once.
These cases only ran because the grader accepted an alternate command-line form. The results could still be checked, but your submission should work with the published assignment CLI directly.
Affected checks: 35
| Case | Affected Checks | What The Grader Accepted | What You Should Fix |
|---|---|---|---|
| darp-02-capacity - Vehicle capacity forces one rejection | 3 | Alternate distance objective form accepted | Your CLI requires `--objective unserved=2000;distance=1` to run distance cases, but the assignment specifies `--objective distance`. Update your CLI to accept `distance` alone without a rejection-penalty prefix. |
| darp-10-max-route-duration - Max route duration forces one rejection | 3 | Alternate distance objective form accepted | Your CLI requires `--objective unserved=2000;distance=1` to run distance cases, but the assignment specifies `--objective distance`. Update your CLI to accept `distance` alone without a rejection-penalty prefix. |
| darp-11-all-infeasible - All requests infeasible — both must be rejected | 5 | Alternate distance objective form accepted | Your CLI requires `--objective unserved=2000;distance=1` to run distance cases, but the assignment specifies `--objective distance`. Update your CLI to accept `distance` alone without a rejection-penalty prefix. |
| darp-18-batch-same-dest-fit - Same pickup and same dropoff — requests stay separate | 12 | Alternate distance objective form accepted | Your CLI requires `--objective unserved=2000;distance=1` to run distance cases, but the assignment specifies `--objective distance`. Update your CLI to accept `distance` alone without a rejection-penalty prefix. |
| darp-21-batch-identical-requests - Identical requests must not be merged | 12 | Alternate distance objective form accepted | Your CLI requires `--objective unserved=2000;distance=1` to run distance cases, but the assignment specifies `--objective distance`. Update your CLI to accept `distance` alone without a rejection-penalty prefix. |
Open a case to see the expected result, the observed result, and the evidence files you should inspect next.
capacity 1 prevents ride-sharing, and tight pickup windows prevent serving both requests one after the other — the solver must reject one
1 vehicle with capacity 1, 2 requests with overlapping time windows. The vehicle can only carry 1 passenger at a time. Picking up one passenger and dropping it off takes too long to return for the second before its pickup window closes, so one request must be rejected.
Capacity is 1, so the vehicle cannot carry both passengers at once. R1 pickup at (5,0) tw=[5,10] min and R2 pickup at (6,0) tw=[5,10] min. Serving R1 first (pickup t = 5 min, dropoff t = 10 min) means the vehicle cannot reach R2 before its window closes at t = 10 min. The same happens in reverse. Exactly 1 request must be rejected.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (5, 0) | 0 | [5, 10] | 3 | (10, 0) | 0 | [10, 20] |
| R2 | 1 | 2 | (6, 0) | 0 | [5, 10] | 4 | (11, 0) | 0 | [10, 20] |
| 0 | 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|---|
| 0 | 0 | 5 | 6 | 10 | 11 | 0 |
| 1 | 5 | 0 | 1 | 5 | 6 | 5 |
| 2 | 6 | 1 | 0 | 4 | 5 | 6 |
| 3 | 10 | 5 | 4 | 0 | 1 | 10 |
| 4 | 11 | 6 | 5 | 1 | 0 | 11 |
| 5 | 0 | 5 | 6 | 10 | 11 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 5. Depot window = [0, 40] min (= [0, 2400] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [5, 10] min. Dropoff windows range from [10, 20] min. Route duration limit T = 40 min (= 2400 s in outputs). |
| Ride rule | Maximum ride time L = 20 min (= 1200 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
non-overlapping pickup windows force a specific service order — the solver must respect earliest and latest pickup times
1 vehicle, 2 requests with non-overlapping pickup windows. R2's window [5, 10] closes before R1's window [15, 20] opens, so the vehicle must pick up R2 first and R1 second.
R2 pickup at (5,0) tw=[5,10] must come first. R1 pickup at (6,0) tw=[15,20] must come second. Best route: depot(0,0)→P_R2(5,0)→P_R1(6,0)→D_R2(10,0)→D_R1(12,0)→depot(0,0). Total distance = 5 + 1 + 4 + 2 + 12 = 24.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (6, 0) | 0 | [15, 20] | 3 | (12, 0) | 0 | [20, 30] |
| R2 | 1 | 2 | (5, 0) | 0 | [5, 10] | 4 | (10, 0) | 0 | [10, 20] |
| 0 | 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|---|
| 0 | 0 | 6 | 5 | 12 | 10 | 0 |
| 1 | 6 | 0 | 1 | 6 | 4 | 6 |
| 2 | 5 | 1 | 0 | 7 | 5 | 5 |
| 3 | 12 | 6 | 7 | 0 | 2 | 12 |
| 4 | 10 | 4 | 5 | 2 | 0 | 10 |
| 5 | 0 | 6 | 5 | 12 | 10 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 5. Depot window = [0, 40] min (= [0, 2400] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [5, 20] min. Dropoff windows range from [10, 30] min. Route duration limit T = 40 min (= 2400 s in outputs). |
| Ride rule | Maximum ride time L = 20 min (= 1200 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
the classic distance-focused run should report pickup delay correctly when a later request is served after its earliest pickup time
1 vehicle, 2 requests. The distance-feasible route reaches R2 at t = 15 min, while R2's earliest pickup is t = 10 min. That creates 5 min of pickup delay for R2, so total_wait_s = 300 s in outputs.
Distance-feasible route: depot→P1→D1→P2→D2→depot. Total distance = 5 + 5 + 5 + 5 + 20 = 40 km (= 40000 m in outputs). The vehicle reaches R2 at t = 15 min, while R2's earliest pickup is t = 10 min, so R2 contributes 5 min (= 300 s) of pickup delay to total_wait_s.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (5, 0) | 0 | [0, 50] | 3 | (10, 0) | 0 | [0, 50] |
| R2 | 1 | 2 | (15, 0) | 0 | [10, 30] | 4 | (20, 0) | 0 | [0, 50] |
| 0 | 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|---|
| 0 | 0 | 5 | 15 | 10 | 20 | 0 |
| 1 | 5 | 0 | 10 | 5 | 15 | 5 |
| 2 | 15 | 10 | 0 | 5 | 5 | 15 |
| 3 | 10 | 5 | 5 | 0 | 10 | 10 |
| 4 | 20 | 15 | 5 | 10 | 0 | 20 |
| 5 | 0 | 5 | 15 | 10 | 20 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 5. Depot window = [0, 50] min (= [0, 3000] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [0, 50] min. Dropoff windows range from [0, 50] min. Route duration limit T = 50 min (= 3000 s in outputs). |
| Ride rule | Maximum ride time L = 20 min (= 1200 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
the max route duration constraint must force the solver to reject one request when serving both would exceed the time limit
1 vehicle, 2 requests. Max route duration T = 30 min (= 1800 s in outputs). Serving both requests in one route takes longer than that, so the solver must reject one and serve only one.
Depot at (10,0). Serving both requests takes at least 40 min (= 2400 s), which exceeds T = 30 min (= 1800 s). Serving either one alone takes 20 min (= 1200 s), which fits. n_rejected must be 1.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (15, 0) | 0 | [0, 30] | 3 | (20, 0) | 0 | [0, 30] |
| R2 | 1 | 2 | (5, 0) | 0 | [0, 30] | 4 | (0, 0) | 0 | [0, 30] |
| 0 | 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|---|
| 0 | 0 | 5 | 5 | 10 | 10 | 0 |
| 1 | 5 | 0 | 10 | 5 | 15 | 5 |
| 2 | 5 | 10 | 0 | 15 | 5 | 5 |
| 3 | 10 | 5 | 15 | 0 | 20 | 10 |
| 4 | 10 | 15 | 5 | 20 | 0 | 10 |
| 5 | 0 | 5 | 5 | 10 | 10 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (10, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 5. Depot window = [0, 30] min (= [0, 1800] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [0, 30] min. Dropoff windows range from [0, 30] min. Route duration limit T = 30 min (= 1800 s in outputs). |
| Ride rule | Maximum ride time L = 20 min (= 1200 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
the solver must reject every request when no pickup can be reached before its time window closes
1 vehicle, 2 requests. Each pickup node is farther from the depot than its latest pickup time allows. The vehicle cannot reach either pickup in time, so both must be rejected.
R1 pickup at (10,0) tw=[5,6] min: the vehicle needs 10 min (= 600 s) to arrive, but the window closes at t = 6 min (= 360 s). R2 pickup at (15,0) tw=[5,6] min: the vehicle needs 15 min (= 900 s), and the window also closes at t = 6 min (= 360 s). Both are unreachable, so n_rejected = 2 and total_distance_m = 0.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (10, 0) | 0 | [5, 6] | 3 | (12, 0) | 0 | [0, 40] |
| R2 | 1 | 2 | (15, 0) | 0 | [5, 6] | 4 | (18, 0) | 0 | [0, 40] |
| 0 | 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|---|
| 0 | 0 | 10 | 15 | 12 | 18 | 0 |
| 1 | 10 | 0 | 5 | 2 | 8 | 10 |
| 2 | 15 | 5 | 0 | 3 | 3 | 15 |
| 3 | 12 | 2 | 3 | 0 | 6 | 12 |
| 4 | 18 | 8 | 3 | 6 | 0 | 18 |
| 5 | 0 | 10 | 15 | 12 | 18 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 5. Depot window = [0, 40] min (= [0, 2400] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [5, 6] min. Dropoff windows range from [0, 40] min. Route duration limit T = 40 min (= 2400 s in outputs). |
| Ride rule | Maximum ride time L = 20 min (= 1200 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
the solver must handle time windows where the vehicle arrives right at the boundary without violating them
1 vehicle, 1 request. The pickup window [4, 6] and dropoff window [8, 12] barely fit the travel times. The vehicle arrives right at the edge of each window.
Pickup at (5,0) tw=[4,6] min: the vehicle travels 5 km from the depot, so it arrives at t = 5 min (within [4,6]). Dropoff at (10,0) tw=[8,12] min: the vehicle travels 5 km from pickup to dropoff, so it arrives at t = 10 min (within [8,12]). Distance = 5 + 5 + 10 = 20 km (= 20000 m in outputs).
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (5, 0) | 0 | [4, 6] | 2 | (10, 0) | 0 | [8, 12] |
| 0 | 1 | 2 | 3 | |
|---|---|---|---|---|
| 0 | 0 | 5 | 10 | 0 |
| 1 | 5 | 0 | 5 | 5 |
| 2 | 10 | 5 | 0 | 10 |
| 3 | 0 | 5 | 10 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 3. Depot window = [0, 30] min (= [0, 1800] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [4, 6] min. Dropoff windows range from [8, 12] min. Route duration limit T = 30 min (= 1800 s in outputs). |
| Ride rule | Maximum ride time L = 20 min (= 1200 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
the max ride time constraint must block interleaving when the detour pushes ride time just past the limit
1 vehicle with capacity 2, 2 requests in a 2D plane. Max ride time L=12. Each direct ride is 8 (OK), but interleaving P1-P2-D1-D2 gives rides of about 12.2 (exceeds L=12). The solver must go sequential.
L = 12. Direct rides are 8 each (well within L). Interleaving P1-P2-D1-D2 gives ride times around 12.2 > L=12. The solver must serve P1-D1 then P2-D2 (or vice versa). Expected distance ~36.50.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (1, 2) | 0 | [0, 40] | 3 | (9, 2) | 0 | [0, 40] |
| R2 | 1 | 2 | (2, -2) | 0 | [0, 40] | 4 | (10, -2) | 0 | [0, 40] |
| 0 | 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|---|
| 0 | 0 | 2.24 | 2.83 | 9.22 | 10.2 | 0 |
| 1 | 2.24 | 0 | 4.12 | 8 | 9.85 | 2.24 |
| 2 | 2.83 | 4.12 | 0 | 8.06 | 8 | 2.83 |
| 3 | 9.22 | 8 | 8.06 | 0 | 4.12 | 9.22 |
| 4 | 10.2 | 9.85 | 8 | 4.12 | 0 | 10.2 |
| 5 | 0 | 2.24 | 2.83 | 9.22 | 10.2 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 5. Depot window = [0, 40] min (= [0, 2400] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [0, 40] min. Dropoff windows range from [0, 40] min. Route duration limit T = 40 min (= 2400 s in outputs). |
| Ride rule | Maximum ride time L = 12 min (= 720 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
two requests at the same pickup node and time with different destinations should be served by one vehicle when the combined load fits
1 vehicle with capacity 2, 2 requests at the same pickup node (5,0) in the same time window [5, 6]. Dropoffs differ: (10,0) and (15,0). The vehicle picks up both before leaving, then drops off one by one.
Both pickups are at x=5 with tw=[5,6]. One vehicle picks up both with load 2, then drops R1 at x=10 and R2 at x=15. Route: depot(0)→P1(5)→P2(5)→D1(10)→D2(15)→depot(0). Total distance = 5 + 0 + 5 + 5 + 15 = 30. R1 and R2 should each have exactly one PICKUP and one DROPOFF.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (5, 0) | 0 | [5, 6] | 3 | (10, 0) | 0 | [0, 40] |
| R2 | 1 | 2 | (5, 0) | 0 | [5, 6] | 4 | (15, 0) | 0 | [0, 40] |
| 0 | 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|---|
| 0 | 0 | 5 | 5 | 10 | 15 | 0 |
| 1 | 5 | 0 | 0 | 5 | 10 | 5 |
| 2 | 5 | 0 | 0 | 5 | 10 | 5 |
| 3 | 10 | 5 | 5 | 0 | 5 | 10 |
| 4 | 15 | 10 | 10 | 5 | 0 | 15 |
| 5 | 0 | 5 | 5 | 10 | 15 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 5. Depot window = [0, 40] min (= [0, 2400] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [5, 6] min. Dropoff windows range from [0, 40] min. Route duration limit T = 40 min (= 2400 s in outputs). |
| Ride rule | Maximum ride time L = 20 min (= 1200 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
two requests with the same origin and destination must not be merged into a single service event — each needs its own PICKUP and DROPOFF
1 vehicle with capacity 2, 2 requests sharing the same pickup node (5,0) and the same dropoff node (10,0). The solver must keep them as two separate requests (two PICKUP rows, two DROPOFF rows) even though they look alike.
Both pickups are at (5,0) with tw=[5,6], and both dropoffs are at (10,0). Route: depot(0)→P1(5)→P2(5)→D1(10)→D2(10)→depot(0). Total distance = 5 + 0 + 5 + 0 + 10 = 20. Peak load = 2. routes.csv must show R1 and R2 as separate rows.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (5, 0) | 0 | [5, 6] | 3 | (10, 0) | 0 | [10, 15] |
| R2 | 1 | 2 | (5, 0) | 0 | [5, 6] | 4 | (10, 0) | 0 | [10, 20] |
| 0 | 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|---|
| 0 | 0 | 5 | 5 | 10 | 10 | 0 |
| 1 | 5 | 0 | 0 | 5 | 5 | 5 |
| 2 | 5 | 0 | 0 | 5 | 5 | 5 |
| 3 | 10 | 5 | 5 | 0 | 0 | 10 |
| 4 | 10 | 5 | 5 | 0 | 0 | 10 |
| 5 | 0 | 5 | 5 | 10 | 10 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 5. Depot window = [0, 40] min (= [0, 2400] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [5, 6] min. Dropoff windows range from [10, 20] min. Route duration limit T = 40 min (= 2400 s in outputs). |
| Ride rule | Maximum ride time L = 20 min (= 1200 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
identical requests with different IDs must not be collapsed into one — the solver must keep R1 and R2 as separate service events
1 vehicle with capacity 2, 2 requests with the exact same pickup, dropoff, and time windows. The solver must treat them as two separate requests — routes.csv must show R1 and R2 each with their own PICKUP and DROPOFF rows.
R1 and R2 are identical: both pick up at (5,0) with tw=[5,6] and both drop off at (10,0) with tw=[10,20]. Route: depot(0)→P_R1(5)→P_R2(5)→D_R1(10)→D_R2(10)→depot(0). Total distance = 5 + 0 + 5 + 0 + 10 = 20. Peak load = 2. routes.csv must list R1 and R2 as separate entries.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (5, 0) | 0 | [5, 6] | 3 | (10, 0) | 0 | [10, 20] |
| R2 | 1 | 2 | (5, 0) | 0 | [5, 6] | 4 | (10, 0) | 0 | [10, 20] |
| 0 | 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|---|
| 0 | 0 | 5 | 5 | 10 | 10 | 0 |
| 1 | 5 | 0 | 0 | 5 | 5 | 5 |
| 2 | 5 | 0 | 0 | 5 | 5 | 5 |
| 3 | 10 | 5 | 5 | 0 | 0 | 10 |
| 4 | 10 | 5 | 5 | 0 | 0 | 10 |
| 5 | 0 | 5 | 5 | 10 | 10 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 5. Depot window = [0, 40] min (= [0, 2400] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [5, 6] min. Dropoff windows range from [10, 20] min. Route duration limit T = 40 min (= 2400 s in outputs). |
| Ride rule | Maximum ride time L = 20 min (= 1200 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
one request on a straight line lets you verify the classic distance-focused evaluation by hand
1 vehicle, 1 request, all nodes on a straight line. The only feasible route is depot → pickup → dropoff → depot. Under the classic distance-focused evaluation, the request is served with total distance 20.
Route: depot(0,0) → pickup(5,0) → dropoff(10,0) → depot(0,0). Total distance = 5 + 5 + 10 = 20. Vehicles used = 1. Rejected = 0.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (5, 0) | 0 | [0, 30] | 2 | (10, 0) | 0 | [0, 30] |
| 0 | 1 | 2 | 3 | |
|---|---|---|---|---|
| 0 | 0 | 5 | 10 | 0 |
| 1 | 5 | 0 | 5 | 5 |
| 2 | 10 | 5 | 0 | 10 |
| 3 | 0 | 5 | 10 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 3. Depot window = [0, 30] min (= [0, 1800] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [0, 30] min. Dropoff windows range from [0, 30] min. Route duration limit T = 30 min (= 1800 s in outputs). |
| Ride rule | Maximum ride time L = 20 min (= 1200 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
the max ride time constraint must block interleaving when it would keep a passenger on board too long
1 vehicle, 2 requests in a 2D plane. Max ride time L = 8 min (= 480 s in outputs). Interleaving pickups and dropoffs would keep each passenger on board longer than that, so the vehicle must serve them one after the other.
L = 8. Direct ride for each request is 5 (within limit). Interleaving P1-P2-D1-D2 would give ride times around 18, far above L = 8. The vehicle must go P1-D1-P2-D2 (or P2-D2-P1-D1) sequentially. Ride time = time from pickup departure to dropoff arrival.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (5, 0) | 0 | [0, 50] | 3 | (10, 0) | 0 | [0, 50] |
| R2 | 1 | 2 | (0, 5) | 0 | [0, 50] | 4 | (0, 10) | 0 | [0, 50] |
| 0 | 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|---|
| 0 | 0 | 5 | 5 | 10 | 10 | 0 |
| 1 | 5 | 0 | 7.07 | 5 | 11.18 | 5 |
| 2 | 5 | 7.07 | 0 | 11.18 | 5 | 5 |
| 3 | 10 | 5 | 11.18 | 0 | 14.14 | 10 |
| 4 | 10 | 11.18 | 5 | 14.14 | 0 | 10 |
| 5 | 0 | 5 | 5 | 10 | 10 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 5. Depot window = [0, 50] min (= [0, 3000] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [0, 50] min. Dropoff windows range from [0, 50] min. Route duration limit T = 50 min (= 3000 s in outputs). |
| Ride rule | Maximum ride time L = 8 min (= 480 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
the solver must use more than one vehicle when pickup windows are too tight for a single vehicle to reach both in time
2 vehicles, 2 requests. Both pickup windows are [5, 6] and each pickup is 5 units from the depot. One vehicle cannot reach the second pickup after serving the first, so both vehicles are needed.
R1 pickup at (5,0) tw=[5,6] min and R2 pickup at (0,5) tw=[5,6] min are each 5 km from the depot, so each first leg takes 5 min (= 300 s). A single vehicle can reach the first pickup at t = 5 min, but cannot then reach the second before t = 6 min. Both vehicles must depart the depot simultaneously.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (5, 0) | 0 | [5, 6] | 3 | (10, 0) | 0 | [0, 30] |
| R2 | 1 | 2 | (0, 5) | 0 | [5, 6] | 4 | (0, 10) | 0 | [0, 30] |
| 0 | 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|---|
| 0 | 0 | 5 | 5 | 10 | 10 | 0 |
| 1 | 5 | 0 | 7.07 | 5 | 11.18 | 5 |
| 2 | 5 | 7.07 | 0 | 11.18 | 5 | 5 |
| 3 | 10 | 5 | 11.18 | 0 | 14.14 | 10 |
| 4 | 10 | 11.18 | 5 | 14.14 | 0 | 10 |
| 5 | 0 | 5 | 5 | 10 | 10 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 5. Depot window = [0, 30] min (= [0, 1800] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [5, 6] min. Dropoff windows range from [0, 30] min. Route duration limit T = 30 min (= 1800 s in outputs). |
| Ride rule | Maximum ride time L = 20 min (= 1200 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
service time should delay departures and affect timing, but must not change the distance objective
1 vehicle, 1 request. Pickup and dropoff each have service time 5 min. The route distance is still 20 km (= 20000 m in outputs) because service time does not add travel, but the vehicle spends extra time at each stop before departing.
Route: depot(0,0)→pickup(5,0)→dropoff(10,0)→depot(0,0). Total distance = 5 + 5 + 10 = 20 km (= 20000 m in outputs), the same as without service time. The vehicle now spends 5 min (= 300 s) at pickup and 5 min (= 300 s) at dropoff before departing, so route time increases while distance stays 20 km.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (5, 0) | 5 | [0, 40] | 2 | (10, 0) | 5 | [0, 40] |
| 0 | 1 | 2 | 3 | |
|---|---|---|---|---|
| 0 | 0 | 5 | 10 | 0 |
| 1 | 5 | 0 | 5 | 5 |
| 2 | 10 | 5 | 0 | 10 |
| 3 | 0 | 5 | 10 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 3. Depot window = [0, 40] min (= [0, 2400] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 5 min. Dropoff service times = 5 min. |
| Time windows | Pickup windows range from [0, 40] min. Dropoff windows range from [0, 40] min. Route duration limit T = 40 min (= 2400 s in outputs). |
| Ride rule | Maximum ride time L = 20 min (= 1200 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
the classic distance-focused run should still report total ride time correctly when two passengers each ride directly
1 vehicle, 2 collinear requests. The distance-optimal route serves each request directly, so the reported total ride time should be 10 min (= 600 s in outputs).
Distance-feasible route: depot→P1→D1→P2→D2→depot. Total distance = 5 + 5 + 5 + 5 + 20 = 40 km (= 40000 m in outputs). Each passenger rides 5 min (= 300 s), so total_ride_s = 600.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (5, 0) | 0 | [0, 40] | 3 | (10, 0) | 0 | [0, 40] |
| R2 | 1 | 2 | (15, 0) | 0 | [0, 40] | 4 | (20, 0) | 0 | [0, 40] |
| 0 | 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|---|
| 0 | 0 | 5 | 15 | 10 | 20 | 0 |
| 1 | 5 | 0 | 10 | 5 | 15 | 5 |
| 2 | 15 | 10 | 0 | 5 | 5 | 15 |
| 3 | 10 | 5 | 5 | 0 | 10 | 10 |
| 4 | 20 | 15 | 5 | 10 | 0 | 20 |
| 5 | 0 | 5 | 15 | 10 | 20 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 5. Depot window = [0, 40] min (= [0, 2400] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [0, 40] min. Dropoff windows range from [0, 40] min. Route duration limit T = 40 min (= 2400 s in outputs). |
| Ride rule | Maximum ride time L = 20 min (= 1200 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
two collinear requests with wide windows should be batched by one vehicle in a single sweep
2 vehicles are available, but 2 collinear requests can be served by one vehicle in a simple left-to-right route with total distance 40.
One vehicle can serve both requests in one sweep: depot(0,0)->P1(5,0)->D1(10,0)->P2(15,0)->D2(20,0)->depot(0,0). Total distance = 5 + 5 + 5 + 5 + 20 = 40. The second vehicle is unnecessary because the same sweep already serves both requests feasibly.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (5, 0) | 0 | [0, 40] | 3 | (10, 0) | 0 | [0, 40] |
| R2 | 1 | 2 | (15, 0) | 0 | [0, 40] | 4 | (20, 0) | 0 | [0, 40] |
| 0 | 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|---|
| 0 | 0 | 5 | 15 | 10 | 20 | 0 |
| 1 | 5 | 0 | 10 | 5 | 15 | 5 |
| 2 | 15 | 10 | 0 | 5 | 5 | 15 |
| 3 | 10 | 5 | 5 | 0 | 10 | 10 |
| 4 | 20 | 15 | 5 | 10 | 0 | 20 |
| 5 | 0 | 5 | 15 | 10 | 20 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 5. Depot window = [0, 40] min (= [0, 2400] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [0, 40] min. Dropoff windows range from [0, 40] min. Route duration limit T = 40 min (= 2400 s in outputs). |
| Ride rule | Maximum ride time L = 20 min (= 1200 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
the solver must handle five collinear requests and still find the one-vehicle distance solution
2 vehicles, 5 requests on a straight line. All can be served by one vehicle going left to right under the classic distance-focused evaluation.
All nodes are on the x-axis. One vehicle sweeps left to right: depot(0)→P1(5)→D1(6)→P2(10)→D2(11)→P3(15)→D3(16)→P4(20)→D4(21)→P5(25)→D5(26)→depot(0). Total distance = 5 + 1 + 4 + 1 + 4 + 1 + 4 + 1 + 4 + 1 + 26 = 52. Vehicles used = 1. Rejected = 0.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (5, 0) | 0 | [0, 60] | 6 | (6, 0) | 0 | [0, 60] |
| R2 | 1 | 2 | (10, 0) | 0 | [0, 60] | 7 | (11, 0) | 0 | [0, 60] |
| R3 | 1 | 3 | (15, 0) | 0 | [0, 60] | 8 | (16, 0) | 0 | [0, 60] |
| R4 | 1 | 4 | (20, 0) | 0 | [0, 60] | 9 | (21, 0) | 0 | [0, 60] |
| R5 | 1 | 5 | (25, 0) | 0 | [0, 60] | 10 | (26, 0) | 0 | [0, 60] |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 11. Depot window = [0, 60] min (= [0, 3600] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [0, 60] min. Dropoff windows range from [0, 60] min. Route duration limit T = 60 min (= 3600 s in outputs). |
| Ride rule | Maximum ride time L = 20 min (= 1200 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
same pickup node and time must force a split across two vehicles when the combined load exceeds one vehicle's capacity
2 vehicles with capacity 1, 2 requests at the same pickup node (5,0) in the same time window [5, 6]. Capacity 1 means one vehicle cannot carry both, and the window is too short to return for the second. Two vehicles needed.
Both pickups are at x=5 with tw=[5,6], but capacity is 1. Vehicle A: depot(0)→P1(5)→D1(10)→depot(0) = 5 + 5 + 10 = 20. Vehicle B: depot(0)→P2(5)→D2(15)→depot(0) = 5 + 10 + 15 = 30. Total distance = 50. Vehicles used = 2. Rejected = 0.
| Passengers | Pickup node | Pickup coords | Pickup service | Pickup window | Dropoff node | Dropoff coords | Dropoff service | Dropoff window | |
|---|---|---|---|---|---|---|---|---|---|
| R1 | 1 | 1 | (5, 0) | 0 | [5, 6] | 3 | (10, 0) | 0 | [0, 40] |
| R2 | 1 | 2 | (5, 0) | 0 | [5, 6] | 4 | (15, 0) | 0 | [0, 40] |
| 0 | 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|---|
| 0 | 0 | 5 | 5 | 10 | 15 | 0 |
| 1 | 5 | 0 | 0 | 5 | 10 | 5 |
| 2 | 5 | 0 | 0 | 5 | 10 | 5 |
| 3 | 10 | 5 | 5 | 0 | 5 | 10 |
| 4 | 15 | 10 | 10 | 5 | 0 | 15 |
| 5 | 0 | 5 | 5 | 10 | 15 | 0 |
| Units | DARP benchmark inputs use minutes for time values and Euclidean coordinates treated as kilometers. With unit speed, each direct distance in km equals the direct travel time in minutes. routes.csv and results.csv should report seconds and meters. |
|---|---|
| Depot | Single depot at (0, 0). Vehicles depart from depot node 0 and return to the same depot location; the DARP instance file repeats it as return node 5. Depot window = [0, 40] min (= [0, 2400] s in outputs). |
| Service | Depot service times = 0 min. Pickup service times = 0 min. Dropoff service times = 0 min. |
| Time windows | Pickup windows range from [5, 6] min. Dropoff windows range from [0, 40] min. Route duration limit T = 40 min (= 2400 s in outputs). |
| Ride rule | Maximum ride time L = 20 min (= 1200 s in outputs). |
| Rejections | Requests may remain unserved when no feasible route exists; count them with n_rejected and apply the objective penalties listed below. |
Check plain feasibility with objective=unserved, then verify that unserved;vehicles breaks ties toward the smaller fleet usage.
Two easy requests can both be served without rejection; a lexicographic secondary objective on vehicles should prefer one vessel once feasibility is tied.
Both requests are feasible. The unserved run only needs n_rejected = 0. The vehicles run should keep both requests served while reducing vehicles_used to 1.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 2 | 1 | [0, 2000] | 3 | [0, 2000] |
| R2 | 1 | 2 | [0, 2000] | 4 | [0, 2000] |
| 0 | 1 | 2 | 3 | 4 | |
|---|---|---|---|---|---|
| 0 | - | 100 s / 1 m | 200 s / 2 m | 400 s / 4 m | 500 s / 5 m |
| 1 | 100 s / 1 m | - | 100 s / 1 m | 300 s / 3 m | 400 s / 4 m |
| 2 | 200 s / 2 m | 100 s / 1 m | - | 200 s / 2 m | 300 s / 3 m |
| 3 | 400 s / 4 m | 300 s / 3 m | 200 s / 2 m | - | 100 s / 1 m |
| 4 | 500 s / 5 m | 400 s / 4 m | 300 s / 3 m | 100 s / 1 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 2000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s; node 3 = service 0s, dwell 0s; node 4 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
the vessel shift end must force rejection when a request cannot be completed before the shift is over
1 vessel, 2 requests. The vessel shift ends at 1000 s. R1 fits (pickup at [0, 300], whole route done by ~600 s). R2 starts at 1000 s, so it cannot be completed before the shift ends.
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 1 | 1 | [0, 300] | 2 | [200, 600] |
| R2 | 1 | 3 | [1000, 1200] | 1 | [1100, 1400] |
| 0 | 1 | 2 | 3 | |
|---|---|---|---|---|
| 0 | - | 200 s / 1 m | 200 s / 1 m | 200 s / 1 m |
| 1 | 200 s / 1 m | - | 200 s / 1 m | 200 s / 1 m |
| 2 | 200 s / 1 m | 200 s / 1 m | - | 200 s / 1 m |
| 3 | 200 s / 1 m | 200 s / 1 m | 200 s / 1 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 1000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s; node 3 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
a request requiring more passengers than the vessel capacity must always be rejected
1 vessel with capacity 4, 2 requests. R1 needs 2 seats (fits). R2 needs 5 seats (exceeds capacity). R2 must be rejected regardless of routing.
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 2 | 1 | [0, 2000] | 2 | [0, 2000] |
| R2 | 5 | 1 | [0, 2000] | 2 | [0, 2000] |
| 0 | 1 | 2 | |
|---|---|---|---|
| 0 | - | 200 s / 1 m | 200 s / 1 m |
| 1 | 200 s / 1 m | - | 200 s / 1 m |
| 2 | 200 s / 1 m | 200 s / 1 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 2000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
the max ride-time ratio constraint must block the cheaper route when it stretches a passenger's ride beyond the allowed ratio
1 vessel, 2 requests. The cheaper interleaved route (distance 10 m) keeps each passenger on board for 400 s, but their direct rides are 200 s. With max_ride_ratio = 1.5, the allowed ride time is 300 s. The solver must use the longer sequential route (14 m) instead.
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 1 | 1 | [0, 2000] | 3 | [0, 2000] |
| R2 | 1 | 2 | [0, 2000] | 4 | [0, 2000] |
| 0 | 1 | 2 | 3 | 4 | |
|---|---|---|---|---|---|
| 0 | - | 100 s / 1 m | 300 s / 3 m | 400 s / 4 m | 600 s / 6 m |
| 1 | 100 s / 1 m | - | 200 s / 1 m | 200 s / 3 m | 400 s / 5 m |
| 2 | 300 s / 3 m | 200 s / 1 m | - | 200 s / 1 m | 200 s / 3 m |
| 3 | 400 s / 4 m | 200 s / 3 m | 200 s / 1 m | - | 200 s / 1 m |
| 4 | 600 s / 6 m | 400 s / 5 m | 200 s / 3 m | 200 s / 1 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 2000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s; node 3 = service 0s, dwell 0s; node 4 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
overlapping short pickup windows must force the solver to use both vessels when one cannot reach both in time
2 vessels, 2 requests. Both pickups open in the window [600, 800] s. Each pickup is 400 s from the depot. One vessel can reach one pickup by 600 s, but cannot serve the first request and reach the second before 800 s.
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 1 | 1 | [600, 800] | 2 | [0, 2000] |
| R2 | 1 | 3 | [600, 800] | 4 | [0, 2000] |
| 0 | 1 | 2 | 3 | 4 | |
|---|---|---|---|---|---|
| 0 | - | 400 s / 2 m | 600 s / 3 m | 400 s / 2 m | 600 s / 3 m |
| 1 | 400 s / 2 m | - | 400 s / 2 m | 1000 s / 5 m | 1200 s / 6 m |
| 2 | 600 s / 3 m | 400 s / 2 m | - | 1200 s / 6 m | 1000 s / 5 m |
| 3 | 400 s / 2 m | 1000 s / 5 m | 1200 s / 6 m | - | 400 s / 2 m |
| 4 | 600 s / 3 m | 1200 s / 6 m | 1000 s / 5 m | 400 s / 2 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 2000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s; node 3 = service 0s, dwell 0s; node 4 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
distance and drive_time objectives must produce different solutions when the shortest-distance route is not the fastest
1 vessel, 2 requests. The distance-best route (8 m) has high drive time. The drive_time-best route (1600 s) has longer distance (11 m). Tests that switching the objective actually changes the solution.
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 1 | 1 | [0, 2000] | 2 | [0, 2000] |
| R2 | 1 | 3 | [0, 2000] | 4 | [0, 2000] |
| 0 | 1 | 2 | 3 | 4 | |
|---|---|---|---|---|---|
| 0 | - | 200 s / 1 m | 300 s / 4 m | 200 s / 1 m | 500 s / 2 m |
| 1 | 200 s / 1 m | - | 100 s / 5 m | 600 s / 2 m | 800 s / 3 m |
| 2 | 300 s / 4 m | 100 s / 5 m | - | 600 s / 2 m | 200 s / 1 m |
| 3 | 200 s / 1 m | 600 s / 2 m | 600 s / 2 m | - | 400 s / 1 m |
| 4 | 500 s / 2 m | 800 s / 3 m | 200 s / 1 m | 400 s / 1 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 2000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s; node 3 = service 0s, dwell 0s; node 4 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
the solver must reject every request when no pickup can be reached before its time window closes
1 vessel, 2 requests. Each pickup is 400 s from the depot, but the latest pickup time is 200 s. The vessel cannot reach either pickup in time. Both must be rejected.
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 1 | 1 | [0, 200] | 3 | [0, 600] |
| R2 | 1 | 2 | [0, 200] | 3 | [0, 600] |
| 0 | 1 | 2 | 3 | |
|---|---|---|---|---|
| 0 | - | 400 s / 2 m | 400 s / 2 m | 600 s / 3 m |
| 1 | 400 s / 2 m | - | 400 s / 2 m | 200 s / 2 m |
| 2 | 400 s / 2 m | 400 s / 2 m | - | 200 s / 2 m |
| 3 | 600 s / 3 m | 200 s / 2 m | 200 s / 2 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 2000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s; node 3 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
the solver must handle time windows where the vessel arrives right at the earliest boundary without violating them
1 vessel, 1 request. The pickup window [200, 300] s barely fits the 200 s trip from the depot. The vessel arrives right at the window boundary.
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 1 | 1 | [200, 300] | 2 | [400, 500] |
| 0 | 1 | 2 | |
|---|---|---|---|
| 0 | - | 200 s / 1 m | 400 s / 2 m |
| 1 | 200 s / 1 m | - | 200 s / 1 m |
| 2 | 400 s / 2 m | 200 s / 1 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 1000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
the ride-time ratio constraint must block the cheaper route when interleaving stretches rides beyond the allowed ratio
1 vessel, 2 requests. The cheaper interleaved route (10 m) stretches each 200 s direct ride to 400 s. With max_ride_ratio, the solver must use the sequential route (12 m).
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 1 | 1 | [0, 2000] | 3 | [0, 2000] |
| R2 | 1 | 2 | [0, 2000] | 4 | [0, 2000] |
| 0 | 1 | 2 | 3 | 4 | |
|---|---|---|---|---|---|
| 0 | - | 100 s / 1 m | 200 s / 2 m | 300 s / 4 m | 400 s / 6 m |
| 1 | 100 s / 1 m | - | 200 s / 1 m | 200 s / 2 m | 300 s / 4 m |
| 2 | 200 s / 2 m | 200 s / 1 m | - | 200 s / 1 m | 200 s / 2 m |
| 3 | 300 s / 4 m | 200 s / 2 m | 200 s / 1 m | - | 200 s / 1 m |
| 4 | 400 s / 6 m | 300 s / 4 m | 200 s / 2 m | 200 s / 1 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 2000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s; node 3 = service 0s, dwell 0s; node 4 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
two requests at the same pickup dock with different destinations should be served by one vessel when the combined load fits
1 vessel with capacity 4, 2 requests (2 passengers each) at the same pickup dock in the same time window. Different dropoff docks. The vessel picks up both before leaving.
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 2 | 1 | [100, 150] | 2 | [0, 1000] |
| R2 | 2 | 1 | [100, 150] | 3 | [0, 1000] |
| 0 | 1 | 2 | 3 | |
|---|---|---|---|---|
| 0 | - | 100 s / 1 m | 200 s / 2 m | 200 s / 2 m |
| 1 | 100 s / 1 m | - | 100 s / 1 m | 100 s / 1 m |
| 2 | 200 s / 2 m | 100 s / 1 m | - | 100 s / 1 m |
| 3 | 200 s / 2 m | 100 s / 1 m | 100 s / 1 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 1000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s; node 3 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
two requests with the same origin and destination must not be merged — each needs its own PICKUP and DROPOFF rows
1 vessel with capacity 4, 2 requests (2 passengers each) sharing the same pickup and dropoff docks. The solver must keep them as separate requests with separate PICKUP and DROPOFF rows in routes.csv.
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 2 | 1 | [100, 150] | 2 | [200, 400] |
| R2 | 2 | 1 | [100, 150] | 2 | [200, 500] |
| 0 | 1 | 2 | |
|---|---|---|---|
| 0 | - | 100 s / 1 m | 200 s / 2 m |
| 1 | 100 s / 1 m | - | 100 s / 1 m |
| 2 | 200 s / 2 m | 100 s / 1 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 1000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
same pickup dock and time must force a split across two vessels when the combined passenger count exceeds vessel capacity
2 vessels with capacity 3, 2 requests (2 passengers each) at the same pickup dock. Combined load = 4 > capacity 3. The requests must be split across two vessels.
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 2 | 1 | [100, 150] | 2 | [0, 1000] |
| R2 | 2 | 1 | [100, 150] | 3 | [0, 1000] |
| 0 | 1 | 2 | 3 | |
|---|---|---|---|---|
| 0 | - | 100 s / 1 m | 200 s / 2 m | 200 s / 2 m |
| 1 | 100 s / 1 m | - | 100 s / 1 m | 100 s / 1 m |
| 2 | 200 s / 2 m | 100 s / 1 m | - | 100 s / 1 m |
| 3 | 200 s / 2 m | 100 s / 1 m | 100 s / 1 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 1000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s; node 3 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
same pickup dock should still split across vessels when a shared route would exceed the vessel shift length
2 vessels, 2 requests at the same pickup dock. Capacity allows sharing, but the combined route takes 500 s while the vessel shift ends at 400 s. The requests must be split across two vessels.
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 2 | 1 | [100, 150] | 2 | [0, 1000] |
| R2 | 2 | 1 | [100, 150] | 3 | [0, 1000] |
| 0 | 1 | 2 | 3 | |
|---|---|---|---|---|
| 0 | - | 100 s / 1 m | 200 s / 2 m | 200 s / 2 m |
| 1 | 100 s / 1 m | - | 100 s / 1 m | 100 s / 1 m |
| 2 | 200 s / 2 m | 100 s / 1 m | - | 100 s / 1 m |
| 3 | 200 s / 2 m | 100 s / 1 m | 100 s / 1 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 400]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s; node 3 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
distance and wait (= pickup delay) objectives must produce different solutions when the shorter route delays a later pickup
1 vessel, 2 requests. The shorter-distance route serves R1 first, then reaches R2 at t = 1200 s although R2's earliest pickup is 300 s, so total_wait_s = 900 s. The wait-minimizing route serves R2 first, reaches both pickups at their earliest times, and travels farther. This checks that switching from distance to wait changes the chosen route.
Distance run: total_distance_m = 12 and total_wait_s = 900 because serving R1 first postpones R2 until t = 1200 s even though R2 opens at t = 300 s. Wait run: total_distance_m = 13 and total_wait_s = 0 because it serves R2 first at 300 s and R1 next at 600 s.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 1 | 1 | [600, 1600] | 3 | [0, 2000] |
| R2 | 1 | 2 | [300, 1600] | 4 | [0, 2000] |
| 0 | 1 | 2 | 3 | 4 | |
|---|---|---|---|---|---|
| 0 | - | 100 s / 1 m | 300 s / 3 m | 200 s / 2 m | 600 s / 6 m |
| 1 | 100 s / 1 m | - | 400 s / 4 m | 100 s / 1 m | 500 s / 5 m |
| 2 | 300 s / 3 m | 400 s / 4 m | - | 300 s / 3 m | 100 s / 1 m |
| 3 | 600 s / 6 m | 100 s / 1 m | 500 s / 5 m | - | 400 s / 4 m |
| 4 | 400 s / 4 m | 200 s / 2 m | 100 s / 1 m | 400 s / 4 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 2000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s; node 3 = service 0s, dwell 0s; node 4 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
Check weighted watertaxi objectives separately from the main suite by deriving KPI ranges from single-objective runs, then verifying the weighted run against the normalized winner.
All requests remain feasible, but the distance-optimal route and the wait-optimal route disagree on total pickup delay. The weighted run should first normalize both KPI components before combining them.
Distance run: total_distance_m = 12 and total_wait_s = 900. Wait run: total_distance_m = 13 and total_wait_s = 0. With weights distance = 0.7 and wait = 0.3, normalized weighting should match the distance-optimal candidate.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 1 | 1 | [600, 1600] | 3 | [0, 2000] |
| R2 | 1 | 2 | [300, 1600] | 4 | [0, 2000] |
| 0 | 1 | 2 | 3 | 4 | |
|---|---|---|---|---|---|
| 0 | - | 100 s / 1 m | 300 s / 3 m | 200 s / 2 m | 600 s / 6 m |
| 1 | 100 s / 1 m | - | 400 s / 4 m | 100 s / 1 m | 500 s / 5 m |
| 2 | 300 s / 3 m | 400 s / 4 m | - | 300 s / 3 m | 100 s / 1 m |
| 3 | 600 s / 6 m | 100 s / 1 m | 500 s / 5 m | - | 400 s / 4 m |
| 4 | 400 s / 4 m | 200 s / 2 m | 100 s / 1 m | 400 s / 4 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 2000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s; node 3 = service 0s, dwell 0s; node 4 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
service time should delay departures and affect timing, but must not change the distance objective
1 vessel, 1 request. Pickup has 200 s service time, dropoff has 100 s. Distance is still 3+4+5 = 12 m (service time does not add distance). Tests that service_time_s from network.json is applied correctly.
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 1 | 1 | [0, 2000] | 2 | [0, 2000] |
| 0 | 1 | 2 | |
|---|---|---|---|
| 0 | - | 300 s / 3 m | 500 s / 5 m |
| 1 | 300 s / 3 m | - | 400 s / 4 m |
| 2 | 500 s / 5 m | 400 s / 4 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 2000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 200s, dwell 0s; node 2 = service 100s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
dwell time should affect timing without changing distance — the solver must read dwell_time_s from network.json
1 vessel, 1 request. docks have dwell_time_s (200 s at pickup, 100 s at dropoff). Distance is still 1+1+1 = 3 m. Dwell time adds to the stop duration but does not affect the distance objective.
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 1 | 1 | [0, 2000] | 2 | [0, 2000] |
| 0 | 1 | 2 | |
|---|---|---|---|
| 0 | - | 200 s / 1 m | 200 s / 1 m |
| 1 | 200 s / 1 m | - | 200 s / 1 m |
| 2 | 200 s / 1 m | 200 s / 1 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 2000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 100s, dwell 200s; node 2 = service 100s, dwell 100s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
deadhead (empty) travel must be correctly measured as the distance traveled with zero passengers on board
1 vessel, 1 request. The empty legs (no passengers) are depot→pickup (3 m) and dropoff→depot (5 m). Total deadhead distance = 8 m. Total route distance = 3+4+5 = 12 m.
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 1 | 1 | [0, 2000] | 2 | [0, 2000] |
| 0 | 1 | 2 | |
|---|---|---|---|
| 0 | - | 300 s / 3 m | 500 s / 5 m |
| 1 | 300 s / 3 m | - | 400 s / 4 m |
| 2 | 500 s / 5 m | 400 s / 4 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 2000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
the solver must read each directed edge separately — travel time and distance can differ by direction
1 vessel, 1 request. Travel times differ by direction (e.g., 0→1 takes 200 s but 1→0 takes 300 s). Distances are also asymmetric. Tests that the solver reads each directed edge separately.
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 1 | 1 | [0, 2000] | 2 | [0, 2000] |
| 0 | 1 | 2 | |
|---|---|---|---|
| 0 | - | 200 s / 2 m | 300 s / 4 m |
| 1 | 300 s / 2 m | - | 200 s / 3 m |
| 2 | 500 s / 4 m | 400 s / 3 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 2000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
the solver must use distance_m and travel_time_s from the directed edges in network.json instead of recomputing travel from node coordinates
1 vessel, 1 request. The node coordinates are real lat/lon points, but the toy network edges define short values: depot to pickup = 10 m, pickup to dropoff = 13 m, dropoff to depot = 10 m. The expected route total is therefore 33 m from edge data, not from any geometric formula.
Derive the expected output from the stated case data and objective priorities.
| Passengers | Pickup node | Pickup window | Dropoff node | Dropoff window | |
|---|---|---|---|---|---|
| R1 | 1 | 1 | [0, 2000] | 2 | [0, 2000] |
| 0 | 1 | 2 | |
|---|---|---|---|
| 0 | - | 200 s / 10 m | 200 s / 10 m |
| 1 | 200 s / 10 m | - | 300 s / 13 m |
| 2 | 200 s / 10 m | 300 s / 13 m | - |
| Units | Travel time is measured in seconds and distance is measured in meters. Both are read directly from the directed edges in network.json. |
|---|---|
| Depot | Each vessel uses a single depot: it departs from and returns to its listed origin/depot node. Shift window(s) = [0, 2000]. No extra depot opening rule is modeled beyond those shift limits. |
| Service | Node service/dwell times are node 0 = service 0s, dwell 0s; node 1 = service 0s, dwell 0s; node 2 = service 0s, dwell 0s. |
| Time windows | Pickup and dropoff windows are listed in the request table. A vessel may serve a request only if those windows and its shift window all remain feasible. |
| Ride rule | Maximum ride time = 2 x the direct travel time between the request pickup and dropoff. |
| Rejections | Unserved requests are allowed and counted with n_rejected. The objective specs below determine whether a case checks pure feasibility or uses a secondary KPI to break ties among fully served solutions. |
V1: capacity 12, depot node 0, shift [0, 2000]. 1 request. Default run | unserved