Conceptual model

Conceptual model — synthetic mine throughput

System boundary

Included. Truck dispatch from the parking node (PARK), travel along a directed road graph, queueing for capacity-constrained road segments, queueing and service at ore loaders (LOAD_N, LOAD_S), travel to the primary crusher (CRUSH), queueing and service at the crusher, and the empty return to a loader. The simulation clock advances in minutes over a fixed 8-hour shift.

Excluded. Truck breakdowns, fuelling, driver shift changes, tyre changes, operator skill differences, weather, blast cycles, ore grade variation, and any explicit waste haulage. The MAINT and WASTE nodes appear in the topology but are unused under the production-objective dispatching policy. Energy consumption, emissions, and mine planning over multi-shift horizons are out of scope.

Entities

• Trucks — homogeneous CAT-class haul trucks (100 t payload, empty speed factor 1.00, loaded factor 0.85). Fleet size is set per scenario. Each truck is a SimPy process that loops loader → crusher → loader.

Resources

• Loaders — L_N at LOAD_N (mean 6.5 min, SD 1.2 min, capacity 1) and L_S at LOAD_S (mean 4.5 min, SD 1.0 min, capacity 1). Modelled as simpy.Resource.

• Crusher — D_CRUSH at CRUSH (mean 3.5 min, SD 0.8 min, capacity 1). Modelled as simpy.Resource.

• Capacity-constrained lanes — every directed edge with capacity < 999 in the edges file. Edges that share a lane_id (the prefix before the first underscore in the edge_id, e.g. E03_UP and E03_DOWN both map to lane E03) are merged into a single physical-lane SimPy resource because the data flags them as the same physical constraint. The constrained lanes that matter in this topology are:

  • E03 — narrow main ramp (J2 ↔ J3)
  • E05 — single-lane crusher approach (J4 ↔ CRUSH)
  • E07 — single-lane North Pit face access (J5 ↔ LOAD_N)
  • E09 — single-lane South Pit face access (J6 ↔ LOAD_S)

  Open haul roads (capacity = 999) are not modelled as resources; multiple trucks may traverse them concurrently.

Events

Events emitted to the event log per truck cycle:

State variables

• Per truck: current node, loaded/empty flag, cumulative cycles, cumulative tonnes delivered, cumulative busy time, time queued at loaders, crusher and lanes, and full cycle-time history.
• Per resource (loader/crusher/lane): cumulative busy time, queue wait samples, request count.
• Per scenario: replication results aggregated to means and 95% confidence intervals.

Routing and dispatching

• Routing uses NetworkX’s shortest_path over the directed graph with the edge weight set to the average of empty and loaded nominal travel times. Closed edges are dropped from the graph before routing, so unreachable routes raise a clear RuntimeError("No path from … to …") rather than silently producing bad results.
• Dispatching policy: nearest_available_loader with tie-breaker shortest_expected_cycle_time. The expected cycle time used for tie-breaking is travel-to-loader + load + travel-to-crusher + dump + an estimated queue penalty proportional to the loader’s current count plus queue length.

Stochasticity

• Loading and dumping times: normal distributions truncated below at max(0.05 min, mean − 3·SD).
• Travel times: each segment’s nominal distance/(speed × loaded_factor) is multiplied by an independent lognormal noise factor with the scenario’s travel_time_noise_cv (default CV = 0.10).
• Per replication, all stochastic draws are produced from a single numpy.random.default_rng(base_seed + replication_index) so results are reproducible.

Assumptions

Derived from the data.

• Edge capacity = 999 is treated as effectively unbounded.
• Edge capacity = 1 defines a single-lane segment that can hold one truck.
• Edges with the same prefix before the first underscore share one physical lane (the metadata on E03_UP / E03_DOWN calls this out explicitly; the same logic is applied to the other approach roads).
• Loading/dumping service distributions are normal with truncation at the lower tail.
• Truck speeds are scaled by the truck’s empty/loaded factor relative to the edge max_speed_kph.

