Routing to the reporting time step to eliminate interpolation

[cbuahin]

Does anyone see any issues with adjusting the SWMM code to route to the exact reporting timestep to eliminate the interpolation that is currently done to ensure results are produced at the requested timestep?

[MitchHeineman]

I doubt I have anything useful to contribute to the discussion, and expect my answer would be yes if I did understand, but for the sake of ignorant folks like me, what does "route to the reporting time step" mean?

[cbuahin]

I should have been more detailed with my question. When routing is turned on, SWMM uses the routing_getRoutingStep to compute the routingStep to march the model forward in time to the next nextRoutingTime. This routingStep can exceed the next reporting time, in which case, results written to the output file are linearly interpolated to the reporting step. What I am suggesting is to limit routing step to the next reporting step in such instances to eliminate the interpolation.

[dickinsonre]

Oh, in that case you have an excellent idea.

[bemcdonnell]

@cbuahin, I’m sure you already understand the following points but I’ll post them anyways.

PROS:

• you’d be getting the “real” result on the report time steps

CONS:

• adding time steps would be slower. Models with small report steps could experience double number of route steps
• this will change reporting model results. Many utilities using SWMM for consent decree work might have to adjust some reporting.
• No longer following the standard method inside SWMM to determine the next route step length
• we encountered this with swmm_stride when it first came out - occasionally we somehow destabilize the model when we add time steps. I think @karosc found some strange issue with it.

All that being said; I could see going either way :-)

[karosc]

What I am suggesting is to limit routing step to the next reporting step in such instances to eliminate the interpolation.

@bemcdonnell is correct, swmm_stride does do exactly this. Although it has nothing to do with reporting, swmm_stride cuts the computational routing step short so that model simulation halts exactly on the swmm_stride step. This is good for evaluating control assets in pyswmm while minimizing the back and forth between the C and python run times. However, @bemcdonnell and I have experienced some major changes to modeled outputs when using swmm_stride rather than swmm_step. @bemcdonnell initially noticed this because the model he was working with had some instabilities that were accentuated in his updated model results. I dug further into my modelling and found my results were also different (although less so).

Since in my experience the model routing time step is usually very small relative to reporting step, I personally don't see much utility in making sure the model simulation falls exactly on the reporting step other than satisfying my precision itch. However, if others see value in chasing that goal, I have one request: reproducibility across different reporting steps.

With the current implementation of swmm_stride, if I run a reasonably complex model with swmm_stride using 5, 10, 15, 30, and 60 minutes, each model run will have different results at t=60 minutes. I'm not exactly sure why, but I imagine it has something to do with each simulation cutting the routing step short at different times and in different numbers and consequently altering the solver convergence over the course of the simulation. From my perspective, I think the reporting time step should not affect results in the slightest. It'd be confusing to me if I was running my CSO model with a larger reporting timestep (e.g. to keep my out file smaller) and the total overflow volumes in the rpt file come out majorly different even though I didn't change any inputs or elements in my model.

Also, happy Thanks Giving all! I'd like to express how grateful I am that EPA and the SWMM modelling community have such a place to come together and talk technically about the solver source code and the future of the engine. Looking forward to the impending 5.3 and all future releases! 🙏🏻 🦃

[cbuahin]

Thanks for the thoughtful insights, folks! The iterative nature of the SWMM dynamic wave routing solver means that inevitably, the reported results will be different if the timestep values change from one simulation to another. Using the events definition option or the stride stepping option are ways in which the timesteps could change from one simulation to another. The goal will be to try to reduce those errors to within reasonable tolerances to deal with the reproducibility issue you have highlighted. Marching forward in time to the minimum of next reporting time step and the next routing time step is step in this direction by reducing errors from the linear interpolation approach used to generate the results. Another strategy I am experimenting with that is showing some promise is to gradually ramp up to or down from the current timestep to the newly computed computed one.

Happy thanksgiving!

[bemcdonnell]

@karosc, raises a very good point. If you change the reporting step, you’d be getting different results for the output since there would be differences in occurrences of a routing steps.

Happy Thanksgiving 🦃🍁😎

[dickinsonre]

i agree with this - Since in my experience the model routing time step is usually very small relative to reporting step, I personally don't see much utility in making sure the model simulation falls exactly on the reporting step other than satisfying my precision itch