# Where could error terms that blow up in SWE come from?

I have been working on a solver for shallow water equations with reflective boundary conditions. I have found that it diverges very fast. As a workaround I noticed yesterday that if I smooth the momentum (water column height * velocity) field as post processing in each step, the solution no longer blows up. So it seems I have some high frequency error terms appearing somewhere without the smoothing? Where do they usually come from?

• My first guess would be a shock (hydraulic jump) but without more context it is difficult to tell. Can you provide the initial condition and more details regarding your discretization? Nov 2, 2020 at 12:57
• I draw the bottom and the water with my mouse and set the velocity to the same value everywhere. If the bottom is U-shaped I have problems with negative depths, and need to smooth and redistribute the depths while keeping the global amount constant. If the bottom is straight I instead need to smooth the momentum, at least with reflective boundary conditions. I still change my code almost every day so maybe I should wait with updates until my code has "settled" a bit.
– Emil
Nov 2, 2020 at 19:19

Have you plotted the solution using a visualization package or just a cut through the middle of your domain? Sometimes just looking at the solution you're generating will give you an insight into where it's arising from. Based on your description, I'd say there's a mistake in your implementation of your boundary condition.

ETA: The last sentence is probably wrong, and to recap our conversation in the comments and to amplify Gresho & Lee's pithy phrase "the Wiggles are Telling You Something": Even if you haven't used the Galerkin FEM to discretize this, the method is mathematically equivalent to several FVMs and FDMs out there, depending on the quadrature rule used, and so shows similar pathologies if you don't have enough mesh in the boundary layers.

• I have only attempted 1D yet. It is a bit different depending on my initial conditions, but sometimes a distinct V\ shape shows up somewhere in the domain that just grows and grows. It happens more often if I draw cartoony waves like /\/\.
– Emil
Nov 2, 2020 at 19:57
• Grows and grows as the local velocity grows or the elements size grows and grows or one of the coefficients shrinks and shrinks? Sounds like you have so-called "spurious oscillations". Nov 2, 2020 at 20:02
• I think the velocity usually goes crazy first, then the wave patterns follow. Thank you, will search after "spurious oscillations".
– Emil
Nov 2, 2020 at 20:03
• At least that is how it has looked in my latest attempts. It is a little bit harder to trigger after I improved how I calculate dt to uphold the cfl condition, but "spikey" waves seem to be especially hard for my solver.
– Emil
Nov 2, 2020 at 20:10
• It's not a programming or mathematical mistake, it's the nature of the problem. The cell Peclet condition (something else to include in searches) is violated, and your method loses the ability to maintain unwiggliness (my word). Other numerical methods (like your non-linear solver) really hate these "solutions" as inputs because they are now even further from the true solution than a smoother function would be. It's all uphill work from there for them. Nov 2, 2020 at 20:15