Introduced by the modeller.

• Trucks always carry 100 t per cycle (no partial bucket counts).
• Loader and crusher availability are 1.0 (no downtime within the shift).
• Trucks dispatch immediately at t = 0 and continue cycling until the shift clock expires; partially-completed cycles do not count toward throughput.
• The shortest-time path is recomputed once per scenario (not dynamically per request) given the open graph; congestion does not influence routing.
• The dispatching tie-break uses a simple analytic estimate of queue penalty; more sophisticated dispatching (e.g. a centralised optimiser) is out of scope.

Performance measures

• total_tonnes_delivered — sum of payload_tonnes over completed dump_end events at CRUSH.
• tonnes_per_hour — total_tonnes_delivered divided by shift hours.
• average_truck_cycle_time_min — mean of completed cycle durations.
• average_truck_utilisation — fraction of shift time each truck is in any active activity (loading, dumping, travelling).
• crusher_utilisation — fraction of shift time the crusher is busy.
• loader_utilisation[<id>] — fraction of shift time each loader is busy.
• lane_utilisation[<id>] — fraction of shift time × capacity each constrained lane is busy.
• average_loader_queue_time_min, average_crusher_queue_time_min — average queue wait at loaders and crusher.
• top_bottlenecks — resources sorted by mean utilisation.
• All scenario-level metrics are reported as the mean and 95% confidence interval across 30 replications.

Limitations

• No mechanical breakdowns or unscheduled maintenance — real fleets will lose perhaps 10-25 % of theoretical availability.
• No explicit congestion model on open haul roads — only single-lane segments queue. In a real mine wide haul roads still slow down with traffic.
• Routing is static given the open graph; trucks do not re-route when they observe a queue ahead.
• Trucks do not stop for fuelling, refuelling, or operator shift changes.
• Crusher feed bin behaviour, surge piles and conveyor downstream of the crusher are abstracted away — the crusher service time is the entire dump cycle.
• The fleet is homogeneous; in practice trucks have different ages, payloads and speed factors.

README

Synthetic mine throughput simulation

Discrete-event simulation of an 8-hour ore haulage shift, built with SimPy. Reads the provided topology and scenario data, runs 30 replications per scenario with controlled random seeds, and produces machine-readable outputs plus answers to the operational decision questions.

1. Install

python3 -m pip install -r requirements.txt

Tested with Python 3.11 / 3.13. Dependencies: simpy, numpy, pandas, scipy, networkx, pyyaml, matplotlib.

2. Run

From the submission directory:

python3 run.py                    # the six required scenarios
python3 run.py --extras           # also runs the optional trucks_10 scenario
python3 run.py --scenarios baseline   # any subset by name
python3 plot_topology.py          # regenerate topology.png

Outputs land in the submission directory:

Reproducing a single scenario after the fact:

python3 -m src.experiment           # not a CLI; use run.py instead
python3 run.py --scenarios baseline trucks_12

Random seeds: seed = base_random_seed + replication_index where base_random_seed = 12345 is set in data/scenarios/baseline.yaml. All 30 replications are reproducible from those seeds.

3. Conceptual model

Full description in conceptual_model.md. Key elements:

• Entities: trucks (homogeneous, 100 t payload).
• Resources: 2 loaders (L_N, L_S), 1 crusher (D_CRUSH), and a SimPy Resource for every capacity-constrained lane in the road graph.
• Routing: NetworkX shortest-time path on the directed graph; closed edges are dropped before routing so blocked routes fail loudly.
• Dispatching: nearest_available_loader with shortest expected cycle time as tie-breaker.

4. Main assumptions

