Hi @awh142857. Thank you for raising this issue. We will look into it as this requires some thinking. One approach I have used in the past when coupling overland and the subsurface drainage is do an iterative coupling to ensure continuity of the hgl when the hgl exceeds the rim. However, this will come at a computational cost. Solving this issue will definitely require some in-depth testing.

@awh142857, I have been able to confirm your observation in the model you shared. It is, however, unclear whether the inlet equations apply in the reverse direction to allow for the coupling you are looking for. Using orifices as you have done is likely the best solution for now even though you loose the benefit of using the inlet equations. Again, thanks for raising this issue. We will look into.

The inlets feature added to v5.2 was meant to implement the widely used HEC-22 equations for computing the amount of street flow diverted to a sewer by various types of inlet designs. For on-grade inlets, these equations have flow capture be a function of the street flow rate and not depth. HEC-22 is silent on how to model sewer to street backflow under surcharged conditions. If you want to make the flow exchange between street and sewer be based strictly on HGL then you would need to use another approach such as deploying orifices or outlet links (with a rating curve) to couple the two systems. But then you would not be using the HEC-22 on-grade methodology, which was the whole point of developing the inlets feature.

However, for on-sag inlet locations, the HEC-22 equations are based on depth and therefore would be compatible with using an HGL approach to determine a flow exchange rate. The equations essentially describe a rating curve of flow rate as a function of the difference in HGL between the street and sewer node. The plot shown below is the rating curve for the curb opening inlets used in the example submitted by @awh142857.

Replacing the Orifices with Outlet links with this rating curve in @awh142857's example, we get the following comparison between flow rates exchanged between street node S2 and sewer node P2 (at a reporting time step of 1 minute):

The Outlet link produces a more satisfying result than does the Orifice link, plus it is faithful to the HEC-22 equations.

This exercise suggests making the following changes to how the Inlets feature of SWMM is implemented:

