Variable Friction Coefficient in GeoClaw

[Kyle Mandli]

Hi everyone,

My work using GeoClaw to model storm surge has come to a point where it appears that having a variable friction coefficient field is necessary to produce accurate surge run-ups.  Adding the variation in Manning's-N is easy in terms of how the source term is treated but specifying the field seems more difficult.  Here are a few strategies I have come up with:

1. Only allow variation in coefficients for land and sea.  This would work by looking at cells that were initially dry and initially wet and assigning a coefficient.  Since dry and wet regions have the possibility for the greatest difference in coefficients and this would be easy to handle for AMR (since the field is static), this would be the easiest path forward at this time.
2. Allow specification of regions where a modified coefficient can be applied.  These would rectangles where another coefficient would be used rather than some background value.  This method would be tricky to use due to complex coastlines.
3. Somehow tap into land use maps and build in a system that resembles what is done with bathymetry.

Ideally at least strategy 1 and 3 should be implemented.  I am not sure if strategy 2 would have much use but maybe people feel otherwise.  All of these approaches would store the coefficients in an aux array so the implementation other than the specification of the field is fairly straight forward.

Kyle

[David L George]

Kyle,

For the "straightforward" part of reading in aux values from
files---I've implemented something similar for debris flows, using a
variable friction coefficient, and other spatially variable
parameters, that are specified in files of the same format as
topography files, and read and stored in aux arrays much like
topography. The code for adding aux arrays in this fashion (for
geoclaw generally, not necessarily debris flows) exists on git hub
dlgeorge/geoclaw-4.x . There is an auxinit module and qinit module,
and modified qinit_geo and setaux_geo routines for initialization in
geoclaw/lib if you want to take a look. I can provide a setrun.py to
serve as an example. Of course, as you mention, you'd still need to
design the input files for n...but the code might serve as a starting
point.

Dave

> --
> You received this message because you are subscribed to the Google Groups
> "claw-dev" group.
> To post to this group, send email to claw...@googlegroups.com.
> To unsubscribe from this group, send email to
> claw-dev+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/claw-dev?hl=en.



--
----------------------------------------------------
David L George (dge...@usgs.gov)
Research Mathematician
U.S. Geological Survey
Cascades Volcano Observatory
1300 SE Cardinal Ct. #100
Vancouver, WA 98683
1-360-993-8932
-----------------------------------------------------

[Kyle Mandli]

I will take a look at what you have in there, sounds like this will make it easy to implement the 3rd option from my original email.

Kyle

[Randall J LeVeque]

Hi Kyle, David,

This is very timely -- just yesterday I was experimenting with different Manning coefficients for a site on the Washington coast where we're modeling inundation from a CSZ event.  I was surprised at how much difference changing n made on the inundation, and also in the distance the waves propagate into Gray's Harbor.  Since the area we're interested in is somewhat protected by trees it would be nice to be able to use a larger value in this region, but not in the Harbor.  The simple approach of basing n on B>0 or B<0 might be enough for this, and I notice that this would be quite easy to do since the aux arrays are passed into src2_geo.f and one only needs check the bathymetry at each point.  Rectangular regions probably wouldn't be useful for most practical problems.  Having spatially varying friction factors handled similar to the topo grids would be nice when more information is available, so I'll take a look at what Dave's done too.

 - Randy