Notes on Configuring BINDER_EW: Earthworm's Phase Associator

by Lynn Dietz, July 2002
  Given a list of P-wave arrival times, a set of station locations and a
simple velocity model, binder's job is to identify the smallest set of
hypocenters that could have produced the current list of arrival times.
With each new pick, binder tries to:

  1) associate that arrival to an active event, or

  2) identify a new event by stacking the back-projections of P-wave
     travel times on a space-time grid to find a likely source (hypocenter)
     for recent unassociated picks.

  Sounds simple, right?  Well, there are a lot of configurable parameters
that control exactly how binder will go about this task.  I'll try
to explain the basic steps I go thru when I'm setting up binder for the
first time in a new region of interest.  And I'll give a few details
about how binder goes about its tasks (refer to this flowchart as we go).


Getting Started: Earthworm Setup & Network Definition
-----------------------------------------------------
The three most basic things binder needs to know are:
1. Where should it get P-wave arrivals (picks) to work on?
2. What stations are being picked and where are they?
3. What's the velocity structure like?

1. P-wave arrivals:
  Two commands in binder's configuration file tell it where it should get
the P-wave arrivals to work on.  The "RingName" command specifies which
Earthworm transport ring (a shared memory region) to read from.  Make sure
that this is the same ring into which pick_ew is writing its output.  Also,
if you're importing picks from another source and want binder to use them,
make sure you are placing them in this ring as well.
  The "GetPicksFrom" command specifies the installation id and module id of
the TYPE_PICK2K messages that binder will operate on.  Specific id's or
wildcards can be used for either or both of these arguments.  Note: both
binder_ew and eqproc should be set to listen to the same pick source(s)!

2. Station List:
  Binder expects the network's station list to be in a file in Hypoinverse
station format; it gets the name of the file from the "site_file" command.
Of all the fields in this file, the only ones used by binder are the
station codes (5-letter site code, 2-letter network code, 3-letter component
code) and the station latitude and longitude.  A quirk of this file is that
all lats and lons are listed as positive numbers; a letter is used to denote
N,S,E,W, with blanks interpreted as N and W.  As binder reads the file, it
converts lat and lon to decimal degrees with N and E being positive.  If a
site has multiple components, each component should be listed on its own line
in the station file. As of Earthworm v4.0, binder treats each component
independently, so if multiple components at a site are picked, that site
will be weighted more heavily in stacks and locations than a single-component
site.
  Large networks (over 1000 channels) will have to use the "maxsite"
command to increase the number of stations that binder will input and use.
  Since binder works only on arrival times, it doesn't need to know anything
about instrument response or gain.

3. Velocity Model:
  Binder uses one simple velocity model to calculate travel times for the
entire region of interest.  If the velocity structure varies greatly in
your region, make sure you give binder a decent average model.  This
velocity model is specified with a series of "lay" commands in the
configuration file, listed in order of increasing depth.  The velocities
in each layer are constant, and should increase with depth (no low velocity
zones, please).  Pay attention to the order of the arguments of the
lay command.  It should be "lay depth(km) velocity(km/s)".  If you get
depth and velocity swapped, binder won't do much of anything.
  Binder also uses one P/S velocity ratio; the default is 1.72, but it can
be changed by using the "psratio" command in the configuration file.


Stacking - The Guts of Binder
-----------------------------
  How does binder identify new earthquakes, or what does "stacking" mean?
Binder needs to find the likely origin, in space and time, of a group of
P-wave arrivals. Given a single P-wave arrival (call it the "initiating pick"),
binder considers the entire volume of the earth is a potential hypocenter.
The addition of a second P-wave arrival gives binder information on relative
timing; so it can narrow the field of possible hypocenters to a 3-dimensional
surface. To determine this surface, binder essentially takes the P-wave
travel-time curve, puts the curve's origin at the station's location, flips
the curve upside down (about a horizontal axis), shifts it in depth
considering the relative timing between the two picks, and spins the curve
around a vertical axis.  This creates a conic-like surface (somewhat like a
hollyhock flower opening down) that passes through all possible hypocenters
which could have produced that second arrival, given the timing of the first.
Binder calculates the "hollyhock" of potential hypocenters for each subsequent
pick in the same manner, always using to the initiating pick's time as the
reference time.  When the "hollyhocks" from two arrivals overlap, you get a
line of potential hypocenters that is consistent with both picks and the
initiating pick. The point where three or more individual "hollyhocks"
intersect is a unique hypocenter (stacking location) that can explain all
of those arrivals, including the initiating pick.  At this stage, with four
P-wave arrival times, binder has successfully "stacked" a new "active event."
It associates (or binds) these four picks into an event and passes those
picks and the stacking location to its simple L1 locator for further
processing.

  Instead of considering an infinite number of possible hypocenters, binder
