wiki:glass

Version 6 (modified by branden, 8 years ago) (diff)

--

Earthworm Module: glass

Contributed by: Carl Johnson, Dave Kragness, Mitch Withers

Function

Carl Johnson's Global Associator. See the overview for the Glass Manual written for Hydra by Dave Kragness. (new in EW v7.0)

Manual

This is meant to be an informal document. As such it is not guaranteed to have been reviewed for things like accuracy, grammar, or spelling. (Take it with a grain of salt for good measure)

Initial Blame: David Kragness, Hydra Development Team

Mitch Withers converted to earthworm documentation with no significant changes from Dave's original word doc. The example configurations are found below though this "overview" does contain configuration advice. Carl Johnson's original edicts for earthworm are modularity and platform independence. Carl decided to focus on the science rather than the code for this module and it is currently hopelessly tied to the microsoft platform. It will not compile on any other.

Overview

Glass is a program designed and developed by Carl Johnson for the USGS NEIC, and is currently maintained by the Hydra development team. It is an earthquake Associator designed for a global(earth) environment. It has been integrated into Hydra, and is now an integral part of the Response Hydra system.

This informal document contains four(4) sections oriented at different individuals

  • The Seismologist/ Network Operator section contains information on tuning Glass for your seismic network.
  • The Hydra Administrator section provides information for the system administrator trying to configure Glass to run in an Hydra/ Earthworm environment.
  • The Programmer section contains information on the architecture of Glass code and notes for anyone looking to maintain/modify Glass.
  • The User section contains minimal information on the interactive use of the Glass GUI displays.

Seismologist/ Network Operator

Glass can be thought of as having four(4) major mechanisms for producing earthquake information (origins and associated phases): Nucleator, Associator, Locator, and Filter. The Nucleator creates new earthquake origins, the Associator associates picks with existing origins, the Locator refines origin hypocenters, and the Filter eliminates origins and origin-pick associations.

The Nucleator

Overview