1. Keep the on-grade inlet analysis as-is since there is no apparent way to switch from a flow-based capture calculation to an HGL-based surcharged calculation (I've tried doing this and the result was highly unstable).
2. Treat the on-sag inlet analysis using a virtual Outlet link that implements the HEC-22 rating curve equations for the particular inlet design being analyzed. This means moving the computations into the iterative scheme used in dynwave.c. (The on-grade lateral flow adjustment scheme is done outside of dynwave.c, basing street flow capture and sewer node flooding on results from the most recent time step).
3. This shouldn't require any change to the input data used for Inlets, but SWMM would have to adjust the rim elevation of on-sag sewer receptor nodes to match the invert elevation of its street capture node in case they weren't the same.

Thanks for the inputs @LRossman. Could you clarify why you see the Outlet as being more faithful to the HEC-22 equations? Does it not require some insights/calibration to tune the the curve parameters or derive the head vs flow relationship to use?

Also on 2, are you suggesting implementing the hgl coupling/feedback (i.e., moving it into the dynamic wave) only for on-sag inlets that have a configuration that uses the HEC-22 rating curves or are you suggesting implementing it for all on-sag inlets?

The Outlet used in the example I gave is derived directly from the HEC-22 equations for a curb opening inlet of height H and length L:

Q = 2.3 * L * d^1.5  for d < H
Q = 0.67 * (L*H) * sqrt(2g * d)  for d > 1.4*H

where Q is flow in cfs, d is the head difference in feet, and linear interpolation is used for d between H and 1.4*H. The equations for a grate inlet will look slightly different. Please consult the Inlets Tutorial for more information. That's the beauty of using the HEC-22 equations -- the rating curve is analytical and comes pre-packaged so there is no calibration or curve fitting required and they have supposedly been verified experimentally.

I'm proposing that on-sag inlet calculations be moved into the dynamic wave calculations for all types of inlets -- grates, curb openings, slotted inlets, or custom inlets with user-defined rating curves. Remember, the advantage of using the pre-packaged Inlets feature is that the analyst can use well accepted computational methods while being spared from having to explicitly add orifices or outlets between streets and sewers along with their parameters.

@LRossman, I think treating the sag inlets as virtual outlet links with rating curves makes a lot of sense, with the rating curves coming from HEC-22. I took your rating curve (which would be nice to be able to export from SWMM if it's not something already there that I just missed) and put it into a copy for myself. It's giving some oscillations, but not nearly as much as the orifice equations did. I didn't realize that an outlet would work both ways based on the head differential in the rating curve. If it's this much more stable, then maybe SWMM could give the user the option to convert an orifice to an equivalent rating curve and use that rating curve internally, much like what you are suggesting to do for the HEC-22 inlets.

Simply using a HEC-22 rating curve isn't perfect, because for a curb inlet, it is a combination of weir flow conditions for low depths and orifice conditions for high depth, but it should be pretty close. Once it becomes submerged, it should really resort to orifice-only for low head differentials, which would have lower flows at lower head differentials. That effect should be fairly small, though.

In my simple example, the rating curve is very stable until the storm sewer HGL hits the bottom of the orifice, at which it becomes somewhat, but not very, unstable, since it starts accounting for the difference in head between the nodes, rather than just the upstream head. I think the difference I'm seeing between the rating curve and inlet is due to the fact that HEC-22 uses weir equations for curb inlets at low depths.

On-Grade Inlets

For on-grade inlets, SWMM should have some means of handling HGL-surcharged conditions, because there will be occasions where reverse flow happens and capping the pipe HGL at the rim doesn't give the right result in the pipe system. The HEC-22 equations are also really only valid when the HGL is below the inlet. Once the HGL reaches the inlet, an on-grade inlet could change behavior dramatically. In that case, a grate inlet would act more like an orifice, with the head differential being the depth of flow in the gutter vs the pipe HGL. If the pipe HGL is above the depth for approaching flow down the gutter, water would leave a grate inlet and continue down the street. An on-grade curb inlet would probably act somewhat similarly, but it's hard to visualize what would really happen. I can see that it would be difficult to get stability using the HEC-22 equations and trying to do submergence.

Applying a rating curve like the sag inlets wouldn't work quite right, because the rating curve wouldn't work the same both directions, like for an orifice based on a sag inlet, which is more similar. You'd have to have a two-sided rating curve that doesn't have a discontinuity at zero, but that uses an orifice-based curve for negative depth differentials and a HEC-22-based curve for positive depth differentials. That would involve re-imagining the outlet to allow negative head/flow combinations that weren't just mirrors of the positive values but should otherwise be able to use the same data entry forms. Also, that rating curve wouldn't really behave the same when the HGL is above the gutter, but it would be better than not having it, and if the HGL is above the gutter, it would probably be mostly low head differentials in that case.

Two-sided Rating Curves

There's no reason that a rating curve has to be the same for positive/negative head differentials, as long as they meet at zero with the same slope (and that slope close to zero should be fairly low, so that the flow goes to zero as the head differential gets close to zero). If you can develop two-sided rating curves, then you could apply them to the sag inlets as well, with one side being weir/orifice based for flow into the inlet and the other being orifice-only for flow out of the inlet.

Adjacent node backups for on-grade inlets

One other thing to consider is that for some flat areas (like Houston), the HGL at a sag can back up to be higher than adjacent on-grade inlets and would result in the inlet behaving more like an orifice than a typical on-grade inlet.

@LRossman I didn't read your on-grade comment closely enough. You say that the on-grade for HEC-22 is flow-based, which is true. I guess I was thinking about how that flow translates to head, but that's not quite the same thing.

The 'inlet head' at an on-grade inlet is primarily a function of the flow going down the gutter, not based on the node volume or a typical 'node head' value. But, like I said, it can be also affected by adjacent nodes and by surcharge from the pipe. At any given time step, the flow through the inlet would be affected by: Link Depth (Link DS HGL = street DS invert + Link Depth), Street DS Node HGL, and Inlet Storm Sewer Node HGL (in the pipe).

If the Inlet Storm Sewer Node HGL is below gutter, and the Link DS HGL is higher than the Street DS Node HGL, then use the HEC-22 curve.

If the Street DS Node HGL is higher than the Link DS HGL, then the inlet would use an orifice-like rating curve, rather than the HEC-22 RC. That could be pre-calculated based on the opening shape and stored for later use.

If the two overland HGLs are close (within 0.1'?) to each other, calculate inlet flow using both methods and interpolate to determine the flow used. so that there isn't a big discontinuity when they switch over.

Apply a submergence factor to both RCs if the Inlet SS Node HGL is above gutter.

If the Inlet SS Node HGL is highest, then use the 'negative' side of the rating curve and let flow leave based on the head differential, using the higher of the two overland heads for the delta head calculation.

The tough part is making sure that there aren't any discontinuites in there that would cause sharp jumps in HGL or flow for small changes in conditions.

Also, how'd you get the flow through the inlet for the graph you posted above? I didn't see that in the SWMM GUI graphing options.

To add to the discussion, HEC-22 approach assumes that there is no flow restriction in the downstream pipes due to tailwater submergence or pipe capacity limitations. Therefore, it makes sense the model results under tailwater submergence will differ from using orifices to represent inlets.

To account for tailwater submergence for on-sag inlets, a tabular-head rating curve with SWMM dynwave.c is a good option, as Lew suggested. However, the challenge is to differentiate low head differences under non-submerged (weir flow) and submerged (orifice flow) conditions. When effective depth < H, in all these situations shown below (from SWMM reference manual - Page 110) will be represented with weir flow component of the rating curve.

This requires multiple rating curves depending on the submergence on each side as well as to represent back/reverse flow. awh142857's suggestion to support negative head/depth is a great idea to represent backflow when it is different from inlet capture. Currently, you have to use two outlet links (with inlet capture and backflow rating curves) with flap gates to represent this.

As discussed, the biggest challenge is to represent on-grade inlets under submergence. I was wondering whether while keeping the HEC-22 on-grade flow capture computations as a lateral flow, adding an internal orifice to inlet dimensions or outlet link for custom rating curves with flap gate to represent potential backflow when there is tailwater submergence. Again, this needs to be checked for flow discontinuity or instabilities.

@NandanaPerera,

These rating curves are starting to sound a lot like the HTAB curves that HEC-RAS uses for bridges, but with the added complexity that reverse flow doesn't just use the same set of curves. The RAS system does work fairly well if you have a clean set of curves, but in real-life situations, it's very common for there to be non-monotonic situations, where when you hit the deck of a bridge, the flow goes down while the HW and TW go up. HEC-RAS doesn't have a good way of forcing the curves to stay monotonic. Also, at very low flows the free flow sometimes curve doesn't have enough detail, which seems to be causing some low flow stability problems, where the flow oscillates back and forth more than it should. I know that's a problem for SWMM sometimes, too. A well-developed set of curves works fairly well and reduces the calculation load, though, as the HW is just calculated as a lookup based on the TW and flow rate, or flow rate can be interpolated based on HW and TW.

For on-grade inlets under submergence, the flow regimes are much more difficult even to visualize, much less to do the math for.

There's flow down the gutter which has a certain depth over the inlet. If the submergence was less than that depth, it would tend to push flow into the inlet, BUT Bernoulli effects based on the velocity (sort of like splashover, but different) would tend to suck water out of it if the gutter velocity was high enough.

Of course, if the submergence is higher than the gutter depth, flow would always leave the inlet, and the Bernoulli effect would just make it leave faster.

However, if the overland system is backed up such that the next downstream node's WSE is causing a backwater effect and the node WSE is higher than the gutter flow depth, that would get into the mix.

There's also the potential that there are other upstream flows entering a node that could cause the local head to be higher than the gutter flow approaching down the street with the inlet. The SWMM tutorial seems to show the inlets always at the downstream end of a link. I guess you could specify that the downstream node for an on-grade inlet should always be a continuation of the same street profile and not have any connections, so that there wouldn't be that confounding possibility, but that's not always the way things are built in the field.

If the sag inlets can be represented by HTAB-type rating curves with three variables (HW, TW, and inlet capture), on-grade inlets seem like they'd have 4 variables:

• Gutter flow, Qgutter (and thus depth and velocity)
• Overland node head (HW) based on general SWMM results not accounting for the inlet flow and drawdown
• Pipe node head (TW)
• Inlet capture flow (Qinlet)

Where the RAS HTAB curves can be shown on a 2D graph by having different submerged flow curves, these would have the additional variable of gutter flow to contend with.

If you could create a set of equations that could be solved for inlet capture flow, given the other three as independent variables, then I guess you could make a set of pre-calculated curves to look up from. It would probably be something that was computed before every simulation, because the curves would change depending on the geometry of the inlet and the street cross-section and slope, because like for HEC-RAS bridges, the computational effort for calculating it on the fly seems too high. To do so, SWMM would need a preprocessor like RAS has, and you'd want to keep track of when the HTAB curve was last calculated and only recalculate if there was a change in one of the relevant things. Fortunately, those do all seem to be associated with the street link, so there'd only be a few items to track if they had changed (link slope, inlet configuration, and link shape).

Of course, there'd also be the need for plotting the HTAB curves to review them and maybe edit them manually, so this would not be a small change. It might be worth considering, though, as once developed, there are other ways it could be applied. It might make sense to allow someone to calculate HTAB-type curves for complex model configurations outside of SWMM. Perhaps they could be created from a detailed SWMM model, then applied as curves within a larger model, to reduce the runtime for the larger model while keeping the detail about the complex structure. Perhaps they could be created from a 3D CFD model, a HEC-RAS model, or an SRH-2D model, or just hand-calculated.

Here's an interesting article that considers the actual physical layout of a street drain (curb opening -> catch basin -> connecting pipe -> manhole) in developing the two-way exchange between street and sewer flows. And another article with experimental validation of the exchange equations. I think @awh142857 is perhaps overthinking this topic too much.

@LRossman, that has been known to happen from time to time. ;-)

I do like the idea of having those HEC-22 type inlets in SWMM, but can't use them in Houston, because surcharging is so important to how our systems behave. We often have to do inlet design in something like GEOPAK Drainage or ORD, then model it again in SWMM to figure out what is actually happening. Being able to do both in SWMM and have results that would be internally consistent between the design for small storms and analysis for extreme events would be really nice.

I think it'd be OK to do some approximating, like was shown in those papers, as long as it's clear what the approximations are. That's one reason I think doing some sort of rating curve (possibly even an HTAB-like family of curves) could be useful. Having the rating curves be created from the basic inlet parameters, like you did for that example, is basically what HEC is doing, which is what made me think of applying that concept.

I don't have much time for coding, and am not great with C, but I might look at the rating curve code and see how hard it'd be to let it be two-sided. It seems like it should be relatively straightforward, depending on how the code is organized. Full HTAB-like submergence curves would be a lot harder, I'm sure.

I made some code changes that allow backflow through a HEC-22 Inlet to be a function of both sewer and street HGLs with some promising results. In inlet.c under dynamic wave flow routing:

1. When the sewer node HGL is below the street node invert then the HEC-22 equations, for either on-grade or on-sag placements, are used as before.
2. When the sewer node HGL is above the street node invert then only the HEC-22 on-sag equations are used (even for an on-grade inlet) where the "depth" supplied to the equations is the difference between the street and sewer node HGLs. If this difference is negative then the computed inlet flow represents backflow from the sewer to the street.

In dynwave.c, if a node is an inlet capture node (i.e., it receives captured street flow) then:

1. it is not allowed to surcharge
2. its maximum allowed depth is unlimited (i.e. user-specified full and surcharge depths are ignored).

After making these changes the results obtained for the example network provided by @awh142857 that uses curb inlets located on-sag are shown below. They were obtained using a 10 second variable time step with the EXTRAN surcharge method.

The invert elevation of street node S2 is 10.14 ft. When the sewer HGL is below this the inlet acts to capture street flow. After this HGL is reached at about hour 3, the street HGL remains above sewer HGL until about hour 5 over which time the difference between the two decreases resulting in a decrease in street flow capture. When the sewer node HGL exceeds the street node HGL we get negative flow (i.e., backflow) through the inlet causing the flow in the street downstream of the inlet to increase. This behavior is seen in the plot below:

These results are essentially the same as those obtained by replacing the HEC-22 inlets with Outlet links whose rating curves are derived from the HEC-22 equations.

Next consider the following modified network where the on-sag curb opening inlets are replaced with on-grade HEC-22 grate inlets:

We get a similar behavior as before where the inlet is able to capture some street flow until the sewer node HGL exceeds the street HGL after which the sewer discharges to the street. Of note is that in this case the inlet flow equations switch from being flow based while the sewer HGL is below the street invert of 10.14 ft to being head based once it rises above that level (at hour 2). The inlet flow experiences a discontinuity at the point where the switch occurs (see plot below) but remains continuously smooth afterwards.

Similar results as these were obtained using the SLOT Surcharge Method but required a much smaller time step (1 second) to produce a stable solution.

@LRossman, yes these results look encouraging especially without oscillations at transitions. This approach improves hydraulic computations compared to the current version.

The results show the increase in flow in the downstream street conduit after sewer node P2 HGL reaches 10.14'. But I was wondering why there was an increase in flow in the upstream street conduit at that time (~3 hrs). Less flow through the inlet due to submergence will increase water depth on the street node increasing volume, but should there be an increase in flow in the upstream street too? The second peak may be associated with P4 HGL reaching 10.14'?

Some other comments/questions:

1. Replacing on-grade capture efficiency with on-sag equations when sewer node HGL reaches street gutter elevation may need to be further evaluated for discontinuities for different inlet configurations. In this example, the difference is insignificant.
2. To maintain node mass balance, is the inlet flow updated as lateral flow? If so the magnitude of the lateral flow component on sewer and street nodes will be the same but with different signs (- and +).
3. It seems the sewer nodes should be assigned a surcharge depth to allow the HGL to go above the street gutter elevation.
4. Curb openings will transition from weir flow to orifice flow in both directions. But do grate inlets have weir flow for backflow as water level rises from the bellow through the grate at the same time? As per my understanding, the bottom orifice also computes weir flow under reverse flow conditions.

Please note that I have edited my previous comment about making changes to how two-way inlet flow is handled. More specifically, I found that the HEC-22 equations don't need to be included into the dynamic wave iterative solution method but can instead be treated as before where they are evaluated before each time step's iterations begin to produce a new set of lateral flows. Also the unstable results produced by the EXTRAN surcharge method disappear if sewer capture nodes are not allowed to surcharge.

With regard to @NandanaPerera's questions:

0: I don't have a simple explanation for the bump in street flow in the on-sag curb opening example once the sewer node's HGL reaches the street level, other than to say it's a result of the flow dynamics. The same model using Outlets instead of HEC-22 inlets shows the same bump.

1. The size of the discontinuity when the on-grade equations are replaced with on-sag equations when the inlet floods will be problem dependent. What the example shows however is that the results remain stable after the single point in time when the transition occurs.
2. Yes, the inlet flow, either as positive flow capture or negative backflow, is treated as lateral flow that is subtracted from the street node and added to the sewer node.
3. In the revised set of changes, a sewer capture node is always treated as if it has unlimited depth regardless of what the user assigned to it.
4. As described in the Inlets Tutorial, for grate inlets the depth dividing on-sag weir flow from orifice flow is 1.79 * Ao / Lw where Ao is the open area of the grate and Lw = L + 2W with L = grate length and W = grate width.

I was able to get rid of the discontinuity when on-sag equations replace on-grade ones. As long as the sewer HGL is above the street invert but below the street HGL we set the capture flow to the smaller of the on-grade (flow-based) value and the on-sag (depth-based) value. The results for the second example containing on-grade grate inlets now look as follows:

I pushed the code changes (to only two files) that implement the improved way of handling inlet submergence to a new branch named inlet_improvement. I leave it up to the project maintainers to decide if and when they wish to merge it into develop.

@LRossman,

I am not sure I understand what you've done. You say you were able to get rid of the oscillations by not letting the sewer node surcharge. Did you set the rim high enough that the HGL doesn't exceed it, or are you capping the HGL at the rim elevation? Capping the sewer HGL was one of the things I was wanting to avoid, but that doesn't seem like what you've done. The graph above shows the sewer HGL going above 10.14, which was the rim in my example and I think is the one you're using. In any case, these changes look very helpful.

The tutorial may need to be updated to make the necessary configuration clear if the sewer rim needs to be set higher than the expected max HGL. Or maybe SWMM could just raise the rim for the sewer node of an inlet to prevent surcharging, and provide a message telling what it is doing.

I hope the project maintainers agree with your changes and this gets into the the develop branch.
Thanks!

By "sewer capture nodes are not allowed to surcharge" I only meant that they are not subject to using the Surcharge Algorithm to compute their HGL once their connecting pipes are full. Instead they are treated using the normal depth updating formula (depth change = (inflow - outflow) * time step / surface area) where the depth (or HGL) is not limited by any maximum value. If at some point the sewer HGL gets high enough the resulting backflow onto the street could cause the street node to flood (overtop the height of the street and its backing).

Also with this revised approach the user-supplied values for the sewer node's full depth and surcharge depth are ignored. The only sewer node parameter that matters is its invert. The revised flow exchange calculation only kicks in when the sewer HGL exceeds the street node's invert elevation.

I agree that the Inlet Tutorial, as well as the Hydraulics Reference Manual - Addendum, need to be updated to reflect the change in how two-way exchange through an inlet is computed. But that documentation is maintained separately by EPA outside of this GitHub project.

This is certainly something to consider for adoption/adaptation in the future. While the use of the on-sag equations for backflows appears to be stable, I am still stuck on how the HEC-22 equations (and discharge coefficients) apply for instances where there is negative gradient between the inlet node and sewer HGLs. The documentation seems to be silent on this. Additionally, as others have noted here, the on-grade equation assumes no tailwater. While the errors might be small when the HEC-22 equations are applied in the manner implemented here, it will be important to test and convey these caveats in the documentation. I am partial to the use of different rating curves (i.e., either orifice or weir equations) as described in the article shared here and as NandanaPerera indicated, depending on the relative differences in elevation between the inlet node/street hgl, sewer hgl, and orifice invert and will be evaluating them for inclusion with this work to provide more flexibility. The article highlights the differences in discharge coefficients for different configurations, which seem significant to me (see Table 3). Thankfully, the article provides the experimental data, which could be used to evaluate the performance of different formulations in SWMM.

Our role at the EPA ORD is not only to maintain SWMM, but to continue to evaluate and rigorously review contributions, as well as advance new formulations to keep SWMM the useful tool it has been for all. There is a lot of interest in this type of coupling as folks seek to couple 2D models to SWMM and providing this flexibility would be very useful.