discretizes the problem by using a stacking grid.  Within its boundaries,
the grid contains uniformly-sized cubic cells.  Only the center point of
each grid cell is considered a possible hypocenter in the stacking process
described above. Below I'll describe the parameters that are used to define
the stacking grid and control the stacking process.

  While setting up the stacking grid, I find it very useful to look at a
map of the seismic network and historic seismicity in the region of interest.
The things I look for are:

  + seismic network: overall distribution & station spacing
  + seismicity: latitude, longitude & depth ranges


Stacking Grid Boundaries:
The boundaries of the stacking grid are set with three commands:
  "grdlat" (latitude range in decimal degrees, positive = north),
  "grdlon" (longitude range in decimal degrees, positive = east),
  "grdz"   (depth range in kilometers, positive = down).
Reviewing the map of historic seismicity may help in setting the stacking
grid boundaries.  Binder can only identify new hypocenters that lie within
these boundaries, so they should include the entire volume of interest (ie,
wherever you expect or hope to see earthquakes).  Also, all of your seismic
stations should lie within the grid boundaries.

Stacking Grid Cell Size:
  Now you must decide how big each cell within the grid will be. Each cell
is a cube, and its side-length (in kilometers) is set with the "dspace"
command. That map may be useful again; hopefully, you can set dspace so that
only one station falls within each grid cell. The more stations that fall
within one cell, the more trouble binder will have in "focusing" the stack
(when 2 stations are in the same grid cell, their "hollyhocks" will overlap
100%, which doesn't do much good for resolving potential hypocenters). Then
again, you don't want to make the cell size too small, or binder will have
a lot more computations to do.  So there's a tradeoff here.  FYI, the
Northern California Seismic Network uses a grid cell size of 4 km.

Stacking Distance Constraints:
  When stacking each additional pick, binder considers possible hypocenters
for that arrival within a limited distance of the station, not the entire
stacking grid.  The stacking distance is controlled by the "rstack" command.
Binder computes each pick's "hollyhock" within its stacking volume. The
stacking volume includes the entire depth range of the stacking grid, but in
map view the stacking volume is a square centered on the station location,
extending rstack kilometers in each horizontal direction (the square's sides
are 2*rstack km long). To avoid roundoff problems, rstack should be a multiple
of the grid-cell dimension, dspace.
  Once again, the network map will be handy for choosing an appropriate rstack.
Consider your network's station spacing and distribution - phases from stations
that are more than 2*rstack km apart will not stack together other because
their stacking volumes will not overlap at all.  Also consider your expected
seismicity patterns - binder can only identify new hypocenters where the
stacking volumes of 4 or more stations overlap.  Make sure that your expected
seismicity falls within such a region, increasing rstack if necessary.  After
an event is stacked, binder's L1 locator may move the hypocenter beyond the
stacking volume, and possibly even outside the stacking grid boundaries.
But, you have to stack it first!

Stacking and Time Resolution:
  Binder includes a time-resolution factor ("tstack" command) in calculating
the set of all possible hypocenters ("the hollyhock") for each pick.  This
time factor controls the thickness of the hollyhock petals. Increasing tstack
could increase the number of grid cells each pick's hollyhock. As a first
approximation, tstack should be at least the number of seconds it takes for
a P-wave to cross a grid cell of dspace km.

Pre-Stack Glitch Filtering:
  A glitch is a group of coincident arrivals often caused by noisy telemetry.
For the purposes of this filter, a glitch is defined as a certain number of
picks (m) occurring in a given number of seconds (x). The values of both m
and x are configurable with the "define_glitch" command (the default definition
is 4 picks within 0.035 seconds).  This glitch filter was added to the stacking
portion of binder to prevent it from creating new events from a group of picks
having nearly identical arrival times. Picks that are flagged as belonging to
a "glitch" are not used in summing the stack, but may later be associated with
an event.  If you want to turn off pre-stack glitch filtering (ie, to make
binder stack every pick), set m to zero (example "define_glitch 0 0.0").

Summing the Stack - Stacking Weights & Event Thresholds:
  OK, here we go. Binder gets a new pick and it doesn't associate with any
of its currently active hypocenters.  Binder will now attempt a stack with
that new pick as the "initiating pick".  First it gathers up all recent
unassociated picks (binder keeps track of the last 1000 picks it has
processed, but it only tries to stack with a limited number, set with the
"stack" command).  Then it reviews that list of unassociated picks to see
if there are any glitches (see section above). Any picks that belong to a
glitch will be eliminated from the stacking process. If the initiating pick
itself belongs to a glitch, binder will not attempt a stack at all.
  Now let's talk about stacking weights. The stacking weight of each
pick is based on the quality assigned to that pick by the pick_ew process.
By default, binder stacks only quality=0 picks with a weight=1. Using "grid_wt"
commands, you can include other quality picks in the stacking process. You could
also give high-quality picks greater weight in the stack than low-quality
picks. This differential weighting is especially useful for large networks like
NCSN; we want to avoid generating events based on a few low-quality picks, but
will accept an event that's based on a larger number of low-quality picks (or
a combination of high-and low-quality picks). For small networks (10s of stations),
I would suggest using equal stacking weight for all quality picks.  Just be
sure to use a "grid_wt" command for each pick quality (including 0) that you
want binder to include in the stack.
  The "grid_wt_instid" is a new twist (June 2002) to the stack weighting scheme.