The Nucleator is the portion of Glass that discovers new origins. The Nucleator is the core Glass technology. It is a method for associating a set of picks into an origin. The Nucleator is pick driven, meaning it is fired up whenever a new pick is introduced into Glass that cannot be associated with an existing origin. The new pick (the keystone pick), along with any other unassociated picks in a time window relative to the keystone, are thrown into the Nucleator together. The Nucleator calculates a number of trial origin depths/times (based on the time of the keystone pick) and iterates through them. For each prospective depth/time, the Nucleator obtains an epicentral distance for the keystone pick. The distance is obtained via a reverse lookup of traveltime tables, based on: 1) the delta between the origin time and keystone pick time, 2) the origin depth, and 3) a seismic phase type of P. Using the epicentral distance and the depth, the Nucleator calculates a linear distance. It uses this distance as the radius of a sphere centered at the location of the keystone pick. It then calculates the circle that is the intersection of the keystone sphere and the depth shell sphere (centered at the center of the earth, and radiating out (6371 depth km). This intersecting circle becomes The Ring. For each OTHER pick, the Nucleator calculates the intersection of that pick's sphere (as determined by depth, origin-pick delta time, and P phase) and The Ring. That intersection can be either one or two points (or zero if there is no intersection). The end result is a set of points (each resembling a potential origin location) scattered across the circumference of the Ring. The Nucleator then iterates through the points and for each point calculates the distance of the nth closest point. It then selects the point with the minimum nth-point-distance as the preferred origin location for that time/depth iteration.

Then, after it's computed the preferred origin location for each depth/time iteration, it compares the results from each location and selects the best one (as determined by nth-point-distance). Then if the resulting preferred (from all iterations for that keystone pick) location results in a sufficiently small nth-point-distance, the Nucleator declares a new origin with the determined parameters.

Parameters Tunable

With the exception of the travel time tables and the station list, all of the tunable parameters for the Nucleator are controlled via the glass_assoc.d configuration file.

There are 6 sets of key tunable parameters in the Nucleator:

  1. Location Points: number of and distance threshold.
  2. Time windows for potential origins and associable picks
  3. Size of the time iterations
  4. Depth iterations
  5. Travel time tables
  6. Station List

Location Points

A line similar to the following:

Cut 9 50

appears in the glass_assoc.d config file. The Cut command takes two arguments: number of location points, and distance threshold. When the Nucleator is evaluating potential origins, it calculates nth-point-distance for each potential origin for each time/depth iteration. The first argument defines n (the number of points), and the second argument defines the distance threshold of acceptable origins. So Cut 9 50.0, would instruct the Nucleator to require 9 points to be within 50km of a perspective origin on The Ring, in order for that origin to be deemed acceptable. Note that the Nucleator counts the central point in the 9, so there are only required to be 8 (n-1) other points within the distance. n in theory controls the number of points required in a proximate distance, but in practice, it can be used to determine the number of P-phases required to associate an origin.

Time Windows

A line similar to the following:

TimeRange -600.0 500.0 -820.0

appears in the glass_assoc.d config file. The Nucleator processing is concerned with 2 time windows. The first time window is processed outside of the Nucleator, and directly determines the inputs to the Nucleator. The first time window defines the unassociated picks that will be sent to the Nucleator as picks that are associable with the current pick. The second time window defines the range of potential origin times that should be used by the Nucleator for constructing trial origins. The TimeRange command takes three arguments: the start and end of the first time window (Pick times), and the start of the second time window (Origin times). For example, if the current pick came from station XYZ at 10:45:00, then the above TimeRange command would cause all unassociated picks between 10:35:00 (10:45:00 - 600) and 10:53:20 (10:45:00 + 500) to be sent to the Nucleator along with the current pick. The command would also instruct the Nucleator to try potential origins between 10:31:20 (10:45:00 - 820) and 10:45:00 (10:45:00 + 0).

Time Iterations

A line similar to the following:

TimeStep 5.0

appears in the glass_assoc.d config file. The Nucleator iterates through a set of trial origin times within the potential origin time window. The time delta between iterations in seconds is defined by the TimeStep command. So if TimeStep is 5.0, then the Nucleator will iterate between origins that are 5 seconds apart. The smaller the TimeStep value, the closer the Nucleator should be to the actual origin time and the more processing iterations that will have to be done, so there is a tradeoff between accuracy and processing effort. There are two factors that affect what the TimeStep value should be set to: residual distance limits and locator ability. Because the Nucleator fixes the origin time and depth, any residuals are distance based. If the TimeStep value is set too high, then it increases the artificial distance residual that may be imposed on an origin because the actual event time lay between two iterative steps. So if an event occurs at time 1232.5, TimeStep is set to 5, and the closest two origin time iterations are 1230.0 and 1235.0, then an artificial time residual of 2.5 seconds is being imposed on the nucleated origin. Because the Nucleator deals only in distance residuals, that 2.5 seconds becomes converted to a distance value. When that residual distance value gets to be too great then the Nucleator will no longer be able to associate the origin. The Nucleator is a tool to associate picks into an Origin, its association is not meant to be the Glass end-all final location answer. Within Glass there is a Locator that will refine solutions after they come out of the Nucleator. So a TimeStep value must be chosen that is not too processing intensive but is also not so wide as to preclude origins based on the artificial residuals between time iterations and actual event time. A TimeStep of 5.0, results in a maximum artificial window of 2.5 seconds, with a maximum P velocity of about 13km/sec, that ends up at a worst case artificial distance residual of 32km. If the distance Cut is set to 50km, this leaves only 18km available for anomalies due to actual vs. theoretical 1-d travel times, and depth iteration intervals.

Depth Iterations

Lines similar to the following:

# Shells
Shell 5.0
Shell 20.0
Shell 60.0
Shell 100.0
Shell 200.0
Shell 400.0
Shell 600.0

appear in the glass_assoc.d config file. Each one of these lines defines a depth iteration. The Nucleator iterates through a set of trial origin depths as defined by the Shell commands. Shells should be defined in order of increasing depth. The depth iteration considerations are similar to the time iteration considerations. The same rules hold true for residuals. With a small number of depth iterations defined, the depth residuals may be quite large, but depth and time tend to be somewhat interchangeable, especially if there are enough picks at a similar origin distance to the keystone pick. This allows depth residual to overflow into time residual and be mitigated by a small enough time iteration. (To the Nucleator, an event at time 1230 and depth 300km, will look a lot like an event at time 1235 and depth 400km). If the Nucleator ends up time/depth shifting an event to make the depth residual small enough to fit, then hopefully the Locator will be capable of re-shifting the event back into place with the use of other phase data.

Travel-time Tables

The Nucleator and the rest of Glass use the Hydra traveltime libraries to access data stored in traveltime tables. At this point Glass uses a special subset of traveltime tables that were generated based on empirical ad-hoc observations regarding the phases being picked by the Hydra picker. The actual traveltime tables used by Glass are defined in the tt_tables.d config file in the Hydra params directory. The individual traveltime files must be generated by a separate program. See Generating Traveltime Tables in the Programmer section of this document, or find a developer to do it for you.

The parameters that control the generation of the Glass specific traveltime tables are defined in a set of files tt_*_Glass.txt in the earthworm CVS tree under src/seismic_processing/glass/run/params/ttt.

Each traveltime table entry contains the following information:

  • Traveltime
  • Depth
  • Distance
  • Take Off Angle
  • Time residual window half-width
  • Horizontal Slowness of the phase (dtdx)
  • Vertical Slowness of the phase (dtdz)
  • Association Strength (Pick Probability Density - not currently used)
  • Location Weight (used by the Glass Locator, not by the Hydra Locator)
  • Mag. Threshold (not currently used)
  • Phase Name

The Nucleator makes use of only P phases from the crust/mantle. The current list includes (Pg, Pb, Pn, p, P, Pdif), and only the Traveltime, Depth, and Distance information. Under the current code, there is probably not much that should/could be altered in the traveltime tables that would affect the Nucleator.

Station List

The Nucleator is fairly sensitive to the affects of noisy stations. If you have stations that consistently generate non-relative picks, you may wish to remove them from the station list. Noisy stations will often generate picks that are ripe for coincidental associations which can corrupt origin parameters, causing false or mislocated earthquakes.

Glass currently uses the list of stations specified in the Glass_data\stalist.hinv file (a list of stations in HypoInverse station list format). The lower the number of Cut points, the more sensitive the Nucleator will be to noise picks. Glass must be restarted in order for station list file changes to take effect. There is no way to adjust the station list on the fly during runtime. Glass will ignore all picks received from channels that are not in the station list

Parameters Untunable

The Nucleator only uses mantle/crust P phases for association. It does not use any other kind including PKP. This is hardwired into the code. This could easily be changed in a later release with potential consequences.

The Associator

Overview

The Associator is the portion of Glass that associates picks with existing origins. The Associator is a simple tool that compares a pick with origins using traveltime tables. The Associator is pick based. For each pick that comes into the Associator, the Associator compares the pick to a list of origins known to it, and matches the pick up with the origin for which it has the best fit (as determined by an affinity statistic). If the affinity statistic is above a certain threshold then the pick is associated with that origin, otherwise it gets passed to the Nucleator where it will attempt to associate it as the keystone pick. The affinity statistic is generated based upon certain origin and origin-pick parameters:

  • Number of phases already associated with the origin;
  • Azimuthal gap between associated P-phases;
  • Residual for the current phase;
  • Distance of the current phase relative to the median distance for the phases already associated with the origin.

At the core of the Associator is the simple task of evaluating the likelihood that a pick associates with an origin as a certain phase. The Associator also runs in a separate fashion, where it reevaluates how all of the relevant picks associate with an origin after that origin has been modified. In this case there are 3 groups of picks (that are time relevant):

  • Picks already assigned to the origin
  • Picks not assigned to any origin
  • Picks assigned to a different origin

For each pick currently assigned to the modified origin, the Associator reevaluates the association in order to recalculate the residuals and re-evaluate the best phase match (sometimes the picks will associate as a slightly different phase pP vs. P or Pg vs. Pb). Here the Associator is acting as a catalyst to the origin refinement process.

For each pick that IS NOT associated with any origin (but is still time relevant), the Associator attempts to associate the pick with the origin. Here, the Associator is acting as a reassociator to associate picks that couldn't originally be assigned because of the poor quality of the initial hypocenter location.

For each pick that is assigned to a DIFFERENT origin, the Associator attempts to associate the pick with the modified origin. The Associator compares the association quality of the pick with its existing origin and the modified origin and if the pick now associates better with the modified origin, it reassigns the pick from its current origin to the modified one. At this point the Associator is tasked with resolving splits that may have occurred due to errors in early estimates of the origin hypocenter. The Associator should be taking picks away from a weaker origin and adding them to a stronger origin, until the stronger origin finally eats the weaker one.

Parameters Tunable

There are three sets of parameters that affect the Associator:

  1. The traveltime tables
  2. The station list
  3. The affinity statistic coefficients

The traveltime tables and station list are currently tunable. The affinity statistic coefficients defined in the traveltime tables are tunable, but the others that are hardcoded within the Glass program are not.

Travel-time Tables

Please see Travel-time Tables under The Nucleator for an overview of the traveltime tables. At this point Glass uses a special subset of traveltime tables that were generated based on empirical ad-hoc observations regarding the phases being picked by the Hydra picker.

In addition to an origin, the Associator requires two sets of inputs in order to perform an association: a traveltime table for the appropriate distance/time, and a pick. If there are no traveltime tables then there are no associations. If there are no traveltime tables for a depth/distance/phase type, then there will be no associations made for that depth/distance/phase type. So associations can be limited by limiting the available traveltime tables. At the very least you want to limit the traveltime tables to the phases that are actually observed by the picker that is generating input to Glass. If the picker doesnÆt pick a phase at a distance, then there shouldn't be a Glass traveltime table entry for that phase at that distance. What to do about phases that periodically appear is a more difficult question. They can either be excluded, or can be included and an attempt can be made to rig the affinity statistic coefficients in order to limit their use to where they will likely be seen. Examples of this problem include PKKP, P'P', ScP.

Station List

The Associator requires two sets of inputs in order to perform an association: a traveltime table for the appropriate distance/time, and a pick. If there are no picks, there will be no associations. So associations can be limited by limiting the available picks. Whether or not to limit legitimate energy picks in order to get better answers out of Glass is a question that's above my position on the seismology scale; however, limiting noisy stations that do not contribute picks that are relative to your end goal is a recommended activity. For example, if you are interested in locating medium to large global earthquakes, then you probably do not want to include stations with faulty electronics, stations with a lot of non-seismic noise (traffic, oceans, ice breaking), or stations that are located close to an active seismic source that constantly releases energy in small magnitudes. Noisy stations will often generate picks that are ripe for coincidental associations. This can corrupt origin parameters, causing false or mislocated earthquakes.

Tunable Affinity Statistics Traveltime Tables

Traveltime tables are generated by a separate program, which is not currently setup for seismologist operation. There are a number of configuration files that are used as input to the traveltime table generation program, that can be edited by a seismologist. These input files currently live in hydra_proj\params\resp\seismic\ttt\glass\*.txt. In these files, a configuration paragraph similar to the following appears for each traveltime table.

Phase	PKKPbc	PKKP
DistRange	 85	 125
DistDelta	 2.5
DepthRange	 0	 800
DepthDelta	 25
TimeDelta	 10
RayParam	 2.0	 4.112
LocWeight	 0.05
ResWinWidth	 15.0

The above paragraph tells the program that generates the traveltime tables to generate one for the phase PKKP, to be named PKKPbc, to generate it over the distance range of 85 to 125 degrees with an entry every 2.5 degrees, for a depth range of 0 to 800 with an entry every 25km; it also tells it to generate a reverse lookup table based on time/depth, with entries every 10 seconds / 25km. It tells it to only use PKKP phases with ray params between 2 and 4.112 (the bc branch but not the ab). The LocWeight entry is not important to the Associator but effects the weight given to this phase by the Glass Locator. The last entry is SIGNIFICANT with respect to the Residual affinity statistic. It tells the Associator to use a 15 second residual window (half-width) for this phase, instead of the default of 10. The residual affinity statistic is calculated based on the ratio of the residual to the allowable residual window.

The generation program will generate a table for each configuration paragraph. Actually two tables get generated: one based on time/depth and one on distance/depth. Each entry in these tables will contain the following information:

  • Traveltime
  • Depth
  • Distance
  • Take Off Angle
  • Time residual window half-width
  • Horizontal Slowness of the phase (dtdx)
  • Vertical Slowness of the phase (dtdz)
  • Association Strength (Pick Probability Density - not currently used)
  • Location Weight (used by the Glass Locator, not by the Hydra Locator)
  • Mag. Threshold (not currently used)
  • Phase Name
Parameters - Untunable

Affinity Statistic

Most of the components of the affinity statistic generated for an origin-pick association are not tunable. The composite affinity statistic is generated via the following equation: Affinity = Origin.Gap_Affinity * Origin.Number_of_Arrivals_Affinity *

Pick.Residual_Affinity * P.Distance_Affinity * Pick.PPD_Affinity

Certain components of the affinity statistic can be turned on and off via the OPCALC_fAffinityStatistics variable. (This variable is currently hardcoded and cannot be changed in a config file.)

The component affinity statistics are generated in the following manner

Origin.Gap_Affinity Value: Origin.Gap_Affinity = 4 * Bellcurve_Value(Origin.Gap / 360) Description: Origin.Gap is the maximum azimuthal gap between P phases

associated with the origin. If the number of existing associations is too small (currently defined as less than OPCALC_nMinStatPickCount = 10), then Origin.Gap_Affinity is set to 1.0.

Range: Artificially limited to 0.5 û 2.0. (If the gap is

EXCRUSIATINGLY BAD (more than 325 degrees) then it is not artificially limited.)

Reason: Gap is a crude measurement of the quality of the epicentral

location. An origin with an azimuthal gap of 90 will generally produce a more accurate location than an origin with a gap of 270, even if the number of phases associated with each origin is the same.

Origin.Number_of_Arrivals_Affinity Value: Origin.Number_of_Arrivals_Affinity = log10(Origin.NumberOfPhases?) Description: DescOrigin?.NumberOfPhases? is the number of phases that were

used by the Locator to generate the latest hypocenter for this Origin. The affinity value is limited to a minimum of 1.0.

Range: Artificially limited to 1.0+ (Under the current NEIC network

2.5 is the realistic maximum based on 300 phase picks).

Reason: The number of arrivals associated with an origin is a crude

measurement of the magnitude of the quake. This allows larger quakes an improved chance of associating more phases. This aids in preventing splits where larger quakes can associate phases even though they have large residuals, and in resolving splits where larger origins can steal phases from smaller ones.

Pick.Residual_Affinity Value: Pick.Residual_Affinity =

2 * Bellcurve_Value(Pick.Residual / PhaseResidualWindowWidth?)

Description: Breakeven point is one half the residual window width. For the

default 10 second window, a residual of 5 seconds would net a Residual_Affinity of 1.

Range: The range is 0 to 2, with no artificial limits. Reason: The residual is the most key requirement in the association of

a Pick to an Origin. You cannot associate a Pick as a P phase if the pick delta time is not close to the theoretical traveltime. The affinity statistic allows picks that are closer to the theoretical traveltime to garner an improved affinity.

Pick.Distance_Affinity Value: Pick.Distance_Affinity =

Bellcurve_Value(Pick.Distance/(Median_Distance_Estimate*4))

Description: Distance based filtering is a decent mechanism for excluding

coincidental picks that arenÆt generated by energy released by a quake. The distance affinity statistic prevents picks outside of four(4) times the median distance from being associated with this origin. The value 4 is hardcoded as OPCALC_dCutoffMultiple. The breakeven point is twice the median distance estimate; however the median distance estimate is fudged for very small earthquakes as well as for some larger ones. For very small earthquakes the median distance is multiplied by 1.5. For certain earthquakes that are located near the heart of the network such that the median distance is kept low by the non-uniformity of the network (for the NEIC, imagine a M5.0+ earthquake located anywhere in the contiguous US), the median distance is artificially inflated relative to the number of phases associated with the origin. This allows for PKP and other associations that would otherwise be disallowed because the median distance is only 15 degrees.

Range: The range is 0 to 2, with no artificial limits. Reason: Distance is used as a sanity factor to prevent local or regional

quakes from associating with coincidental picks across the globe, which have no energy from the quake associated with their pick, and may corrupt the origin parameters.

Composite Affinity

Because the composite affinity statistic is a product of all the components, any affinity with a value of 0 automatically nixes the association. The residual, dip, and distance affinity components can potentially have a value of 0. So an association can be precluded because 1)the residual is too great; 2) the distance is too great; 3) all of the picks are coming from a single direction(azimuthal gap).

