1
$\begingroup$

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?

$\endgroup$
  • $\begingroup$ 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? $\endgroup$ – Kyle Mandli Nov 2 '20 at 12:57
  • $\begingroup$ 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. $\endgroup$ – Emil Nov 2 '20 at 19:19
1
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ 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 /\/\. $\endgroup$ – Emil Nov 2 '20 at 19:57
  • $\begingroup$ 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". $\endgroup$ – Bill Barth Nov 2 '20 at 20:02
  • 1
    $\begingroup$ I think the velocity usually goes crazy first, then the wave patterns follow. Thank you, will search after "spurious oscillations". $\endgroup$ – Emil Nov 2 '20 at 20:03
  • 1
    $\begingroup$ 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. $\endgroup$ – Emil Nov 2 '20 at 20:10
  • 1
    $\begingroup$ 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. $\endgroup$ – Bill Barth Nov 2 '20 at 20:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.