It allows you to set the stacking weight of a pick based on its pick quality
and its installation_id.  For example, this allows a user to weight a quality
2 pick from one installation differently than a quality 2 pick from a different
installation.  This is only useful for networks that exchange pick data with
other institutions.
  To sum the stack, each grid cell is assigned a "hit count" to keep track of
how many picks that cell is a potential hypocenter for (how many "hollyhocks"
that cell is a member of). During the stack, binder only keeps track of the
grid cells within the initiating pick's stacking volume. At the beginning of a
stack, the hit count of every cell in the initiating pick's stacking volume is
set to initiating pick's stack weight.  Then binder calculates the hollyhock
for each additional pick; for each grid cell that lies within the new pick's
hollyhock and the initiating pick's stacking volume, the hit count in
incremented by the stack weight of the new pick.
  After binder sums the stack using all picks in its short list, it reviews
the hit counts of all the grid cells. Binder prepares a list of cells that
share the maximum hit value and the same minimum distance to the initiating
phase. Binder declares a new hypocenter from the stack only if the maximum
hit count is greater than or equal to an event threshold value (set with the
"thresh" command) and the number of cells in the list is less than an
event focus value (set with the "focus" command). The trial hypocenter for
the declared event is calculated by averaging the center positions of all
the cells in the maximum-hit-count list.  Each pick that contributed to that
maximum hit count is associated with the new event.
  It's very important that at least 4 phases contribute to declaration of a
newly stacked earthquake.  If all picks are being weighted equally (no
"grid_wt" commands were used), the event threshold ("thresh" command)should
be set to 4 or higher. If differential stacking weights are being used, the
event threshold should be greater than 3 times the maximum stacking weight
specified by "grid_wt" commands.
  Finding the optimum value for the event focus value ("focus" command)
may require considerable experimentation for any specific network. The
optimal value will depend somewhat on the stacking grid granularity ("dspace"
command). Since the trial hypocenter is calculated by averaging the center
positions of all the cells in the maximum-count list, a larger focus threshold
will increase the probability of a poor starting location (which has its own
attendant problems). A smaller focus value, however, will tend to reject
distant events.

Stacking and Eventids:
  Every time binder identifies a new event with a stack, it assigns