Assuming that none of those components preclude the association, then the composite affinity for the pick/origin must be above a minimum affinity threshold in order to be eligible for association. That threshold value is hardcoded to 0.9 ( as OPCALC_dAffMinAssocValue). Note that to allow quakes to properly build, exceptions are made to how affinity statistics are computed for small earthquakes. Currently small quakes are defined as those with less than 10 phases (hardcoded as OPCALC_nMinStatPickCount).

Two examples:

SNZO BHZ IU 00 reports a pick 329.1 seconds after an existing origin. The origin has 138 phases, an azimuthal gap of 54 degrees, and a median distance of 83 degrees. 54 degrees results in a Gap_Affinity of 2.0. 138 phases results in a Number_of_Arrivals_Affinity of 2.14. The theoretical traveltime for a P phase at SNZOÆs distance and the originÆs depth is 324.9 seconds, resulting in a residual of 4.25, resulting in a Residual_Affinity of 1.2. The distance of 24.9 degrees relative to the median distance of 83 results in a Distance_Affinity of 2.0. The PPD is fixed at 1.0. The composite affinity for this pick relative to the origin is 10.3 (2.0 * 2.14 * 1.2 * 2.0 * 1.0). It is greater than the minimum affinity requirement of 0.9, so it would be eligible for assignment to this origin and would very likely be assigned to it as the affinity is quite high.

