View Full Version : Solving instabilities

David Wozniak
December 8, 2014, 02:18 AM

Especially in big models there are always the elements that cause convergence\volume balance problems, such as overflows, steep pipes, etc.
It seems that various modellers have various approach to same. Some ignore volume balance issues when less than 1%, some go up to 5% and some ignore them entirely and only try to solve the problem only when model fails.

What is your approach? what volume balance percentage do you consider acceptable?

Also when model fails some people try to tweak the Simulation Parameters and if that doesn't work they alternate the elements that fail even if these are properly defined.

Would you alternate the model elements even thought it might impact the simulation results?

Kristian Ravnkilde
December 8, 2014, 03:55 AM
Starting point - if the run completes, I count myself lucky! I have enough problems with sims that don't complete for one stupid reason or another to be too fussy abut the ones that do! Upping the number of halvings and iterations often helps. Failing that, it may be necessary to alter the network itself, but it's usually things like discharge coefficients rather than geometry. Pipes with no flow are a major problem - head nodes with no subcatchments, or spill pipes (adding a very small base flow can help). It's mostly something small and silly, and hard to find :(
Beyond that, I look at 5%+, and the nodes/ links with lots of fail counts and try to deal with them in the same way if there's time.
It's not just the result - unstable models run slowly even if they complete, which can waste a lot of human time as well.

Stewart Sargent NZ
December 9, 2014, 11:51 PM
I use 5% as absolute max Continuity Error
Also I look at some key components to see if the results make Engineering sense. (NO SUBSTITUTE for a reality check based on Engineering basics and experience.)
Also, look for Math Spikes in graphs - and wild fluctuations in HGL profile results

Reduce time step,
Make sure all forced main have: a FLAP V near the start, use DW or HW and have a sufficiently large SurchargeDepth.
[Also, it often seems better to use IDEAL pumps in the model (for stability) and optimise/evaluate pump & pumped main hydraulics with a customized spreadsheet model ( ie outside infoSWMM)]

Lower Tol and increase iterations/trials.

[I normally also use "Both" for normal-flow-limits and Variable Time Step]

Yes...I will tweak some elements if I have-too. Especially those which have the Highest Continuity Errors &/or show spikes in ReportMgr Grphs.

However for complex networks with discontinuities (like pumps going on & off), perfect results (fast, no spikes, v low Continuity error, and where summary tables/max values contain no wild-cards / spikes) are not very common.... sadly.

Basically, I find that I have to very suspicious and do lots-of-audits before I have confidence to reach firm engineering conclusions.

[I've been modelling for longer than some of you have been alive... <grin>.. but it really doesn't get any easier nor can one relax & take things at face value.
Powerful modelling tools just means you can make bigger mistakes... faster <grin> however ... you can also achieve some lofty goals .... but only by being very careful.

"Take care out there. May all your models converge and give sensible answers and nothing comes back to bite you."

Kristian Ravnkilde
December 10, 2014, 02:03 AM
Pump on and off delays are another good way to improve stability (30seconds seems to work well in InfoWorks, all flavours - and going back umpteen years to WASSP if we're being all nostalgic!) Stewart's right, reality checks are essential. Spikes and fluctuations are good indicators - look for silly max depth/ flow values in grid results, that don't necessarily show up in timestep results. A large number of low reversals on a river bank is another good pointer, but it doesn't always mean that the problem is with that bank or river reach. I find it's more often caused somewhere upstream in the 1D system and propagates downstream as in the butterfly effect until it finally causes something to fall over. The 2D system seems to be much more stable.