Vet Clinic Simulator

The model has three categories of places:

• Resources: dvm_avail, rvt_avail, exam_room_free, surgery_free — tokens represent available staff and rooms
• Queues: wait_exam, wait_tech, wait_surgery — tokens accumulate when patients wait for service
• In-service: in_wellness, in_spay, in_xray — tokens represent patients currently being treated

A patient flows through the net: arrival → wait_* → in_* → checkout → discharged. Surgery patients detour through in_recovery first.

Why This Matters

Resource places create bottlenecks naturally. When all DVMs are busy (0 tokens in dvm_avail), exam transitions cannot fire and the queue grows — exactly what happens in a real clinic.

Each clinical service has a start/finish transition pair:

• start_wellness consumes tokens from wait_exam + dvm_avail + exam_room_free, produces a token in in_wellness
• finish_wellness consumes from in_wellness, returns the DVM and exam room, sends patient to checkout

Triage transitions (triage_to_exam, triage_to_tech, etc.) route arriving patients to the correct queue based on the service mix sliders.

The Source Transition

patient_arrives is a source transition with no input places. Its rate directly controls how many patients enter the system per hour. After 5:30 PM, this rate drops to zero — no new arrivals, but in-progress procedures finish.

Instead of stepping through individual events, the simulator solves a system of ordinary differential equations:

Why Piecewise?

Staff levels change throughout the day (lunch breaks, part-time shifts ending). The simulator splits the day into segments at each staff change, solving each segment independently and stitching the results together. This captures the 12:30 PM lunch dip and afternoon staffing changes accurately.

What the ODE Reveals

• Queue buildup: When arrival rate exceeds service capacity, queues grow — visible as rising curves in the Queues plot
• Staff utilization: The fraction of time each resource is busy (tokens consumed vs. available)
• Steady state: Whether the clinic reaches equilibrium or queues grow unbounded

The financial dashboard is derived directly from the ODE solution:

• Revenue: Each service type has a price (wellness exam: $65, spay: $350, etc.). Revenue = cumulative patients × price.
• Supplies (COGS): Each service consumes inventory items (vaccines, suture packs, x-ray film). Costs are tracked per-item.
• Staff cost: Hourly rates × hours worked, computed from the staff timeline including overtime.

The gross profit margin emerges from the interplay of service mix, staffing levels, and patient volume — all encoded in the Petri net topology.

The Schedule view introduces a human dimension to the Petri net model:

• Employee registry: DVMs, RVTs, and receptionists with full-time/part-time classifications
• Shift scheduler: Gantt-style chart showing who works when, including auto-generated lunch and rest breaks
• Staff timeline: Converted to piecewise ODE segments — when a part-time RVT leaves at 1 PM, rvt_avail drops by 1 for the remaining segments

This is where Petri nets shine: the same model works for both the simple slider-based staffing and the detailed per-employee schedule. The ODE solver doesn't care where the numbers come from.