Navigation

As with all of Clawpack, this code is provided as a research
and teaching tool with no guarantee of suitability for any particular
purpose, and no liability on the part of the authors. See the
License for more details.

This is a brief outline of how to set up and run GeoClaw to model a real
event, with pointers to various useful data sources.

As always, the best way to get started is to copy a working example and
modify it to do what you want. We’ll start with the example in
$CLAW/apps/tsunami/chile2010 of Clawpack 4.6.

Copy this directory somewhere new with an appropriate name.

As an example we will convert this to a code modeling the Great Tohoku
Tsunami of 11 March 2011, and will assume an environment variable has been
set so that $TOHOKU points to the directory. This is easily done by going
into this directory and typing (at the Unix prompt $):

You need one or more files that contain both bathymetry and topography on
a single rectangular grid of points (generally in lat-long coordinates).
Bathymetry is underwater topography. Here (and in the code) we refer to
both as topo. In general these files have negative values of z to
indicate distance below sea level for bathymetry, and positive values of z
to indicate height above sea level on shore. But some files have these
switched. See Topography data for more details on the formats GeoClaw can
handle.

You probably need two types of topo files: fairly coarse resolution
over a large area of an ocean, and finer scale over one or more small
regions: those where you want to model inundation and perhaps also
for the source region where the tsunami was generated.

Coarse-scale topo can be obtained from various on-line databases. The
easiest is the NGDC GEODAS Design-a-grid
website. Simply type in the latitude and longitude of the edges of the
region you need.

Choose the ETOPO 1-minute Global Relief database and then select the grid
resolution you want.

Typically 4 arc-minute or even 10-minute
resolution is sufficient for tsunami propagation
across the ocean. Recall that 1 degree of latitude is 111 km and 1 degree
of longitude is about the same at the equator, so 4 minutes is roughly 7.5 km.
You can also select 1- or 2-minute data.

Finer-scale topo for much of the US coast is also available from this
website; select the “US Coastal Relief Model Grids” database.

To get an idea of what region you need to get topo, it’s often easiest to
use Google Earth, which shows latitude and longitude.

For the Tohoku event, we’ll use 10-minute topo over the region
from 115E to 30W and from 15N to 50N, covering part of the north Pacific.
Type these coordinates into Design-a-grid and choose the 10-minute grid and
the ASCII Raster format. It should tell you this will create a grid with
211 latitude cells and 571 longitude cells. (Points would be more accurate
than cells, since these are equally spaced
grid points including the end points in each direction.)

Select ASCII Raster Format (with header).

Give your grid the name npacific and then click “Submit”.

On the next page click on “Compress and Retrieve Your Grid”. You do not
need to check any of the boxes on this page.

On the next page click on “Retrieve Compressed File”.

This should save a gzipped tar-file called npacific-1257.tgz (the number
may be different).

The next 211 lines each consist of 571 values, the topo value going along
one particular latitude. The first line is at northernmost latitude
. The last line is at the
southernmost latitude 15. On each lines the values correspond to z at
points going from west to east, from longitude 115 to .
Note that 210E is the same as 150W. In GeoClaw the computational domain
will go from xlower = 115 to xupper = 210.

This file is almost in the form required by GeoClaw (with topotype = 3
as described at Topography data). The only problem is that GeoClaw wants the
numbers to appear first on the header lines, so you can delete the words
before the numbers (which aren’t needed), or move them to the end of the
line for future reference. There’s a Python script available if you have
Clawpack installed:

Various other attributes of a TopoPlotData object
can also be set. Here are the default values:

topotype=3cmap=None# set automaticallycmax=100.cmin=-4000.climits=Nonefigno=200addcolorbar=Falseaddcontour=Falsecontour_levels=[0,0]xlimits=Noneylimits=Nonecoarsen=1imshow=Truegridedges_show=Trueprint_fname=True

Setting coarsen to an integer greater than 1 coarsens the grid by that
factor in each direction. Setting imshow = False causes pcolor to be
used instead, which takes longer to plot but may look nicer.

We have specified two topo files. Each file has topotype 3 and we are
allowing at most 3 levels of AMR in the regions covered by each file. Later
we will see how to allow more levels in specific regions.

We also need to specify how the seafloor moves, which generates the tsunami.
This is specified to GeoClaw by providing a dtopo file as described
further in the section Topography data. This is a file with a similar structure
to a topo file but gives the displacement of the topo over some rectangular
grid, possibly at a sequence of different times.

Often earthquake data is specified in the form of a set of fault
parameters that describe the slip along a fault plane of some finite size
at some depth below the seafloor. A single earthquake may be described by a
collection of such fault planes. All of this subsurface slip must be
combined to generate the resulting seafloor motion. Ideally this would be
done by solving elastic wave equations in the three-dimensional earth,
taking into acount the spatially-varying elastic parameters and the
irregularity of the seafloor.

In practice, the Okada model is often used to translate slip along one
small fault plane into motion of the seafloor. This is essentially a Greens
function solution to the problem of a point dislocation in an elastic half
space, so it assumes the region of slip is small, the elastic parameters in
the earth are constant, and the seafloor is flat. This may not be a great
approximation, but given the uncertainty in the true elastic constants and
the actual slip in an earthquake, it is generally considered to be accurate
enough.

In GeoClaw there are some Python tools in
$CLAW/python/pyclaw/geotools/okada.py for applying the Okada model and
creating dtopo files from given source parameters.

This is a 450 km by 100 km fault plane with the length oriented at 16
degrees from north (the Strike_Direction). The fault plane is not
horizontal but instead dips at 14 degrees from horizontal along the axis
oriented with the length. The slip along this plane has a magnitude of 15 m
(the Dislocation) and the slip is in the direction 104 degrees from the
strike direction (the Slip_Angle, usually called the rake).

The fault plane is 35 km below the surface.

The last 6 lines specify the grid where the seafloor displacement should be
specified in the resulting dtopo file. In this a 100 by 100 grid covering
the region specified by the last four values.

Note that we are forcing 3 levels of refinement in the region covered by the
fault at the initial time. This value should be chosen to
insure that the fault region has reasonable resolution. (If fewer than 3
levels of refinement are used, i.e. mxnext < 3, then this will insure that
as many levels as available are used in this region.)

Note: Dynamic fault motion, in which the dtopo file contains
time-dependent displacements dz, is also supported. Need to document.

Note that geodaa.gauges is initialized to an empty list and then a list
has been appended that specifies a gauge numbered 32412 at longitude -86.392
and latitude -17.975. This is the location of DART buoy 32412 off the coast
of Chile. The values of t1 and t2 specified means that this gauge data
will be output for all times.

This location is not in our new computational domain, so this line can be
deleted. We might want to add one or more lines corresponding to the
locations of DART buoys or tide gauges for the new computation. Tide gauges
are generally in shallow water and we would need much finer bathymetry than
we are using to resolve the flow near a tide gauge.

Note that gauge output is only requested after time
t1 = 3600*7 seconds since the tsunami doesn’t reach this
gauge until more than 7 hours after the earthquake (which could be
determined by first doing a coarse grid simulation).