[Scoping] Scheduling layer (campaigns, equipment allocation, greedy + MILP)

[bernalde]

Goal (scoping issue)

Add a scheduling capability on top of the flowsheet simulator — multi-product/multi-batch campaign planning, equipment allocation, and makespan analysis. This issue scopes the approach; a design spec follows before implementation.

Current state

PharmaPy is purely a simulator with no scheduling layer:

• SimulationExec (SimExec.py:24-166) builds a DAG and runs unit operations strictly sequentially via topological_bfs (Connections.py:238-258); SolveFlowsheet (SimExec.py:49) is a serial loop, recycle streams are explicitly rejected (SimExec.py:45-47).
• time_processing (SimExec.py:144-146) records elapsed time after execution — there is no planning, no equipment sharing, no campaign/recipe concept, no makespan optimization.
• No optimization dependency for scheduling (cyipopt is used only for parameter estimation in ParamEstim.py).

Proposed approach (high level)

• New data structures (PharmaPy/scheduling.py): Recipe (ordered unit sequence + operation times), Campaign (batches, due dates, priorities), Equipment/EquipmentPool (availability, capacity).
• Two schedulers:
  • GreedyScheduler — fast forward list-scheduling; no extra dependencies.
  • MILPScheduler — makespan / objective optimization via Pyomo (optional extra), with a pluggable solver (glpk/cbc/gurobi).
• A ScheduledFlowsheetExec extending SimulationExec that takes a schedule, then drives the existing per-batch simulation for each scheduled batch and aggregates results (Gantt/timeline output).

Open questions for the design follow-up

• Scope of v1: fixed operation times from prior simulations vs. simulation-in-the-loop timing.
• Resource model granularity (single-stage equipment vs. storage/holdup with DynamicCollector, ContinuousHoldup in Containers.py).
• Whether Pyomo becomes an optional extra (keep core install lean).

Deliverables

• Design spec (data model, scheduler APIs, MILP formulation, integration with SimulationExec).
• GreedyScheduler first (no new hard deps), then optional MILPScheduler (Pyomo extra).
• Example multi-batch campaign + tests (unit tests for the greedy scheduler; MILP test gated on solver availability).

Depends conceptually on a working test/CI baseline (#3 theme A).

---

Upstream PR

Wave 4 — propose before building. Discuss scope and the new optional Pyomo dependency with maintainers upstream before implementing. See #3.