Paved surface irragation

General
1

Hi, I have a question regarding simulating irrigation or street cleaning on paved surfaces in SUEWS.

I would like to prescribe a paved-surface watering rate of 0.5 mm h⁻¹. My current setup is:

  • WaterUseMethod = 1, so external water use is prescribed through the forcing data;
  • the irrigation fraction of the paved surface is set to 1.0;
  • irrigation fractions for the other surface types are set to 0;
  • the forcing data are hourly, while SUEWS is run with a 5-minute model time step.

My understanding is that the bulk Wuh forcing variable has units of m³ per forcing time step and is distributed to the surfaces according to their irrigation fractions.

However, I found that the SuPy forcing validation file, checker_rules_indiv.json, defines the valid range of Wuh as 0–10 m³. For a 1 km² grid, the required hourly Wuh can easily exceed 10 m³. For example, with a paved fraction of 0.5, 0.5 mm h⁻¹ corresponds to 250 m³ h⁻¹.

Could you please clarify the following?

  1. Is the 0–10 m³ range in checker_rules_indiv.json a strict physical or numerical limit, or only a legacy input-validation range?
  2. Can values larger than 10 m³ be safely used by disabling or modifying the input validation?
  3. Can the current SUEWS kernel represent a paved-surface watering rate of 0.5 mm h⁻¹ for a grid?
  4. Are the newer wuh_paved forcing columns currently used by the physical calculation, or are they only stored as metadata?

My SUEWS version is v2026.6.5.dev0.

2

Thanks for the detailed question, and for going straight to the checker rules; that makes this easy to answer precisely.

Short answer first: the 0-10 m3 range is a validation guard on the Python side (in checker_rules_indiv.json), not a limit in the model kernel. It is a fixed constant applied regardless of grid area, which is exactly why it breaks down for a city-scale tile. That is a known problem, tracked in #1440. Your arithmetic is right: 0.5 mm h-1 over 0.5 km2 of paved is 250 m3 h-1, well above the guard.

To your specific questions, for the 2026.6.5 line you are running:

  • Units and what the kernel sees. With WaterUseMethod=1, SUEWS reads a single bulk Wuh column in m3 per forcing timestep and converts it internally to a depth by dividing by the irrigated area (wu = Wuh / irrigated_area * 1000, in mm). So the kernel represents 0.5 mm h-1 paved watering perfectly well; you just express it as the equivalent m3, which is what you have already done.

  • Targeting paved. Set the paved irrigation fraction to 1 and the others to 0, as you have. The observed water is then distributed onto the irrigated surfaces in proportion to their irrigation fraction, so with only paved irrigated, all of it lands on paved. That is the correct way to prescribe paved-only watering today.

  • The 10 m3 guard. It is legacy validation and safe to exceed for Wuh specifically, since there is no hard cap in the physics. If you bypass the checker you can run larger values, but be aware that disables the whole range-check pass, not just this one field, so treat it as a stopgap rather than a setting to leave off.

  • wuh_paved and the other per-surface columns. In your version these are recognised in the forcing schema but kept as metadata only; they are not yet consumed by the kernel. So do not rely on wuh_paved to deliver water; use the bulk Wuh column for now.

One practical note on hourly forcing with a 5-minute timestep: Wuh is treated as a sum variable, so the hourly total is split evenly across the twelve 5-minute steps (the hourly sum is conserved). Put the per-hour total (your 250 m3) in the hourly column and SUEWS handles the disaggregation.

Direction of travel: relaxing the area-independent cap (#1440) and moving water-use forcing from m3 to mm (#1441) are both in progress under the umbrella #1447. The per-surface mm pathway has already landed on the development branch on the Fortran side, which will eventually let you prescribe 0.5 mm h-1 on paved directly, without the m3-to-area step. Following those issues is the best way to track the timeline.

1 Like
3

Thank you very much for the detailed clarification. That makes the issue much clearer.

Based on your explanation, I manully modified the local checker_rules_indiv.json file by increasing the maximum allowed value for Wuh. After doing this, I can now run prescribed high-volume paved-surface irrigation / street-cleaning events without triggering the error:

RuntimeError: SuPy stopped entering simulation due to invalid forcing!

1 Like