# 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.