Manning friction term

When using GeoClaw to model inundation, it is important to include an appropriate bottom friction term in the equations. This takes the form of a source term added to the right hand side of the momentum equations:

\((hu)_t + \cdots = -\gamma (hu),\)

\((hv)_t + \cdots = -\gamma (hv),\)

The form built into GeoClaw is the Manning formulation, in which \(\gamma\) is a function of the depth and momentum:

\(\gamma = \frac{gn^2\sqrt{(hu)^2 + (hv)^2}}{h^{7/3}}.\)

with \(g\) the gravitational constant and \(n\) the “Manning coefficient”. This is an empirical formula and the proper value of \(n\) to use depends on the roughness of the terrain or seabed, as shown for example in this table. Often for generic tsunami modeling, the constant value \(n=0.025\) is used. An enhancement of GeoClaw planned for the future is to allow spatially-varying Manning coefficient.

The friction term is only applied in regions where the depth is below a threshold specified by friction_depth (see Specifying GeoClaw parameters in setrun.py).

New in 5.0: A list of Manning coefficients can be specifed to be used in different regions based on the topography B, e.g. one value offshore and a different value onshore. See General geo parameters.

Warning

Changing the Manning coefficient can have a significant effect on the extent of inundation and runup. If GeoClaw (or any other code) is used for estimating real-world hazards, users should think carefully about chosing an appropriate value, and may want to run sensitivity studies. A smaller value of \(n\) (less friction) will generally lead to greater inundation.

Warning

A bug was recently discovered in GeoClaw that was corrected in Version 4.6.3: The exponent (7/3) was used in the Fortran code, which evaluates as 2 in integer arithmetic rather than 2.3333. This has now been corrected by writing it as (7.d0/3.d0). This can make a difference in the extent of inundation and runup. Given the uncertainty in the proper value of \(n\) to use and the inadequacy of using the same value everywhere, the effect of this bug on the resulting accuracy was probably small, but users may want to test this.