Technical Reference

Delivery Schedules (Agricultural Rotations)

Standard EPANET software is designed for municipal drinking water systems that run continuously. It does not inherently understand rotational water rights, shared ditch capacities, or staggered agricultural delivery schedules.

To solve this, IAMDD utilizes a custom Python control loop (simulation.py) that forcefully interrupts the EPANET solver every hour to enforce user-defined scheduling rules before the hydraulic mathematics are calculated.

1. Schedule Parsing

When a simulation begins, the engine parses the active Rotations defined in the project settings. Each schedule is broken down into three temporal parameters:

  • Interval: The total length of the rotation cycle in hours (e.g., a 2-day rotation = 48 hours).
  • Duration: The number of hours the headgate is legally allowed to be open during the interval.
  • Offset: The number of hours the schedule is delayed from the start of the simulation (ETime 0). This allows users to stagger fields so they don't all turn on simultaneously.

2. The Hourly Enforcement Loop

As the simulation progresses, the overarching Python wrapper intercepts the model at the top of every hour.

Before determining crop stress or running the EPANET hydraulic solver, it evaluates the schedule. The engine mathematically compares the current simulation hour against the Interval, Duration, and Offset parameters for every assigned schedule.

If the math dictates the field is currently "Off-Schedule", the Python engine directly interfaces with the EPANET toolkit to forcefully change the assigned turnout pipe's status to Closed.

3. Absolute Demand Overrides (The 5 PSI Rule)

Closing the pipe creates a disconnected sub-network. In standard EPANET, if a node has a positive demand but is completely disconnected from a water source, the mathematical solver will crash or generate massive negative pressures (e.g., -999 psi) as it attempts to pull water out of an empty, sealed void.

IAMDD prevents this mathematical collapse using a multi-step override sequence:

  1. Static Baseline Reading: With the headgate pipe closed, the engine takes a preliminary reading of the static pressure at the delivery junction. Because the pipe is closed, the static pressure collapses.
  2. The 5 PSI Disconnect Rule: The engine checks if the static pressure is physically viable. If the pressure at the node is below 5.0 psi, the engine recognizes that the sub-network is cut off from the main supply.
  3. Forced Zero: Because the pressure is below the threshold, the Python engine forcefully overrides the field's target demand to exactly 0.0 gpm.

This combination of forcefully closing the pipe and forcefully zeroing the demand allows IAMDD to perfectly simulate a locked headgate. Even if the field's soil moisture reaches the Permanent Wilting Point and the crop is dying, the engine will stubbornly refuse to deliver water until the rotational scheduling logic permits the pipe to re-open.