• Loading and dumping times are normal-truncated using means/SDs from the data; travel times are nominal distance/speed multiplied by a lognormal noise factor (CV = 0.10).
• Edges with capacity < 999 model single-lane segments. Edges sharing a lane prefix (e.g. E03_UP and E03_DOWN) share one physical-lane resource.
• Trucks dispatch immediately at t = 0 from PARK, do not refuel, and do not break down.
• Throughput is counted only on completed dump_end events at CRUSH within the shift.
• See summary.json → key_assumptions and model_limitations for the full list.

5. Routing and dispatching

The graph is built once per scenario from nodes.csv and edges.csv after applying scenario edge/node overrides. Edge weights are the mean of the empty and loaded nominal travel times. Closed edges are removed.

For each cycle, the truck:

1. Picks the loader whose expected cycle time (travel + load + travel-to- crusher + dump + queue penalty) is shortest. Idle loaders are preferred over busy ones.
2. Walks the shortest-time path edge by edge. On a constrained lane it requests the corresponding simpy.Resource and holds it for the travel time before releasing.
3. Loads, hauls, queues, dumps, then loops.

If data/scenarios/<scenario>.yaml closes an edge that breaks all paths to the target, the simulation raises RuntimeError("No path from X to Y in current topology") rather than silently completing.

6. Key results

Mean values across 30 replications (95 % CI in brackets where shown).

7. Operational decision questions

Q1. Expected baseline throughput

~12 050 tonnes per shift (≈1 507 t/h), 95 % CI [11 999, 12 107]. This is the mean across 30 independent replications with the 8-truck fleet.

Q2. Likely bottlenecks

The crusher (88 % utilisation) is the dominant bottleneck under the baseline. The single-lane crusher approach (E05, 74 % utilisation) and the South Pit face access (E09, 74 %) are the next constraints. Loader L_S runs at 77 % because the dispatcher prefers it (shorter cycle). At trucks_12, crusher utilisation hits 93 % and E09 rises to 82 % — the crusher is the wall.

Q3. Does adding trucks help?

Diminishing returns. Going from 4 → 8 trucks adds ~4 547 t/shift (+60 %). Going 8 → 10 adds only ~733 t (+6 %), and 10 → 12 adds another ~63 t (<0.5 %). The system is essentially saturated by ~10 trucks; beyond that the extra trucks queue at the crusher and the loaders.

Q4. Would improving the narrow ramp help?

No — within rounding of zero (12 003 vs 12 053 t/shift, well inside the CI overlap). The ramp E03 is only used for the initial dispatch from PARK to the South Pit; the steady-state cycle goes pit → J3 → J4 → CRUSH and back, never re-traversing the ramp. The bypass via J7/J8 is also faster than the ramp for North Pit dispatch, so empirically the ramp is not on the hot path. Capital spent on the ramp upgrade in this configuration would not materially improve throughput.

Q5. Sensitivity to crusher service time

Doubling the mean dump time from 3.5 to 7.0 min (the crusher_slowdown scenario) reduces throughput from ~12 053 to ~6 483 t/shift, a drop of ~46 %. Crusher utilisation actually rises (94 %), confirming it is the binding constraint. Throughput is therefore highly sensitive to crusher service time — roughly inversely proportional, as expected for a saturated single-server bottleneck.

Q6. Operational impact of losing the main ramp

Closing E03_UP/E03_DOWN reduces baseline throughput by only ~100 t/shift (0.8 %), within the 95 % CI of baseline. The bypass J2 → J7 → J8 → J4 plus the lateral connectors J7 ↔ J5 and J8 ↔ J6 provide a workable alternative for initial dispatch to either pit. Operators could lose the main ramp for the shift with negligible production impact.

Optional extra scenario (proposed)

trucks_10: an interpolated fleet point between 8 and 12 trucks. It confirms that saturation begins between 8 and 10 trucks; adding the last two trucks beyond 10 yields essentially zero additional throughput.

8. Likely bottlenecks (top 3 by utilisation)

9. Limitations

See summary.json → model_limitations for the canonical list. The most material ones for interpreting these results:

• No truck breakdowns or maintenance — real-world availability will be lower, so the absolute tonnage figures should be treated as theoretical upper bounds for the modelled configuration.
• Routing is static; in reality dispatchers will sometimes re-route trucks to balance queues. The model therefore likely under-states the benefit of better dispatching and over-states the impact of static bottlenecks.
• The crusher is modelled as a single-server resource; in practice the feed bin and downstream conveyor introduce additional buffering.
• Open haul roads have no congestion model; on a real site, a 12-truck fleet would slow down somewhat even on wide haul roads.

10. Suggested improvements / further scenarios

• Reduce crusher service time (e.g. through a feed-bin upgrade or chute redesign): the model says this is the only intervention that materially raises throughput.
• Crusher availability scenarios: model crusher MTBF/MTTR. With the crusher already saturated, even short downtimes will translate directly into lost tonnes.
• Loader re-balancing: shifting some demand from L_S to L_N (or upgrading L_S to a faster bucket) would reduce the secondary bottleneck.
• Buffer / stockpile: add a surge stockpile between trucks and crusher to decouple haulage variability from the crusher.
• Mixed fleet: introduce a faster, smaller truck class to fill the small operational gaps.

Reviewer form

Reviewer Form: Synthetic Mine Throughput

Submission: 2026-04-25__001_synthetic_mine_throughput__claude-code__claude-opus-4-7__max-thinking Decoded: Date 2026-04-25 | Benchmark 001 mine throughput | Harness Claude Code | Model Claude Opus 4.7 (max thinking) Reviewer: Independent human reviewer (opus subagent) Date: 2026-04-27

Automated report

• Report file: results/evaluation_report.json
• Automated checks: 57/57 passed (100%)
• Behavioural sanity checks: all six passed (fleet ordering, ramp upgrade, crusher slowdown, ramp closed, saturation)
• Required scenarios present: yes (six required + extra trucks_10)
• Python LOC: 1,360 total / 1,128 code, 7 files
• Runtime, return code, token usage: not captured by harness (null); submission.yaml reports time_s: 699 and tokens: 116900

Human quality score

Strengths

1. Genuine, well-engineered SimPy DES with correct queueing, lane resources, truncated/lognormal stochastics, seed control, and a clean module separation that any reviewer can follow.
2. Mechanistic interpretation of results — the explanation of why the ramp upgrade is a null result (steady-state cycles bypass E03) demonstrates the agent actually understood the topology rather than parroting numbers.
3. Strong assumption hygiene: conceptual_model.md explicitly separates data-derived from modeller-introduced assumptions, and the limitations list is honest (no breakdowns, no congestion on open roads, no dynamic rerouting).

Concerns / gaps

1. Lane-grouping heuristic is asserted, not validated — only E03_UP/DOWN has explicit metadata calling it out as one physical lane; applying the same prefix rule to E05/E07/E09 is reasonable but unverified, and tightens the crusher-side bottleneck (E05 at 74% utilisation). A sensitivity check would have closed this gap.
2. Initial-dispatch artefact: at t=0 all trucks route to LOAD_S simultaneously; this transient is included in the 8-hour aggregate without warm-up exclusion. Material? Probably small at 8 trucks but unquantified.
3. Dead code and minor polish: _record_resource_busy is unused; comment density is low; no unit tests despite the modular structure inviting them.

Failure modes observed

None of the standard failure modes apply. Behavioural checks all pass; conceptual model is present; SimPy is used genuinely; CIs and seeds are present; event log is rich; decision questions are answered.

Final judgement

Strong submission. Would I trust this as a first-pass decision-support artefact? Yes, with the caveat that the lane-grouping assumption should be confirmed with the data owner before acting on the “ramp upgrade is not worth it” recommendation, and the absolute tonnage figures be treated as a theoretical upper bound (as the README itself flags). Final score 92/100.