an eventid to it.  Binder uses this eventid in its internal bookkeeping
to know which picks are associated with which events.  It also writes
the eventid in the TYPE_LINK and TYPE_QUAKE2K messages that it outputs,
so that downstream modules (eqproc, eqprelim) can also do their own
bookkeeping.
  Binder keeps track of the next available eventid in a file called
"quake_id.d" that is written in the EW_PARAMS directory.  The actual
command written to the file is the "next_id quakeid" command. This file
is read once on startup (actually, the first eventid used after startup
is quakeid+1), and is updated after every new event is stacked.  To ensure
sequential, non-duplicated eventids between runs, binder's configuration
file must contain the command "@quake_id.d". If this command is omitted,
event sequence numbers will be issued beginning at 1 each time binder
is restarted.
  You should never see the same eventid twice, but you may see gaps.
On startup, binder always skips one eventid (just in case it died in the
middle of writing the quake_id.d file), and it may kill events for various
reasons.  Also, the eventids may appear downstream out of numerical order.
Sometimes a smaller event that occured after (thus had a higher eventid)
a large one will finish first.


Associating New Phases with Active Earthquakes
----------------------------------------------
  Whenever binder retreives a new pick, the first thing it does is try
to associate the arrival time with one of its currently active earthquakes.
Even though the Earthworm pick_ew module supposedly only picks P-wave
arrivals, binder assumes the pick is an unknown phase during the association
process. Knowing each event's origin time and location (binder keeps track of
the most recent 100 hypocenters), the station location, and the velocity
structure, binder calculates the arrival times of each event's possible
phases (P, Pg, Pn, S, Sg, Sn) at that site. Then it compares the actual
arrival time to the calculated times to find the residuals. Any phase with
a residual within the configured residual-tolerance qualifies that pick to
be associated with that event as that phase. The phase having the lowest
residual value (within the residual-tolerance) wins!  Binder associates
or links the pick with the event with the winning phase, then it hands that
event to the L1 locator for further processing.  If no phase has a residual
within the residual-tolerance, binder performs a stack with the new pick as
the initiating pick (see stacking section above).

Association and Time Constraints:
  As I mentioned above, binder keeps track of the 100 most recent hypocenters.
When it tries to associate a new pick, it doesn't actually consider all of
those hypocenters as possible sources for the pick.  Instead, it considers
only those hypocenters where the pick time is within a given time range of
the origin time.  The "t_dif tmin tmax" command defines the acceptable time
range (tmin, tmax are in seconds). If the pick time is earlier than
(origintime + tmin) or later than (origintime + tmax) for a given event,
binder will not attempt to associate that pick with that event.

Association and Distance Constraints:
   Binder keeps track of the average epicentral distance (rAvg) of all phases
associated with each active hypocenter in its list. Before binder attempts
to associate a new pick with a given hypocenter, it compares the epicentral
distance of that station with a cutoff distance based on the rAvg value for
that hypocenter. If the new pick's epicentral distance is greater than the
cutoff distance, binder will not attempt to associate the new pick with
that hypocenter. The cutoff distance is calculated by rAvg*rAvg_Factor,
where rAvg_Factor is a constant (default value = 10.0) that can be set with
the "rAvg_Factor" command.  This distance cutoff is important in cases where
two earthquakes occur with seconds of one another in different parts of the
network.  It also keeps an event from being contaminated by distant spurious
noise picks which happen to match the event's travel time curve.

Configuring the Travel-time Residual Tolerance Function:
  Whether or not a given phase is associated with, culled from, or scavenged
for a given event is determined by how closely its arrival time fits the
predicted arrival time for the event (ie, how large its travel-time residual
is). The overall maximum-allowed travel-time residual (residual tolerance
or restpr) for a pick to be associated with a given active hypocenter is
composed of three terms:

   restpr = dist-taper + res1_OT + res2_OT

The first term (dist-taper) is based on the distance of the current pick to
the hypocenter (controlled with the "taper" commands) and two remaining
terms (res1_OT and res2_OT, controlled with the "taper_OT" command) are based
on the quality of the event's location.  All of these terms are configurable
to allow you to widen the residual tolerance for more distant picks and/or
for more poorly located earthquakes.

Residual Tolerance Distance Term, dist-taper:
  The distance-dependent term of residual tolerance, dist-taper, is controlled