MTE BHZ GE -- reports a pick 1223.4 seconds after the same origin (138 phases, gap of 54 degrees, and median distance of 83 degrees). 54 degrees results in a Gap_Affinity of 2.0. 138 phases results in an Number_of_Arrivals_Affinity of 2.14. The theoretical traveltime for a PKPab phase at MTEÆs distance and the originÆs depth is 1215.0 seconds, resulting in a residual of 8.4, resulting in a Residual_Affinity of 0.14. The distance of 155.3 degrees relative to the median distance of 83 results in a Distance_Affinity of 1.1. The PPD is fixed at 1.0. The composite affinity for this pick relative to the origin is 0.66 (2.0 * 2.14 * 0.14 * 1.1 * 1.0). Because the affinity is below 0.90, this pick would not be eligible for assignment to the origin.

Relevant Origin Time Range

In it's primary role of trying to assign a new pick to its most likely origin, the Associator grabs only the origins that are time relevant to the pick. The relevant origin time window relative to the pick time is hard coded. It starts 2400 seconds pick (hardcoded as OPCALC_dSecondaryAssociationPrePickTime) prior to the pick and ends at the time of the pick.

Relevant Pick Time Ranges For An Origin

When the Associator runs in it's alternate scope of reevaluating how all of the time relevant picks associate with an origin after that origin has been modified, it uses various time windows. (this is a bug/feature).

