Too many dt reductions

[Darrel Robertson]

Is it possible to just ignore this warning and keep going and not stop the calculation?

*** WARNING *** Courant number  =  0.6686D+02  is larger than input cfl_max =   0.7500D+00  on grid 179 level   1
 AMRCLAW: level  1  CFL = .669E+02  dt = 0.1858E+02  final t = 0.545574E+04
 **** Too many dt reductions ****
 **** Stopping calculation   ****

I was hoping someone knew some about GeoClaw stopping early because of "Too many dt reductions". In particular I noticed that the code is trying to run with a Courant number of 67! Unsurprisingly it is then taking too many dt reductions to get get down to a requested courant number of 0.75. Does anyone know why it is first trying a courant number so high, and how I might be able to get it to start at the requested courant number?

I am admittedly trying to do something less than ideal: I have a huge wave of much greater height than the local bathymetry, which is running up rugged natural terrain, and I've cranked the Manning friction way down, since I want to know that maximum possible extent of the run-in. While I've read that I could smooth the bathymetry, and I know increasing the seafloor friction works (because I've already run those cases), I was hoping for a fix not involving changing the physics. I don't care if I have to specify a small fixed timestep, or if the problem takes a long time to run, because it runs in a couple of hours and I could easily wait a couple of days.

Darrel.

[Kyle Mandli]

Hi Darrel,

The Courant number is based on what the speed of the waves are during the most recent time step so assumedly in this case a grid cell exhibited a speed that accelerated dramatically.  Since GeoClaw first computes the update and consequently the speeds the Courant number is only known during the update (although it does try to guess the speeds).  In essence then what happens is that it tries to reduce the Courant number based on that speed to reach the “desired CFL”, hence the dt reductions.  If the dt reductions do not work past a certain threshold you get the message you saw.

This can be caused by a number of things but I would first check to make sure that the simulation is not simply blowing up or there is some transition in depth of water, including a dry-state.  Given the description of your case I am wondering if perhaps the wave hit a large jump in topography?  Before waiting days though I would see if you can diagnose where/why the CFL jumps like that.

Kyle

--
You received this message because you are subscribed to the Google Groups "claw-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to claw-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/claw-users/abb4afe3-d6c8-43e1-a204-d2a1d1337864o%40googlegroups.com.

[Darrel Robertson]

Hi Kyle,

           I'm working on asteroid impact tsunamis on Mars (3 Billion years ago when we think there was an ocean there), so yes I have a large bore wave (shock at the front) travelling at hundreds of miles an hour running over dry land which includes other impact craters with large near vertical walls. I'm going to be encountering that type of problem in many places throughout the domain, hence my interest in just having it ignore the problem and keep running. Alternatively if there is a way that I could just specify the timestep to use at each AMR level (since I know the max wave speed and the resolution, I don't really need the code to calculate this for me).

Darrel.

To unsubscribe from this group and stop receiving emails from it, send an email to claw-...@googlegroups.com.

[Kyle Mandli]

Hi Darrel,

You can have tighter control over the time step for each level by turning off `variable_dt_refinement_ratios` although this just picks out the correct ratios of time refinement between levels so that may not help.  You can also set a direct coarse time step and hold that constant by turning off `dt_variable` and specifying the time step directly although I am not sure that you may  want to do this either.  In reality you may want to use regions and control the time step and level in time and space more carefully but there may be others on this list that have some ideas regarding what you are doing.  In any case you can take a look at some of the documentation and see what might fit your situation at

https://www.clawpack.org/setrun_amrclaw.html
https://www.clawpack.org/setrun_geoclaw.html

Kyle

To unsubscribe from this group and stop receiving emails from it, send an email to claw-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/claw-users/826b28a7-d89d-478e-9139-cd045b0773e7o%40googlegroups.com.

[Randall J LeVeque]

Hi Darryl,

Good to hear you've got GeoClaw sort of working at least!  Regarding setting the time step and turning off the variable time step option, you would also have to set 

  clawdata.cfl_max

to something larger than the Courant number you are seeing, or else it will abort when the Courant number is greater 1, which is normally the stability limit.    Of course if you set the time step so that CFL > 1 in other parts of the domain then it will definitely blow up.

But as Kyle says, it's not clear this will work very well.  Unfortunately we do sometimes run into issues with "too many dt reductions" when looking at big waves flowing over rough topography and you have a more extreme case than usual.  Often the problem goes away (in less extreme cases, anyway) if you can smooth out the topography a bit, or even just shift the grid very slightly (a fraction of the dx on the finest resolution grids) so that it averages the input topofiles slightly differently. 

This generally happens, I think, at the margins of the flow where there might be a cell just getting wet that has a large momentum value hu but a very small depth h, and then the velocity u = hu/h ends up very large.  The wave speeds are $u \pm \sqrt{gh}$ and the Courant number is based on this.  It seems like we should be able to fix up the code to deal with this situation, but in past attempts we haven't found a robust general fix that doesn't do the wrong thing elsewhere.

 - Randy

To view this discussion on the web visit https://groups.google.com/d/msgid/claw-users/56ced8c0-2b5e-4402-a0c3-d3cb0e50b59f%40Spark.

[berger Marsha]

concurring with others that you can't just turn it off or your code will blow up.

A few question to help diagnose and maybe suggest other solutions.  DO you know what level you are on when this happens? Does this happen right at the beginning of your calculation, or after many time steps?

We recently found a bug that we haven't had time to integrate it yet, but  in case it helps you I will separately email you.

Marsha

To view this discussion on the web visit https://groups.google.com/d/msgid/claw-users/CADwYU3KfaZ8OeU_K2XxvZnDwd-WvJp%3Di2_wgXNRw9D0a-OEu3A%40mail.gmail.com.

[Darrel Robertson]

Hi Marsha and Randy,

                                  Great to chat with you again. I'll assume you aren't coming out to Ames this summer! I'll check with exactly where and on what level it happens. In general it happens after many timesteps, roughly when the wave reaches shore which matched with what Kyle said about hitting dry states with large bathymetry changes, since it's littered with craters. Just for fun attached is a screenshot of the last output time before failure, at least in one case, and that scale on the left is in meters! In the meantime I'm going to try using a fixed dt as Kyle suggested. Fingers crossed! Short of that I may have to give up lowering the Manning friction so much, since it runs fine with the nominal value of 0.025.

Darrel.

Marsha

To view this discussion on the web visit https://groups.google.com/d/msgid/claw-users/826b28a7-d89d-478e-9139-cd045b0773e7o%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "claw-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to claw-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/claw-users/56ced8c0-2b5e-4402-a0c3-d3cb0e50b59f%40Spark.

--
You received this message because you are subscribed to the Google Groups "claw-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to claw-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/claw-users/CADwYU3KfaZ8OeU_K2XxvZnDwd-WvJp%3Di2_wgXNRw9D0a-OEu3A%40mail.gmail.com.

[Kyle Mandli]

That looks fun!

That also reminded me of someone who was trying to model a geyser on Mars.  Not sure what the context was I am afraid beyond Mars.

Kyle

To unsubscribe from this group and stop receiving emails from it, send an email to claw-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/claw-users/d75de3a0-4403-41bb-9bd7-59cdf82471eco%40googlegroups.com.

[Donna Calhoun]

Cool plot.  Is that Mars? 

I’ve been thinking about this dt issue as well recently, and have made comparisons using  both global time stepping and sub-cycling.  My experience is mostly with ForestClaw (an octree version of GeoClaw).   Short story : it isn’t clear (to me, at least) what to do about these large wave speeds!

(background, for others following) With global time stepping, the time step size (fixed for all grids, but allowed to vary from one step to the next), would  be governed by the finest grids in an idealized case (assuming constant u).  But in SWE, it is often governed by the coarsest levels, since that is where the wave speeds are the fastest. In this case, you would  typically end up with very small CFLs on finest level.  This may not be the end of the world, however, since accuracy on the coarsest levels may be less important (?).  

But a few places where the finest level grids have really large speeds can blow out the CFL everywhere. And then once the small step is taken (and it might be dramatically smaller), the next step will try to compensate and take a larger step.  But this could again blow out the CFL, forcing a small time the next time, and so on.  In ForestClaw, I retake a time step if the CFL exceeds 1, and I can mostly get over these rough spots. But when these large speeds are encountered on the finest levels, this can force virtually every step to be retaken, slowing down the code (painful to watch).   If I don’t retake the time step, and hope for the best, the code can blow up dramatically. 

I haven’t implemented the “dt to go” variable time ratios that GeoClaw has, but have tried a strategy in which I simply  switch from sub-cycling  to a global time step, suitable for one of the finer levels.  The idea is to start with a time step suitable for the coarsest levels, reduce this time step size on successive levels, up to a level where I switch, and then on that level and all finer levels, use a time step suitable for the level where I switch.  This generally reduces the number of steps taking on the finest levels. This, combined with retaking time steps seems to get over the “rough patches”.  I have thrown up my hands at trying something more sophisticated (:-)).  

I’ve attached a plot of what various CFLs. vs. grid sizes.  This plot compares idealized cases (constant u), and what happens with in an actual case (the Tohoku tsunami in this case, resolved down to 1/3 arc second).   ForestClaw runs on an octree grid, so the levels are powers of 2.   This was a more general case, before large wave speeds on the finest grids were encountered. 

-----------------------------------

Donna Calhoun
Associate Professor
Department of Mathematics, Mathematics Bldg 241A
Boise State University

1910 University Drive

Boise, ID 83725-1555

(208) 426-3386
http://math.boisestate.edu/~calhoun
-----------------------------------

To unsubscribe from this group and stop receiving emails from it, send an email to claw-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/claw-users/d75de3a0-4403-41bb-9bd7-59cdf82471eco%40googlegroups.com.
<Screen Shot 2020-06-12 at 10.53.54 AM.png>

[Randall J LeVeque]

Hi Darryl,

It is true that in general there are more potential stability issues with smaller Manning coefficients.  

The friction term has h to some power in the denominator, so it really helps to decelerate the flow

in cells with very small depth but large velocity.  The value 0.025 is what we normally use for

hazard modeling, and corresponds to bare gravelly earth.  Is Mars much smoother than that?

Marsha and I have a couple modifications you could try out.  I'll write to you separately about that

so as not to clutter up this thread for those not interested, but if we make progress I'll report back.

I did open a couple WIP PRs on the changes if others are interested in chiming in or trying them out...

  https://github.com/clawpack/geoclaw/pull/456

  https://github.com/clawpack/riemann/pull/159

 - Randy

To unsubscribe from this group and stop receiving emails from it, send an email to claw-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/claw-users/d75de3a0-4403-41bb-9bd7-59cdf82471eco%40googlegroups.com.

[Darrel Robertson]

Just in case anyone reads the thread, thought I'd post that Kyle's suggestion of using a constant timestep worked.  In setrun.py set clawdata.dt_variable = False and clawdata.dt_initial to a small number. It certainly wasn't as efficient as GeoClaw is with variable timesteps, but it did the trick of getting me an upper bound on the potential inundation, without crashing.  

Many thanks to everyone who helped me with this.

Darrel.

On Monday, June 15, 2020 at 3:08:50 PM UTC-7, Randall J. LeVeque wrote:

Hi Darrel,

To view this discussion on the web visit https://groups.google.com/d/msgid/claw-users/d75de3a0-4403-41bb-9bd7-59cdf82471eco%40googlegroups.com.

[Randall J LeVeque]

Thanks Darrel, good to know.  

 - Randy

To unsubscribe from this group and stop receiving emails from it, send an email to claw-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/claw-users/b4fed154-015b-4a44-878c-aa94d8529874o%40googlegroups.com.