with the "taper r resmax" command, where r is the epicentral distance (km) and
resmax is the value of the dist-taper term (seconds). Multiple taper commands
(up to 100) can be used, in order of increasing r, to define the dist-taper
term of the tolerance function. Between the distances specified, the value of
the dist-taper term changes linearly between corresponding resmax values. For
distances less than the lowest value specified, the dist-taper term is constant
at the resmax value for the smallest distance; for distances exceeding the
maximum specified, the dist-taper term is constant at the resmax value set
for the maximum distance. If no "taper" commands are supplied, the dist-taper
term is a constant 1.0 sec for all distances.
  The dist-taper function defined by the "taper" commands also plays a role
in how a pick is weighted in the relocation process (see the distance-weight
factor in the "Relocation and Pick Weighting" section below).

Residual Tolerance Hypocentral Quality Terms, res1_OT and res2_OT:
  The "taper_OT OTconst1 OTconst2" sets two constants that are used to
calculate the hypocenter-quality terms of the maximum-allowed travel-time
residual, restpr. The thinking is, if your location is poor, you'll want to
accept a phase with a higher travel-time residual.  If no taper_OT command
is listed, the default values are OTconst1 = OTconst2 = 2.0.  To eliminate
the two hypocentral quality terms from the residual tolerance function,
set both constants to 0.0.

  The res1_OT term is based on event's rms residual and the number of phases
associated with the event.  Binder uses the first constant, OTconst1, in
calculating res1_OT for each hypocenter as follows:

   res1_OT = OTconst1 * rms * Npick_factor

   where  Npick_factor = 3.0                     when npick <= 4
                       = SQRT( npick/(npick-4) ) when npick  > 4

When the number of picks is small, the rms of the location is often quite
low, so the Npick_factor and OTconst1 will dominate the res1_OT term.
As the number of picks associated with the event increases, the
Npick_factor approaches 1, so the event rms and OTconst1 will dominate
the res1_OT term.

  The res2_OT term is based on the hypocentral distance to the nearest
station and the second constant, OTconst2.  Given the hypocentral (slant)
distance to the nearest station calculated by:

   s = SQRT( z**2 + dmin**2 )  where    z = hypocentral depth
                                     dmin = epicentral distance to
                                            nearest station

binder calculates the res2_OT tolerance term as follows:

   res2_OT = 0.0                     when s  < 1.0
           = OTconst2 * log10( s )   when s >= 1.0

The larger the minimum slant distance, the more unreliable the location,
and the larger this second residual taper term becomes.

  OK, so that describes the form of all three terms in the residual tolerance
function, but it doesn't really give you a clue as to what values to use for
your network. I think it's most important to set a reasonable distance taper
for your network based on how well your velocity model fits your arrival-time
data.  Hopefully, you already have some idea about that. The residual tolerance
can then be widened if necessary using the origin uncertainty terms. The
values of all three terms are printed in binder's logfile, so you may be
able to empirically settle on some parameters by studying those.


Binder's Simple Event Locator
-----------------------------
  After binder declares a new event from a stack, or after is associates
a new pick with an active event, it passes the event to its simple L1 locator
for further processing.  The locator takes a starting location and all the
phase data for the event, determines a weight factor for each phase in the
relocation, and performs a number of iterations to arrive at a new location.
Again, there are quite a few configurable parameters available to control the
locator, and I'll describe them below.

Intermittent Relocation:
  While binder's locator is simple, it can still be quite a CPU hog, especially
when a large number of phases are associated with the event.  Also, as the
number of associated phases grows, the hypocenter becomes more stable, and the
improvement in the location with each additional phase shrinks. Therefore,
we added the configuration command "locate_eq npick interval" to allow
intermittent relocation of an event. Instead of relocating after every single
new phase is associated, an earthquake with more than "npick" picks will
relocate with every additional "interval" picks associated. Up to 10 "locate_eq"
commands can be supplied (in order of increasing "npick" values) to set multiple
npick-break-points and location intervals.  An event with fewer picks than
the smallest "npick" value will locate after each additional pick is associated.
If no "locate_eq" commands are used, every event will be relocated after
each addition pick is associated.

