Stormwater-Management-Model
Stormwater-Management-Model copied to clipboard
USEPA
Problem with Cumulative Rainfall if there is a negative instead of positive increase in the Rainfall.
A user was using NOAA rainfall and it seems the NOAA rainfall is not consistent. A few negative increments in the last 9 hours cause the rainfall to inflate from 3 to 90 inches. I am attaching the text file in case it helps others.
The rainfall looks like this in SWMM5
once you run the model the total rainfall is 90 inches instead of 3.2 inches and the hyetograph looks like this
Added a check on negative increments and it seemed to work, if the current r is greater than the last r (.rainAccum) is set to zero
case CUMULATIVE_RAINFALL:
if ( r < Gage[j].rainAccum )
r1 = r / Gage[j].rainInterval * 3600.0;
else r1 = (r - Gage[j].rainAccum) / Gage[j].rainInterval * 3600.0;
if (r - Gage[j].rainAccum < 0 ) r1 = 0.0; // Autodesk, 2021
fprintf(Frpt.file, "\n rainfall Gage[j].rainAccum %f %f %f %f ", r1, r, Gage[j].rainAccum, r - Gage[j].rainAccum);
Gage[j].rainAccum = r;
break;
The fix works OK for the example project supplied, but what happens with the following sequence of hourly cumulative rainfall:
Hour: 0 1 2 3 4
Rain: 1 1.2 1.5 0.2 0.3
The 0.2 value is meant to start a new cumulative sequence beginning at hour 3 with a rainfall of 0.2 inches. The proposed fix will begin the new sequence, but instead of returning 0.2 as the rainfall for hour 3 it will return 0.
I don't think there is any foolproof way to distinguish between bad data and the start of a new cumulative sequence. Here's one possible alternative:
case CUMULATIVE_RAINFALL:
r1 = r - Gage[j].rainAccum;
if (fabs(r1) < RAIN_GAGE_ACCURACY)
{
r1 = 0.0;
}
else
{
r1 = r1 / Gage[j].rainInterval * 3600.0;
Gage[j].rainAccum = r;
}
break;
It seems to me you're bending over backwards to handle an exceedingly rare condition. The only time I use a cumulative rain gage is with a synthetic curve (e.g. SCS, Atlas 14). I suspect few users that have ever attempted to use a multi-event cumulative recording gage as SWMM input. While I see that the manual says "each rainfall value represents the cumulative rainfall that has occurred since the start of the last series of non-zero values," I don't see where by that logic you couldn't require intervening zeroes to separate events. Simpler still, you could trigger a warning for any cumulative rain gage that is not monotonically increasing. Recall that in Bob's example the input time series was erroneous - while SWMM's interpretation of the data was problematic, the data needed adjustment to make sense regardless.
Requiring a recording time period with 0 rainfall to separate events would break backward compatibility. Issuing a warning message when a drop in cumulative rainfall is encountered would trigger a false positive for the example I posted above (where there is no 0 rainfall period separating events). I agree that the issue being discussed is an uncommon one, and that the simulation results would give a clear indication that something is amiss with the rainfall data. Perhaps the best course of action is to leave the existing code as is.
The user reexported the data from NOAA using a larger interval and eliminated the problem. In this particular case while he did not know what the issue was the mere graphing of the large rainfalls and the rainfall amount in the Subcatchment Summary Table alerted him to the issue. So it is unusual.
@dickinsonre , since it seems there is agreement this occurrence is unusual, do you mind if I close this issue?