Picks not assigned to any origin

The Associator uses a pick time range of (Origin_Time - 2400 seconds to Origin_Time) (2400 seconds is hardcoded as OPCALC_dSecondaryAssociationPrePickTime)

Picks assigned to a different origin

The Associator uses a pick time range of (Origin_Time - 2000 seconds to Origin_Time) (2000 seconds is hardcoded)

The Locator

Overview

The Locator refines Origin parameters based on a least-squares inversion of the residual vectors for associated phases. (or something like that) The residual vectors are calculated based on the residual and azimuth from each pick along with the dtdx(horizontal slowness) and dtdz (vertical slowness) for the phase association.

Parameters Tunable

The Locator has two tunable parameters: the location weight of each phase (set in the traveltime tables), and the number of iterations it will run each time it is invoked.

Location Weight

The Location Weight is set in the traveltime tables. See Tunable Affinity Statistics Traveltime Tables under the Associator section for a description of traveltime table parameters. Setting LocWeight to a value will cause the Locator to apply that weight to picks of that phase. The default weight is 1.0.

Number of Iterations

A line similar to the following

NumLocatorIterations? 3

Can be placed in the glass_assoc.d config file. This line would cause the locator to be run for three iterations each time the Locator is invoked. The default is 1.

Parameters Untunable

The Locator has no untunable parameters.

The Filter

Overview

The Filter is the portion of Glass that eliminates origins or pick-origin associations because they don't pass certain validity tests. The Filter consists of a conglomeration of filters that are split into different portions of Glass. They attempt to filter coincident origins and coincident pick-associations from the Glass output. The filters can be thought of as falling into 3 groups: core, network specific, and output.

Core Filters