Relocation and Pick Weighting - Phase Type, Pick Quality, and Distance:
  The overall weight of a pick in the location process is the product of three
weighting factors: a phase-weight, a pick-quality-weight and a distance-weight.

     wt = phase-weight * pick-quality-weight * distance-weight

  The phase-weight is based on the phase assigned to the pick by binder, in
conjuction with the "ph" commands listed in the configuration file. Use
one "ph phase weight" command to assign a "weight" (any number from 0.0 to
1.0, inclusive) for each "phase" (any of the strings P,S,Pg,Sg,Pn,Pg) that
you want binder to use in the location.  If at least one "ph" command is
supplied, other phases that were not listed in a "ph" command receive a
phase-weight of 0.0 (ie, they won't be weighted in the location process).
If no "ph" commands are used, all phases receive a phase-weight of 1.0.
  The pick-quality-weight is based on the pick-quality assigned by pick_ew,
in conjuction with the "wt" commands listed in binder's configuration file.
Use one "wt quality weight" command to assign a "weight" (any number from 0.0
to 1.0, inclusive) to any "quality" (0,1,2,3 or 4) of pick that you want
binder to use in the location.  If at least one "wt" command is supplied,
other pick-qualities that were not listed in a "wt" command receive a pick-
quality-weight of 0.0 (ie, they won't be weighted in the location process).
If no "wt" commands are used, all quality picks receive a pick-quality-weight
of 1.0.
  The distance-weight is based on the epicentral distance of the station
from the current starting location and the "r_max" and "taper" commands
listed in the configuration file.  The "r_max" command is used to set the
maximum epicentral distance for weighting picks in the location process.
Any pick at a distance greater than r_max km from the starting epicenter
will not be used in relocating the event.  For picks within r_max km of the
epicenter, the distance-weight is a function of the current distance, r, and
the distance-taper function set with the "taper" commands (see the "Residual
Tolerance Distance Term, dist-taper" section above):

  distance-weight = ((min dist-taper value)/(dist-taper value at r))**2

  The overall weight of a pick in the relocation process will be a number
between 0.0 and 1.0, inclusive.
  The total number of phases binder can use in relocating an event is
limited using the "maxpix" command.  The default value (256) should be
plenty for most networks.

Relocation and Iteration Control:
  Binder hands its locator a starting location and a list of phases. The
locator determines the pick weights as above, then calculates the event's
average weighted travel-time residual (rms) to use as a reference for
testing divergence.
  For most earthquakes, the first iteration performed by the locator will
be a "Free" solution. It will invert for all four hypocentral parameters:
latitude, longitude, depth, and origin time. However, if an event has no
nearby picks associated, the locator will perform "Fixed Depth" solution
instead. This feature is controlled with the "FixDepth dmin trialz"
command (default dmin=50.0, trialz=8.0). If an earthquake has no picks
closer than "dmin" km, binder sets its depth to "trialz" km, then inverts
for only latitude, longitude, and origin time. This prevents events with
no depth resolution from flailing.
  The result of the locator's inversion is the "step-vector." This is the
amount by which the iteration will change all 4 hypocentral components.
Binder places limits on the horizontal (xystep) and vertical (zstep)
components of the step-vector in any given iteration. Those limits are set
with the "MaxStep xystep zstep" command (default xystep=10.0 km, zstep=2.0 km).
If either step-length is exceeded in an interation, all 4 dimensions
(x, y, z and time) of the step-vector are equally damped, preserving the
direction of the vector, such that each dimension is within its configured
limit.
  Binder also place limits on the valid range for computed hypocentral depth.
This range, specified with the "zrange zmin zmax" command (default range
is 2.0 - 20.0 km), should span the depth range in which you expect to detect
earthquakes. It must also span the entire depth range of the stacking
grid ("grdz" command); otherwise, events may stack outside of the zrange
limit and this could cause locator logic errors. If during an iteration,
the step-vector causes the depth to fall outside of the zmin-zmax range,
that step vector is abandoned. The locator then "restarts" the iteration;
beginning with the previous starting hypocenter, the locator performs a
fixed-depth solution.  This feature is useful in controlling locations
from network "glitches" where all picks are coincident and the apparent
high phase velocity would try to locate the quake at the center of the Earth.
  At the end of each iteration, binder recalculates the event's average
weighted residual (rms) and performs a test for divergence.  If the new
rms is greater than the previous rms*"constant" (set with "MaxDeltaRms"
command, default = 1.01), then the solution is diverging. If the location
is converging, the locator goes on to the next iteration. If a location
is diverging, binder removes half of the step-vector in all 4 dimensions
(x, y, z and time), backing the location up toward the starting location
from that iteration, and then checks the rms again. If the solution now
converges, the locator goes to the next iteration. If the solution is
still diverging, it backs the location up farther. Up to 3 backwards steps
will be made (resulting in a step-vector of 1/8 the original size) if
the solution continues to diverge.
  Binder's locator will perform a maximum number of iterations every time
that it's called. The maximum iteration count can be set with the "MaxIter"
command (default = 4). However, the locator may perform fewer than MaxIter
iterations if the change in the location (in X-Y-Z km) in any given
iteration is less than a minimum step-length (set with the "MinXYZstep"
command; default = 0.1 km).


Post-Relocation Event Review:
Pick Culling, Pick Scavenging, and Killing Events:
--------------------------------------------------
  Binder has just relocated an earthquake. Presumably, the location
is better contrained that it was before, and the arrival time fits
may have changed as well.  Binder now recalculates the travel-time
residuals for all phases associated with the event, regardless of
whether the phase was weighted in the relocation or not.  It also
calculates the event's average weighted residual (rms), and performs
a series of tests.

Pick Culling:
  For each associated pick, binder compares the new travel-time
residual to the new residual tolerance value for that station (see
the "Configuring the Travel-time Residual Tolerance Function" section
above).  If the new residual is larger than the tolerance, binder
deassociates or culls the phase from the earthquake.  That pick is
now free to associate with another event, or to stack with other picks
to identify a new earthquake.  If any picks are culled from an event,
that event is sent back to the locator once again.

Pick Scavenging:
  After an event is relocated, binder also looks through its list
of recent picks to see if there are any others which may fit the
travel-time curves of the new hypocenter.  Essentially, it does
the association process (comparing the travel-time residuals of
various phases to the residual tolerance at that station) on picks
that are in already its memory; binder is scavenging.  Binder is
allowed to scavenge two classes of picks in its list: those that are
not associated with any active event (also known as "waifs") and those
that are associated with events that have fewer phases than the
scavenging event.  So big events are allowed to steal phases from
smaller events, as long as the travel-time residuals fit.  Since a pick
can only belong to one event at a time, this scavenging feature makes
it possible for two events to merge into one.  This is useful in
avoiding "split events", where a large event is originally identified
as two events due to the order in which its arrivals were processed.
  If an event successfully scavenges one or more new phases, the
event is sent back to the locator once again.  Also, if any of the
scavenged phases had been associated with a second event, that
second event is also sent back to the locator.

Killing Events:
  In reviewing events, binder sometimes decides that an event is
no longer valid, either because its location parameters are poor,
or because it doesn't have enough supporting phases.  If after a
relocation, an event's rms is larger than a cutoff value (configured
with the "rmscut" command, default = 1.0 sec), binder marks that
event as destroyed or killed.  Or, if after a round of scavenging,
an event has fewer than 4 weighted phases (too few to relocate the
event), binder kills that event as well.
  When binder kills an event, it deassociates or unlinks all of
its phases. Those picks are then free to associate with other active
events as waifs, or to stack with other picks to identify new events.
To notify downstream modules that the event was killed, binder issues
a TYPE_QUAKE2K message for that eventid, setting the "number of
associated phases" field to zero.


Quality Control: Pick-group Assessment
---------------------------------------
  Occassionally one of binder's newly stacked events will include an
outlying pick which falls at a "leverage point" for the hypocenter
produced by binder's locator.  This bad pick has undue influence
over the hypocenter, causing a poor location which in turn leads
to the mis-association of other picks.  Binder uses a test called
"pick-group assessment" to identify and eliminate these outlying
picks, and to produce a trial hypocenter for the locator.  Given a
group of supposedly related picks, pick-group assessment tests whether
all of the arrivals are indeed consistent with a single earthquake.
  Pick-group assessment is most efficient when it is performed on an
event with relatively few associated phases. The configuration
command "assess_pk minpk maxpk" controls when the test is run; when
an event has between minpk and maxpk (inclusive) picks associated with
it, its pick set will be assessed before the event is handed to the
locator (defaults are minpk=6, maxpk=12). If an event stacks with more
than maxpk picks, its pick set will be assessed at least once.  To
turn off pick-assessing totally, set minpk and maxpk to zero.
   Only P-wave arrivals are used in pick-group assessment. First, the
set of picks is sorted in increasing time order and is examined for
glitches.  Glitch picks are eliminated from further testing (see the
"define_glitch" command described in the "Pre-Stack Glitch Filtering"
section above).  The remainder of the test involves a number of
resampling trials.  In each trial, four picks are chosen from the
pick set and the exact four-station hypocenter is calculated using a
uniform velocity halfspace (configured with the "v_halfspace" command,
default = 5.0 km/s). Next, binder calculates the travel-time residual
with respect to that hypocenter for every pick in the pick set (again
using the uniform velocity halfspace).  You can specify the maximum
pick quality (assigned by pick_ew) to use in this resampling process
with the "maxwt" command (valid values are 0-4, default = 3).  Picks
with qualities higher than maxwt (poorer quality) may be rejected as
glitches, but will not be used in resampling trials.
   The number of trials used in the pick-group assessment is controlled
with the "maxtrial" command (default = 500).  Given n picks sampled 4
at a time, the total number of unique combinations is n!/(4!*(n-4)!).
If this number is less than maxtrial, all possible combinations will be
used, with no duplication. If the total is greater than maxtrial, then
maxtrial random samples of 4 picks will be taken, and duplication is
possible.
  Statistics on the residuals from all of the trials are used to
determine if each pick should be accepted or rejected. If a pick is
an outlier, it will have very large residuals for any of the hypocenters
determined from 4 other picks. Also, the scatter in its residuals
will be large.  For each pick, binder calculates the median residual (med),
its absolute value (absmed), and the median of the absolute deviations
from the median residual (mad). If either the absmed or mad is greater
than a configured cutoff threshold, the pick is rejected as an outlier.
The cutoff values are configured with the "residual_cut maxabsmed maxmad"
command (default maxabsmed = 3.0 sec, maxmad = 10.0 sec).
  Pick-group assessment is a multiple pass process. The first pass samples
from the earliest (up to 25) P-phase picks which meet the testing criteria;
this pass is used to winnow the data to arrivals with median residuals
below a cutoff value. A second pass resamples the winnowed data to
determine the new starting hypocenter from the average of all the 4-pick
hypocenters.  This new starting hypocenter and the winnowed list of picks
are handed to binder's locator for further processing.
  If any picks were rejected as glitches or outliers by the pick-group
assessment, they are deassociated from the event and are free to restack
or reassociate.  Occassionally, binder rejects enough picks that the
event no longer has enough valid phases to relocate it.  In this case,
the event is killed, and all of its picks are deassociated.


Examples from Binder's Log File
-------------------------------
1. Stack: five picks stack to create a new event.

2. Glitch Detection in Stacking Phase: a series of picks stack, until
   the last pick identifies the group as a glitch.

3. Association: two examples: a pick associates with an active event and a
   pick fails to associate or stack.



Trouble-Shooting
----------------
Binder's not producing any earthquakes - what could be wrong?

1. Is it seeing any picks?
   Check the log file, you should see some lines like these:
 10  6  3 2189 MWB  NCVHZ D2  19990930005310.08     431     672     584
19990930_UTC_00:53:15 grid_stack, mhit = 0
   The first line is a TYPE_PICK2K message, the second is the log of an
   stacking attempt.

2. Is the velocity model specified with "lay depth velocity"?

3. Is the station file in the correct format?
   All lats & lons should be positive in degrees & minutes,
   with N,S,E,W denoted by letters. If there are no letters,
   N and W are assumed.

4. Are the stacking grid boundaries set properly?
   Lats & lons are in decimal degree with positive = N, E.



Module Index | Binder_ew Commands

Questions? Issues? Subscribe to the Earthworm Google Groups List.