Conceptual model

Conceptual Model Design

System Boundary

The simulation models the active haulage operations over an 8-hour shift. It includes:

• Truck movements between loaders, the primary crusher, and parking.
• Queueing at loaders and the primary crusher.
• Constrained road segments (e.g., single-lane approach roads). It excludes:
• Breakdowns, refueling, or maintenance delays.
• Shift changes or meal breaks.
• Explicit modeling of unconstrained road segment traffic dynamics (passing, acceleration).
• Ore grade blending or material properties.

Entities

The primary active entities moving through the system are Trucks. Each truck cycle consists of:

1. Routing from its current location to an available loader.
2. Traveling empty to the loader queue.
3. Loading an ore payload.
4. Routing from the loader to the primary crusher.
5. Traveling loaded to the crusher queue.
6. Dumping the payload.
7. Repeating the process.

Resources

The system is constrained by:

• Loaders: LOAD_N (capacity 1) and LOAD_S (capacity 1).
• Crusher: CRUSH (capacity 1).
• Road Segments: Edges with a capacity less than 999 are modeled as single-lane resources that trucks must acquire before entering and release upon exiting.

Events

Key discrete events tracked in the simulation include:

• travel_start: Truck enters a road segment.
• travel_end: Truck exits a road segment.
• queue_start: Truck arrives at a resource (loader, crusher) and waits.
• load_start / load_end: Ore loading process.
• dump_start / dump_end: Ore dumping process at the crusher.

State Variables

Tracked state includes:

• Truck status (location, loaded/empty).
• Resource states (busy/idle, queue lengths).
• Accumulators (total tonnes delivered, total truck active time, total crusher busy time).

Assumptions

• Derived from data:
  • Stochastic activity times (loading, dumping, travel) follow a truncated normal distribution to prevent negative durations.
  • The road network allows shortest-path calculations based on expected travel time.
• Introduced:
  • The dispatch policy assigns an empty truck to the loader that minimizes expected turnaround time (travel time plus expected queue waiting time).
  • Trucks evaluate loader choices immediately upon finishing a dump.
• Limitations:
  • Unconstrained roads assume no traffic interference. Trucks travel at their maximum achievable speed modified by their loaded/empty factor.
  • The dispatch decision does not account for the travel time of other trucks currently heading to the same loader, which might lead to temporary clustering.

Performance Measures

• Throughput: Total tonnes delivered and tonnes per hour.
• Cycle Time: Average duration from one dump completion to the next.
• Utilisation: Percentage of time trucks and the crusher are actively engaged in operations.
• Bottleneck indicators: Average queue times at loaders and the crusher.

README

Synthetic Mine Throughput Simulation

This project implements a discrete-event simulation of a mine haulage network using SimPy and NetworkX. It estimates ore throughput to a primary crusher over an 8-hour shift under various operational scenarios.

Installation & Requirements

Ensure you have Python 3.8+ installed. The simulation requires the following dependencies:

pip install simpy networkx pandas numpy scipy pyyaml

Running the Simulation

Execute the main simulation script, which runs 30 replications for all 6 required scenarios:

python3 sim.py

This will generate:

• results.csv: Replication-level detailed results.
• summary.json: Aggregated scenario metrics and confidence intervals.
• event_log.csv: A complete discrete-event trace for all replications.

Conceptual Model & Assumptions

Please refer to conceptual_model.md for details on system boundaries, entities, state variables, and resource definitions.

Routing and Dispatching Logic

• Routing: Shortest-path routing using Dijkstra’s algorithm. Edge weights are defined as the expected travel time (distance / max_speed). Empty and loaded speeds are handled by dynamically calculating path times.
• Dispatching: Dynamic nearest-available loader assignment. After dumping, a truck chooses a loader by minimizing the sum of expected travel time and expected queue waiting time.

Operational Decision Questions

1. What is the expected ore throughput to the crusher during the baseline 8-hour shift?

The baseline configuration delivers approximately 12,416 tonnes per shift (1,552 tonnes per hour) with a 95% confidence interval of roughly [12,341, 12,491].

2. What are the likely bottlenecks in the haulage system?

In the baseline, the Crusher operates at around 90-91% utilisation, while trucks experience minor queuing at the loaders. As the fleet grows, the Crusher becomes the absolute constraint, generating long queues.

3. Does adding more trucks materially improve throughput, or does the system saturate?

