I have not seen anything on street inlet modeling in the SWMM EXTRAN literature, so I would like to bring it up for discussion. After browsing through the SWMM User Archives (www.chi.on.ca/swmmqa61.html), I did find a very interesting discussion under Inlet Restriction by Reinhard Sprenger and Gilles Rivard dated 13 November 1997. Their discussions centered on use of inlet restrictors, a closely related topic implying prior modeling of the inlets. This archive is recommended co-lateral reading. Evidently both Reinhard and Gilles have already crossed some of the the bridges described below, but they did not specifically discuss inlet modeling.

Storm drain inlets in street gutters are generally used to collect gutter flows and pipe them to the nearest manhole on the EXTRAN network. EXTRAN models which I have reviewed (and which I have made) have generally not included modeling of inlet detail. Instead, it has been customary to assume that the RUNOFF module- generated flow "falls" into the EXTRAN manhole or "node" directly. EXTRAN then processes the hydrograph, either accepting all of it or rejecting part of it when the HGL will not allow more inflow.

Omitting the inlet detail is a matter of some convenience in modeling since it eliminates the need to include 4+/- inlets per manhole with 4+/- associated small diameter pipes to the manhole, assuming 4 inlets per intersection.

In the "old days", a few years back, when EXTRAN model size was a necessary concern, omission of the inlets was a desirable and even necessary approximation. Any attempt to add them in quantity would have run up against program or computer memory capacity. Few EXTRAN storm drainage models included inlets and their related piping. (however, from the interchange noted above between Reinhard and Gilles, it appears that inlet modeling may be practiced more frequently with CSOs).

Limitations on EXTRAN model size are no longer problems in most cases. So the question arises, what are the pros and cons on modeling storm drainage inlets?

Certainly the cons are related to the extra work involved in setting up a model. Probably on the order of four times the number of nodes, and for each node an additional 4 pipes, typically, assuming the inflow of 4 inlets per manhole. This could take a relatively simple hypothetical 100-node 100-pipe model up to 500 nodes and 500 pipes, an inflation of modeling effort of 400%. And if it is desired to model ponding and delayed inflow at each inlet, an additional 400 storage nodes over that. Quite an increase in modeling effort, and in potential new sources for psuedo-transients that have to be ferreted out.

As for the pros, the most important consideration is that inclusion would enhance the model's realism. Modeling the losses (form and skin friction) in these facilities will result in additional time of travel in the system hydrographs in the mains. In addition, modeling these losses may result in greater local flooding than when they are not modeled.

Conversely, when the inlet and inlet piping are not modeled, EXTRAN creates a main line hydrograph with a shorter time of concentration than occurs in the prototype, everything else being equal. This would tend to calculate higher mainline peak flows and mainline nodal flooding downstream.

In some case inlet modeling might be an important factor in calibration. While the RUNOFF module has parameters that facilitate calibration, calibration usually requires hydrograph matching in EXTRAN, since the EXTRAN part of the system is usually where the only real flow data can be taken.

When calibrating SWMM using experimentally derived runoff parameters (as given in the manual or other references), it may sometimes be found that large deviations from these parameters are needed to force a calibration on data in EXTRAN. That may leave the modeler puzzled as to why unusual RUNOFF parameter values are needed to get a good calibration. Maybe part of the calibration problem could be lack of detailed modeling of the inlets and inlet piping in EXTRAN , since this will alter the timing and magnitude of EXTRAN peak flows.

In newer systems, often relatively large diameter inlet-to-manhole pipes are specified, mainly to facilitate maintenance cleaning. In older systems, these pipes were frequently sized according to the minimum size that was manufactured. In the first case pipes range from 12 to 18 inches, and in the second case 6" or even smaller. Thus such losses will tend to be more of a constricting factor in older systems, due to the increased frictional loss in the smaller piping and the inlets.

EXTRAN with the inlets modeled will by itself calculate the amount of flooding at each of these nodes, (in terms of water rejected). If each of the inlets is additionally modeled as a storage node, the flow will first store locally and eventually feed back into the system (unless the storage capacity is exceeded, in which case the node will "flood"), after the main line HGL recedes.

A number of cities have specified street transmission be considered in EXTRAN modeling, in which the streets are modeled as "natural" open channels running node to node. If the street channels are sized large enough, they could replace the concept of a storage node, since EXTRAN tracks storage volume in the channels. Excess RUNOFF module-hydrograph flow would then go into conveyance storage in the street channel, for the period that it cannot enter the local inlet due to high HGL. In the typical street design, the crown separates the two gutter flows and their spreads, assuming over-crown flow does not occur. With inlets modeled, each street would typically have two channels, one for each gutter and its spread. So in our hypothetical model, instead of modeling 400 storage nodes, one could model from 400+/- up to 800+/- connecting gutter channels between the 400 inlets, depending on street drainage patterns.

This seems to be getting out of hand. While this hypothetical system is a bit unrealistic, the arithmetic indicates that modeling inlets could amount to a formidable increase in effort.

This leads to the question are there reasonable simplifications available? For example, designate a single surface storage node at a new standard node next to the system manhole node, and connect them with a single virtual pipe with transmission parameters mimicking the transmission capabilities pf the four (or whatever) original inlets and their pipes. I have not tried this, but offhand it would appear doable.

I would like to ask the group for comments, suggestions, simplifications, etc. Has anyone been doing this? If so, what have been your experiences? Any with/without modeling and comparative stats? Any thoughts on calibration considerations? Also, can anyone add to Reihard and Gilles' discussion noted above re inlet modeling in CSOs?

Ron Kilmartin
kilm-ron@ix.netcom.com
ronkilmartin@worldnet.att.net