The Core filters are very simple. They ensure that existing origins and origin/pick associations don't violate the original association requirements. They are used to remove origins that don't have enough pick associations because the location has changed or because its picks have been stolen by another origin. They are used to remove assigned picks because their affinity has dropped due to changes in the parameters of the origin.

Validate Origin

A filter will delete an origin if it discovers any of the following 3 conditions:

Number of phases associated with the origin dropped below the number

of points required by the Nucleator to create a new origin.

Number of phases used by the locator to compute the latest hypocenter

for the origin dropped below the number of points required by the Nucleator to create a new origin.

Number of P phases associated with the origin drops below (number of

points required to nucleate - 1). The -1 is added as a bit of a buffer against excessive origin deletion.

Validate Associations

A filter will delete an origin / pick association (unassign the pick from the origin) if it discovers that the pick / origin affinity drops enough below the minimum association value to exceed a slop buffer (hardcoded as (OPCALC_dAffMinAssocValue - OPCALC_dAffinitySlop = 0.9 - 0.5 = 0.4 ) The substantial slop buffer was added for two reasons: to prevent association oscillations for borderline picks (picks with affinity near the minimum association value); to encourage associated picks to stay associated even if the locator swings the origin in some direction that is not favorable to the pick.

Network Specific Filters

Glass contains several origin oriented network specific filters that are capable of invalidating a given origin. The key reason for these filters is to overcome anomalies in network uniformity and density. In the NEIC Hydra network, the lion's share of sensors are located in North America, such that tuning Glass to preclude coincident events in North America would also preclude many valid medium sized earthquakes in the rest of the world; tuning Glass to include those medium sized events would also cause many coincident/noise events in North America to be produced.

The current set of filters defines 5 regions:

The Inter-mountain West region (46,-104 - 37.5,-113)

Western hemisphere (85,-140 - 45,-40)

Northwest quadrant (85,-170 - 0,-40)

North polar region (Lat > 70)

Rest of the world

For each of these regions the filter checks for a minimum number of quality P phases. The criteria for a quality phase is a residual within 2 seconds of the predicted arrival time. In regions 2 - 4, phases from the networks UU, IW, and MB are not allowed to count towards the minimum requirement.

If the epicenter of the origin falls in regions 1 - 4, then the origin will be invalidated unless one of the following criteria is met:

10 quality P phases are associated with the origin. (10 is hardcoded

as MIN_QLTY_ARR)

4 quality short-range P phases are associated with the origin, where

short-range is defined as distance less than 10 degrees. (4 is hardcoded as MIN_QLTY_CLOSEIN_ARR)

If the epicenter of the origin falls outside regions 1-4 (inside region 5), then the origin will be invalidated unless there are at least x quality arrivals, where x = number of points required to nucleate / 2 This is an integral equation, so if number of points is 8 then you need 5, if 9 then 5, if 10 then 6, in order to avoid invalidation.

Output Filters

Glass contains one final set of filters that do not have a dramatic effect on the world of Glass, but affect what information that Glass exports to the outside world. There are several filters that run in the publishing module that periodically exports event messages to the rest of Hydra.

Minimum Number of Phases

A filter prevents the publication of origins that have fewer than the minimum number of associated phases, as defined by the MinNumPhases? is the glass_pub_params.d config file. Events that don't reach the threshold are not deleted inside of Glass, but they are never published by Glass to the outside world.

Ancillary Phases

A filter tries to prevent certain coincidental associations with an origin, by requiring a minimum number of a certain phase type before phases of that type are published. The current hardcoded limit is 3, and S phases closer than 10 degrees and all P phases are immune to this restriction. For example, if there are two PKPab phases (VLC and MTE), and 4 PKPdf phases (MORC, PSZ, WLF, and CSS) with an origin, then there will be NO PKPab phases published for that origin, but all 4 of the PKPdf phases will be published.

Pdif Phases

A filter prevents Pdif phases > 110 degrees from being published. I don't think there is a GOOD reason for this; however Pdif phases beyond 110 degrees for the current picker are almost always coincidental associations.

Old Events

A filter prevents quakes older than a threshold number of days from being published. A command OldestEventToPublish? in the glass_pub_params.d config file controls the length of the threshold in days. For example: a quake occurs on 09/01/05 at 11:00 UTC, and OldestEventToPublish? is set to 5.0. The quake is not picked up until some late arriving data enters the system on 09/06/05 and 12:00 UTC. Glass now associates the quake, but does not publish it because it has been 5.04 days since the origin time, which is beyond the 5.0 day threshold.

Dead Events

A filter prevents an origin from being published once it is dead. The publishing module tracks an origin through its life cycle in Glass, publishing it over and over again as it changes. At some point the Publisher deems the Origin stale and marks it as dead. This was done with the idea that Glass has a certain scope of time within which it operates, and at some point in time Glass should acknowledge that the quake has gone out of time scope for automatic processing and is being handled further down the processing stream.

Publication Rate

The publication module controls how often glass updates the outside world on how an origin is progressing. Publication rate is potentially affected by both the amount of change an Origin is going through and the amount of time that has occurred after the origin. Publication in general is controlled by the glass_pub_params.d config file, and the controlling parameters are documented within that file.

Other Stuff

There are several other mechanisms within Glass that affect processing, but do not affect output to the degree of the major four. The Depth Refocus module attempts to discover alternate hypocenter depths that elude the Locator. The State Processing orchestrates how origins and picks are processed by Glass.

Depth Refocus

Depth Refocus is a module that searches for an improved origin depth and time that cannot be discovered by the Locator. Refocus assumes a correct epicenter, and does a depth/time grid search for a potentially better depth/time combination. Refocus module utilizes all time-relative picks as input, regardless of their origin assignment status. It attempts to associate each pick as either a P or pP phase for the origin at each point in the time/depth grid. It was created to get the Locator out of local residual minima. Currently there are no tunable parameters in the Focus module.

State Processing

Glass contains a state processing engine that controls how picks and origins are processed. The engine is entity oriented where an entity is either a pick or an origin. It's operation is configured by Tran commands in the glass_assoc.d config file. At this point State Processing configuration is considered to be an engineering issue and is not meant to be modified by a seismologist/network operator.

Hydra Administrator

This section to be filled in later with information regarding how to configure Glass to run in a Hydra/Earthworm? near real-time environment.

Configuring Glass

glass.d

Error Reporting

Glass, by default writes 3 levels of status messages:

MAJOR ERROR

There are 39 Major Errors. They include things like:

Can't open config file.

Can't load DLL (Module)

Can't allocate memory

Can't load traveltime tables

Can't get EW message types

Can't access required module

Can't attach to shared memory

Can't create internal messages

Can't parse config file command

Can't write to temporary files.

MAJOR WARNING

There are 3 Major Warnings They are reserved for times when glass gets "CONFUSED" internally. It continues to operate, but wants you to know that you may regret it in the morning.

MINOR ERROR

There are somewhere around 90 Minor Errors. They cover everything under the sun, including Missed Messages, and so forth so on, and are a general catch all for stuff that the operator or programmer may want to know about.

To make matters more complicated, while the internal error levels are hardcoded in the code, the way glass reacts to them (i.e. what glass reports and how) is completely configurable via the .d files. So you could (while not recommend it) configure glass via the .d file, to issue status messages for each DEBUG/INFO message and not issue them for any of the Major Errors.

From the default glass.d file:

# DebugLevel? commands # CatalogDebugLevel? | EarthwormDebugLevel? | GlassDebugLevel? | GlintDebugLevel? | LocatorDebugLevel? | PublisherDebugLevel? # Level: 0-9 # MAJOR_ERROR 0 # MAJOR_WARNING 1 # MAJOR_INFO 2 # MINOR_ERROR 3 # MINOR_WARNING 4 # MINOR_INFO 5 # FUNCTION_TRACE 9 # # OTF : OutputToFile? # OTD : OutputToDebugger? # OTE : OutputToError? # OTS : OutputTimeStamp? # OSM : OutputStatusMessage? # # Format: # DebugLevel? I:Level={0-9} I:OTF={0|1} I:OTD={0|1} I:OTE={0|1} I:OTS={0|1} I:OSM={0|1} # # Default values: {OTF,OTD,OTE,OTS,OSM} # {1,1,1,1,1}, MAJOR ERROR # {1,1,1,1,1}, MAJOR WARNING # {1,1,0,0,0}, MAJOR INFO # {1,1,1,1,1}, MINOR ERROR # {1,1,1,0,0}, MINOR WARNING # {0,0,0,0,0}, MINOR INFO # {0,0,0,0,0} FUNCTION TRACE

# # Example: # EarthwormDebugLevel? I:Level=2 I:OTF=1 I:OTD=0 I:OTE=0 I:OTS=0 I:OSM=0

User

This section to be filled in later with information regarding how to operate the Glass displays including the ManQuake? display for manually testing a hypothetical hypocenter.

Programmer

This section to be filled in later with information regarding the architectural layout of Glass, along with notes on how to maintain/modify it.

Configuration File Commands

Example glass.d

 # Directory section  - allows you to select which directory glass will
#  look in for particutlar files.
# DLLs   - directory where glass will look for the Module DLLs specified below
#  This should not be needed if you put the bin directory in your "PATH"
#$ DLLs j:\src\usgs\home\earthworm\v6.2\bin\
$ DLLs e:\ew\v7.0beta\bin\

# DATA   - directory where glass will look for DATA files
$ DATA glass_data\

# Module load section (load all modules before initializing parameters)
mod {DLLs}Network.dll
mod {DLLs}Flinn.dll
mod {DLLs}Earth.dll
mod {DLLs}Glint.dll
mod {DLLs}Glass.dll
mod {DLLs}Glock.dll
mod {DLLs}Solve.dll
mod {DLLs}ManQuake.dll
mod {DLLs}Grok.dll
mod {DLLs}Catalog.dll
mod {DLLs}Earthworm.dll
mod {DLLs}Summary.dll
mod {DLLs}Residuals.dll
mod {DLLs}Refocus.dll
#mod {DLLs}FocusGUI.dll
#mod {DLLs}FocusGUI_DP.dll
mod {DLLs}Publisher.dll


# enables nexus traffic monitor
DISPLAY

# Means: messages go to all modules
BROADCAST

# Processed by nexus.dll
Initialize

DISPATCH
# Turns on glass status window(glass.dll)
GlassMonitor

# associator param file (glass.dll)
GlassParams S:File={DATA}glass_assoc.d

# Hypo station list (network.dll)
HypoLoad S:File={DATA}glass.hinv

# Init file for earth module (tt code) (earth.dll)
TTInit S:File=tt_tables.d

# map base (grok.dll)
World S:Base={DATA}World.bmp

# glass pub params
PubAlgParams S:File={DATA}glass_pub_params.d

# Reporting params (glass.dll)
ReportInterval I:Interval=20

# Earthworm params (earthworm.dll)
RingIn S:Name=PICK_RING
RingOut S:Name=ASSOC_RING
HeartBeat I:Interval=30
ModuleId S:Module=MOD_GLASS_EW
LogFile

# NoFlushInput  - uncomment this line to prevent glass from flushing
#                 the earthworm input RING.  - not recommended
                                               for normal operation
#NoFlushInput


# LOG_PICKS  -  Log picks to the glass_pick_log.txt file in EW_LOG dir.
LOG_PICKS

# LOG_ORIGINS - Log origins to the glass_origin_log.txt file in EW_LOG dir.
LOG_ORIGINS

# SHOW_PICKS -  Display new picks in the Map window (grok.dll)
SHOW_PICKS

# TERMINATE - uncomment this line to have glass terminate immediately after
#             processing the config file.
# TERMINATE


# Flinn Engdahl Regions
FlinnEngdahlLoad S:Dir={DATA}

#  DebugLevel commands
#  CatalogDebugLevel | EarthwormDebugLevel | GlassDebugLevel | GlintDebugLevel | LocatorDebugLevel | PublisherDebugLevel
#    Level:  0-9
#           MAJOR_ERROR 0
#           MAJOR_WARNING 1
#           MAJOR_INFO 2
#           MINOR_ERROR 3
#           MINOR_WARNING 4
#           MINOR_INFO 5
#           FUNCTION_TRACE 9
#
#    OTF : OutputToFile
#    OTD : OutputToDebugger
#    OTE : OutputToError
#    OTS : OutputTimeStamp
#    OSM : OutputStatusMessage
#
#  Format:
#  DebugLevel I:Level={0-9} I:OTF={0|1} I:OTD={0|1} I:OTE={0|1} I:OTS={0|1} I:OSM={0|1}
#
#  Default values:  {OTF,OTD,OTE,OTS,OSM}
#  {1,1,1,1,1},  // MAJOR ERROR
#  {1,1,1,1,1},  // MAJOR WARNING
#  {1,1,0,0,0},  // MAJOR INFO
#  {1,1,1,1,1},  // MINOR ERROR
#  {1,1,1,0,0},  // MINOR WARNING
#  {0,0,0,0,0},  // MINOR INFO
#  {0,0,0,0,0}   // FUNCTION TRACE

#
#  Example:
#  EarthwormDebugLevel  I:Level=2 I:OTF=1 I:OTD=0 I:OTE=0 I:OTS=0 I:OSM=0
EarthwormDebugLevel  I:Level=4 I:OTF=1 I:OTD=1 I:OTE=1 I:OTS=1 I:OSM=1
GlassDebugLevel  I:Level=5 I:OTF=1 I:OTD=1 I:OTE=1 I:OTS=1 I:OSM=1

Example glass_assoc.d

 Cut 9 50.0 # Empirical Params
TimeRange -600.0 500.0 -820.0
TimeStep 5.0

# Shells
Shell	  5.0
Shell	 20.0
Shell	 60.0
Shell	100.0
Shell	200.0
Shell	400.0
Shell	660.0


# Glass State - Transition Rules
Tran	Unassigned_Pick			1	Assign		100
Tran	Unassignable_Pick			1	Associate		100

Tran	Changed_Origin			1	Locate		100
Tran	Origin_w_Changed_Assocs		1	Locate		100
Tran	Located_Origin			1	Prune			100
Tran	Located_Origin			1	Focus			 50
Tran	Located_Origin			1	Waif			100
Tran	Located_Origin			1	Scavenge		100
Tran	Stabilized_Origin			1	Validate_Origin	100
Tran	Validated_Origin			1	Update_GUI		100
Tran	Invalidated_Origin		1	Delete		100
Tran	Deleted_Origin			1	Update_GUI		100

# Uncomment the next lines for more GUI updates / slower performance
#  Not currently supported
#Tran	STATE_PICK_ASSOCIATED	1	Update_GUI		100
#Tran	Unassociable_Pick		1	Update_GUI		100


## Old
#Tran	Assign		0	Associate	100
#Tran	Locate		1	Focus		100
#Tran	Locate		1	Waif		20
#Tran	Locate		1	Prune		100
#Tran	Locate		1	Scavenge	20
##Tran	Focus		1	Locate		100
#Tran	Waif		1	Locate		100
#Tran	Prune		1	Locate		100
#Tran	Scavenge	1	Locate		100
#Tran	Assign		1	Locate		100
#Tran	Associate	1	Locate		100
#Tran	Scavenged	1	Locate		100

Helpful Hints