The system saturates. Increasing the fleet from 8 to 12 trucks yields negligible additional throughput (rising slightly to 12,666 tonnes), but crusher queues skyrocket to 14.9 minutes. Decreasing the fleet to 4 trucks severely drops throughput (to 8,126 tonnes). The baseline 8-truck fleet is optimal for this crusher capacity.

4. Would improving the narrow ramp materially improve throughput?

No. The ramp upgrade scenario delivers ~12,440 tonnes, practically indistinguishable from the baseline. This is because trucks only traverse the ramp once during the initial dispatch from parking. Subsequent cycles occur entirely in the upper network.

5. How sensitive is throughput to crusher service time?

Extremely sensitive. The crusher_slowdown scenario cuts throughput by nearly half (to 6,440 tonnes). Crusher queues explode to 28 minutes, bottlenecking the entire cycle. Since the crusher operates continuously near 90%+ utilisation in baseline, any degradation immediately impacts production.

6. What is the operational impact of losing the main ramp route?

Negligible to zero. In the ramp_closed scenario, throughput remains at ~12,416 tonnes. Trucks simply take the western bypass from PARK to the loaders. Since this detour is only taken once at the beginning of the shift, the 8-hour steady-state throughput is completely unaffected.

Limitations

• No breakdowns or shift changes are modeled.
• Traffic dynamics on wide roads (passing, acceleration, deceleration) are not explicitly simulated, potentially underestimating travel times when the network is busy.

Reviewer form

Reviewer Form: Synthetic Mine Throughput

Submission: 2026-04-25 / 001_synthetic_mine_throughput / pi-agent / gemini-3-1-pro-preview / vanilla-customtools Reviewer: Independent human reviewer (opus subagent) Date: 2026-04-27

Automated report

• Automated report file: results/evaluation_report.json
• Runtime seconds: not recorded (runtime_seconds: null); harness ran agent in 297 s per submission.yaml
• Python LOC: 275 code lines across sim.py (72) + sim_core.py (203)
• Required scenarios present: 6/6
• Behavioural checks passed: 53/53 (incl. trucks_12 > trucks_4, crusher_slowdown < baseline, ramp_closed <= baseline)
• Token usage method: declared in submission.yaml (78k in / 21k out), but no token_usage.json per protocol

Human quality score

Top 3 strengths

1. All behavioural sanity checks pass and the numbers tell a coherent story. baseline 12,417 t, trucks_4 8,127 t, trucks_12 12,667 t (saturation), crusher_slowdown 6,440 t, ramp_closed = baseline. The crusher_utilisation ~0.91 in baseline is consistent with the saturation conclusion.
2. Genuine SimPy DES with constrained-edge modelling. Single-lane edges (capacity < 999) become simpy.Resource and trucks acquire/release them via with blocks — not a static spreadsheet calculation.
3. Working dispatch heuristic and event log allow audit. The shortest-time + queue-aware loader choice is documented in the README and visible in code (sim_core.py lines 117-136), and the event log permits per-truck cycle reconstruction.

Top 3 concerns or gaps

1. Loader utilisation tracked internally but never reported (stats['loader_busy_time'] populated, but loader_utilisation: {} empty in summary.json). The recommended schema explicitly asks for it, and it’s needed to identify whether LOAD_N or LOAD_S is the binding loader.
2. No warm-up handling and no additional scenario proposed. Warm-up is set to 0 with no justification despite a known startup transient (8 trucks dispatched simultaneously from PARK), and the prompt’s invitation to propose one extra scenario was not taken — a missed analytic opportunity.
3. Conceptual model and code show small inconsistencies and shortcuts. Truncated-normal claimed, plain Gaussian + clip used; 999 used as a sentinel for unconstrained capacity; bottleneck classification is a heuristic threshold rather than a derived measure; only 12 comment lines in 275 LOC; no requirements.txt.

Failure modes observed

• Poor assumption management (truncated-normal vs Gaussian-clip mismatch)
• Did not propose an additional scenario / no warm-up justification

Final judgement

Marginal-to-acceptable submission. Trustworthy as a first-pass decision-support artefact, partially.

The simulation is real DES, results are internally consistent, scenarios are correctly perturbed, and the decision questions are answered with defensible numbers. However, the analysis is shallow (no per-loader utilisation, no warm-up reasoning, no proposed scenarios, terse interpretation), the code is minimally documented, and the conceptual model glosses over operational detail. Final score: 73/100. Useful to bracket throughput estimates and inform the conversation, but would not commission capex on the ramp purely based on this output without additional analysis on the bypass-vs-ramp routing assumption.