Changes between Version 1 and Version 2 of glass


Ignore:
Timestamp:
05/29/12 11:51:09 (8 years ago)
Author:
branden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • glass

    v1 v2  
    22 
    33= [wiki:Earthworm Earthworm] Module: glass = 
    4 '''Contributed by: Carl Johnson and Dave Kragness''' 
     4'''Contributed by: Carl Johnson, Dave Kragness, Mitch Withers''' 
    55 
    66== Function == 
    77Carl Johnson's Global Associator. See the overview for the Glass Manual written for Hydra by Dave Kragness. (new in EW v7.0) 
    88 
    9 == Details == 
    10  
    11 == Configuration File Commands == 
    12 === Example glass.d === 
     9== Manual == 
     10This 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) 
     11 
     12Initial Blame: David Kragness, Hydra Development Team 
     13 
     14Mitch 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. 
     15 
     16=== Overview === 
     17 
     18Glass 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. 
     19 
     20This informal document contains four(4) sections oriented at different individuals 
     21 
     22 * The Seismologist/Network Operator section contains information on tuning Glass for your seismic network. 
     23 * The Hydra Administrator section provides information for the system administrator trying to configure Glass to run in an Hydra/Earthworm environment. 
     24 * The Programmer section contains information on the architecture of Glass code and notes for anyone looking to maintain/modify Glass. 
     25 * The User section contains minimal information on the interactive use of the Glass GUI displays. 
     26 
     27=== Seismologist/Network Operator === 
     28 
     29Glass 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. 
     30 
     31==== The Nucleator ==== 
     32 
     33===== Overview ===== 
     34 
     35The 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. 
     36 
     37Then, 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. 
     38 
     39===== Parameters Tunable ===== 
     40 
     41With 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. 
     42 
     43There are 6 sets of key tunable parameters in the Nucleator: 
     44 
     45 1. Location Points: number of and distance threshold. 
     46 2. Time windows for potential origins and associable picks 
     47 3. Size of the time iterations 
     48 4. Depth iterations 
     49 5. Travel time tables 
     50 6. Station List 
     51 
     52====== Location Points ====== 
     53 
     54A line similar to the following: 
     55 
     56'''Cut 9 50''' 
     57 
     58appears 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. 
     59 
     60====== Time Windows ====== 
     61 
     62A line similar to the following: 
     63 
     64TimeRange -600.0 500.0 -820.0 
     65 
     66appears 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). 
     67 
     68 
     69====== Time Iterations ====== 
     70 
     71A line similar to the following: 
     72 
     73TimeStep 5.0 
     74 
     75appears 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. 
     76 
     77 
     78====== Depth Iterations ====== 
     79 
     80Lines similar to the following: 
     81 
     82# Shells[[BR]] 
     83Shell 5.0[[BR]] 
     84Shell 20.0[[BR]] 
     85Shell 60.0[[BR]] 
     86Shell 100.0[[BR]] 
     87Shell 200.0[[BR]] 
     88Shell 400.0[[BR]] 
     89Shell 600.0 
     90 
     91appear 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. 
     92 
     93 
     94====== Travel-time Tables ====== 
     95 
     96The 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. 
     97 
     98The 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. 
     99 
     100Each traveltime table entry contains the following information: 
     101 
     102 * Traveltime 
     103 * Depth 
     104 * Distance 
     105 * Take Off Angle 
     106 * Time residual window half-width 
     107 * Horizontal Slowness of the phase (dtdx) 
     108 * Vertical Slowness of the phase (dtdz) 
     109 * Association Strength (Pick Probability Density - not currently used) 
     110 * Location Weight (used by the Glass Locator, not by the Hydra Locator) 
     111 * Mag. Threshold (not currently used) 
     112 * Phase Name 
     113 
     114The 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. 
     115 
     116====== Station List ====== 
     117 
     118The 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. 
     119 
     120Glass 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 
     121 
     122===== Parameters Untunable =====  
     123 
     124The 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. 
     125 
     126==== The Associator ==== 
     127 
     128===== Overview ===== 
     129 
     130The 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: 
     131 * Number of phases already associated with the origin; 
     132 * Azimuthal gap between associated P-phases; 
     133 * Residual for the current phase; 
     134 * Distance of the current phase relative to the median distance for the phases already associated with the origin. 
     135At 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): 
     136 * Picks already assigned to the origin 
     137 * Picks not assigned to any origin 
     138 * Picks assigned to a different origin 
     139For 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. 
     140 
     141For 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. 
     142 
     143For 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. 
     144 
     145===== Parameters Tunable ===== 
     146 
     147There are three sets of parameters that affect the Associator: 
     148 
     149 1. The traveltime tables 
     150 2. The station list 
     151 3. The affinity statistic coefficients 
     152 
     153The 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. 
     154 
     155====== Travel-time Tables ====== 
     156 
     157Please 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. 
     158 
     159In 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. 
     160 
     161 
     162====== Station List ====== 
     163 
     164The 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. 
     165 
     166 
     167====== Tunable Affinity Statistics Traveltime Tables ====== 
     168 
     169Traveltime 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. 
    13170{{{ 
    14  # Directory section  - allows you to select which directory glass will 
    15 #  look in for particutlar files. 
    16 # DLLs   - directory where glass will look for the Module DLLs specified below 
    17 #  This should not be needed if you put the bin directory in your "PATH" 
    18 #$ DLLs j:\src\usgs\home\earthworm\v6.2\bin\ 
    19 $ DLLs e:\ew\v7.0beta\bin\ 
    20  
    21 # DATA   - directory where glass will look for DATA files 
    22 $ DATA glass_data\ 
    23  
    24 # Module load section (load all modules before initializing parameters) 
    25 mod {DLLs}Network.dll 
    26 mod {DLLs}Flinn.dll 
    27 mod {DLLs}Earth.dll 
    28 mod {DLLs}Glint.dll 
    29 mod {DLLs}Glass.dll 
    30 mod {DLLs}Glock.dll 
    31 mod {DLLs}Solve.dll 
    32 mod {DLLs}ManQuake.dll 
    33 mod {DLLs}Grok.dll 
    34 mod {DLLs}Catalog.dll 
    35 mod {DLLs}Earthworm.dll 
    36 mod {DLLs}Summary.dll 
    37 mod {DLLs}Residuals.dll 
    38 mod {DLLs}Refocus.dll 
    39 #mod {DLLs}FocusGUI.dll 
    40 #mod {DLLs}FocusGUI_DP.dll 
    41 mod {DLLs}Publisher.dll 
    42  
    43  
    44 # enables nexus traffic monitor 
    45 DISPLAY 
    46  
    47 # Means: messages go to all modules 
    48 BROADCAST 
    49  
    50 # Processed by nexus.dll 
    51 Initialize 
    52  
    53 DISPATCH 
    54 # Turns on glass status window(glass.dll) 
    55 GlassMonitor 
    56  
    57 # associator param file (glass.dll) 
    58 GlassParams S:File={DATA}glass_assoc.d 
    59  
    60 # Hypo station list (network.dll) 
    61 HypoLoad S:File={DATA}glass.hinv 
    62  
    63 # Init file for earth module (tt code) (earth.dll) 
    64 TTInit S:File=tt_tables.d 
    65  
    66 # map base (grok.dll) 
    67 World S:Base={DATA}World.bmp 
    68  
    69 # glass pub params 
    70 PubAlgParams S:File={DATA}glass_pub_params.d 
    71  
    72 # Reporting params (glass.dll) 
    73 ReportInterval I:Interval=20 
    74  
    75 # Earthworm params (earthworm.dll) 
    76 RingIn S:Name=PICK_RING 
    77 RingOut S:Name=ASSOC_RING 
    78 HeartBeat I:Interval=30 
    79 ModuleId S:Module=MOD_GLASS_EW 
    80 LogFile 
    81  
    82 # NoFlushInput  - uncomment this line to prevent glass from flushing 
    83 #                 the earthworm input RING.  - not recommended 
    84                                                for normal operation 
    85 #NoFlushInput 
    86  
    87  
    88 # LOG_PICKS  -  Log picks to the glass_pick_log.txt file in EW_LOG dir. 
    89 LOG_PICKS 
    90  
    91 # LOG_ORIGINS - Log origins to the glass_origin_log.txt file in EW_LOG dir. 
    92 LOG_ORIGINS 
    93  
    94 # SHOW_PICKS -  Display new picks in the Map window (grok.dll) 
    95 SHOW_PICKS 
    96  
    97 # TERMINATE - uncomment this line to have glass terminate immediately after 
    98 #             processing the config file. 
    99 # TERMINATE 
    100  
    101  
    102 # Flinn Engdahl Regions 
    103 FlinnEngdahlLoad S:Dir={DATA} 
     171Phase   PKKPbc  PKKP 
     172DistRange        85      125 
     173DistDelta        2.5 
     174DepthRange       0       800 
     175DepthDelta       25 
     176TimeDelta        10 
     177RayParam         2.0     4.112 
     178LocWeight        0.05 
     179ResWinWidth      15.0 
     180}}} 
     181The 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. 
     182 
     183The 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: 
     184 * Traveltime 
     185 * Depth 
     186 * Distance 
     187 * Take Off Angle 
     188 * Time residual window half-width 
     189 * Horizontal Slowness of the phase (dtdx) 
     190 * Vertical Slowness of the phase (dtdz) 
     191 * Association Strength (Pick Probability Density - not currently used) 
     192 * Location Weight (used by the Glass Locator, not by the Hydra Locator) 
     193 * Mag. Threshold (not currently used) 
     194 * Phase Name 
     195 
     196===== Parameters - Untunable ===== 
     197 
     198Affinity Statistic 
     199 
     200Most 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: 
     201Affinity = Origin.Gap_Affinity * Origin.Number_of_Arrivals_Affinity * 
     202           Pick.Residual_Affinity * P.Distance_Affinity * Pick.PPD_Affinity 
     203Certain 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.) 
     204 
     205The component affinity statistics are generated in the following manner 
     206 
     207Origin.Gap_Affinity 
     208Value:          Origin.Gap_Affinity = 4 * Bellcurve_Value(Origin.Gap / 360) 
     209Description:    Origin.Gap is the maximum azimuthal gap between P phases 
     210                associated with the origin.  If the number of existing 
     211                associations is too small (currently defined as less than 
     212                OPCALC_nMinStatPickCount = 10), then Origin.Gap_Affinity 
     213                is set to 1.0. 
     214Range:          Artificially limited to 0.5 û 2.0.  (If the gap is 
     215                EXCRUSIATINGLY BAD (more than 325 degrees) then it is not 
     216                artificially limited.) 
     217Reason:         Gap is a crude measurement of the quality of the epicentral 
     218                location.  An origin with an azimuthal gap of 90 will generally 
     219                produce a more accurate location than an origin with a gap of 
     220                270, even if the number of phases associated with each origin 
     221                is the same. 
     222 
     223Origin.Number_of_Arrivals_Affinity 
     224Value:          Origin.Number_of_Arrivals_Affinity = log10(Origin.NumberOfPhases) 
     225Description:    DescOrigin.NumberOfPhases is the number of phases that were 
     226                used by the Locator to generate the latest hypocenter for this 
     227                Origin.  The affinity value is limited to a minimum of 1.0. 
     228Range:          Artificially limited to 1.0+ (Under the current NEIC network 
     229                2.5 is the realistic maximum based on 300 phase picks). 
     230Reason:         The number of arrivals associated with an origin is a crude 
     231                measurement of the magnitude of the quake.  This allows larger 
     232                quakes an improved chance of associating more phases.  This 
     233                aids in preventing splits where larger quakes can associate 
     234                phases even though they have large residuals, and in resolving 
     235                splits where larger origins can steal phases from smaller ones. 
     236 
     237Pick.Residual_Affinity 
     238Value:         Pick.Residual_Affinity = 
     239               2 * Bellcurve_Value(Pick.Residual / PhaseResidualWindowWidth) 
     240Description:   Breakeven point is one half the residual window width.  For the 
     241               default 10 second window, a residual of 5 seconds would net a 
     242               Residual_Affinity of 1. 
     243Range:         The range is 0 to 2, with no artificial limits. 
     244Reason:        The residual is the most key requirement in the association of 
     245               a Pick to an Origin.  You cannot associate a Pick as a P phase 
     246               if the pick delta time is not close to the theoretical 
     247               traveltime.  The affinity statistic allows picks that are 
     248               closer to the theoretical traveltime to garner an improved 
     249               affinity. 
     250 
     251Pick.Distance_Affinity 
     252Value:         Pick.Distance_Affinity = 
     253               Bellcurve_Value(Pick.Distance/(Median_Distance_Estimate*4)) 
     254Description:   Distance based filtering is a decent mechanism for excluding 
     255               coincidental picks that arenÆt generated by energy released by 
     256               a quake.  The distance affinity statistic prevents picks outside 
     257               of four(4) times the median distance from being associated with 
     258               this origin.  The value 4 is hardcoded as OPCALC_dCutoffMultiple. 
     259               The breakeven point is twice the median distance estimate; 
     260               however the median distance estimate is fudged for very small 
     261               earthquakes as well as for some larger ones.  For very small 
     262               earthquakes the median distance is multiplied by 1.5.  For 
     263               certain earthquakes that are located near the heart of the 
     264               network such that the median distance is kept low by the 
     265               non-uniformity of the network (for the NEIC, imagine a M5.0+ 
     266               earthquake located anywhere in the contiguous US), the median 
     267               distance is artificially inflated relative to the number of 
     268               phases associated with the origin.  This allows for PKP and 
     269               other associations that would otherwise be disallowed because 
     270               the median distance is only 15 degrees. 
     271Range:         The range is 0 to 2, with no artificial limits. 
     272Reason:        Distance is used as a sanity factor to prevent local or regional 
     273               quakes from associating with coincidental picks across the 
     274               globe, which have no energy from the quake associated with their 
     275               pick, and may corrupt the origin parameters. 
     276 
     277 
     278 
     279Composite Affinity 
     280 
     281 
     282 
     283 
     284Because the composite affinity statistic is a product of all the components, 
     285any affinity with a value of 0 automatically nixes the association.  The 
     286residual, dip, and distance affinity components can potentially have a value 
     287of 0.  So an association can be precluded because 1)the residual is too great; 
     2882) the distance is too great; 3) all of the picks are coming from a single 
     289direction(azimuthal gap). 
     290 
     291 
     292 
     293Assuming that none of those components preclude the association, then the 
     294composite affinity for the pick/origin must be above a minimum affinity 
     295threshold in order to be eligible for association.  That threshold value is 
     296hardcoded to 0.9 ( as OPCALC_dAffMinAssocValue). 
     297Note that to allow quakes to properly build, exceptions are made to how 
     298affinity statistics are computed for small earthquakes.  Currently small 
     299quakes are defined as those with less than 10 phases (hardcoded as 
     300OPCALC_nMinStatPickCount). 
     301 
     302 
     303 
     304Two examples: 
     305 
     306 
     307SNZO BHZ IU 00 reports a pick 329.1 seconds after an existing origin.  The 
     308origin has 138 phases, an azimuthal gap of 54 degrees, and a median distance 
     309of 83 degrees.  54 degrees results in a Gap_Affinity of 2.0.  138 phases 
     310results in a Number_of_Arrivals_Affinity of 2.14.  The theoretical traveltime 
     311for a P phase at SNZOÆs distance and the originÆs depth is 324.9 seconds, 
     312resulting in a residual of 4.25, resulting in a Residual_Affinity of 1.2. 
     313The distance of 24.9 degrees relative to the median distance of 83 results in 
     314a Distance_Affinity of 2.0.  The PPD is fixed at 1.0.  The composite affinity 
     315for this pick relative to the origin is 10.3 (2.0 * 2.14 * 1.2 * 2.0 * 1.0). 
     316It is greater than the minimum affinity requirement of 0.9, so it would be 
     317eligible for assignment to this origin and would very likely be assigned to 
     318it as the affinity is quite high. 
     319 
     320 
     321 
     322MTE BHZ GE --  reports a pick 1223.4 seconds after the same origin 
     323(138 phases, gap of 54 degrees, and median distance of 83 degrees). 
     32454 degrees results in a Gap_Affinity of 2.0.  138 phases results in an 
     325Number_of_Arrivals_Affinity of 2.14.  The theoretical traveltime for a 
     326PKPab phase at MTEÆs distance and the originÆs depth is 1215.0 seconds, 
     327resulting in a residual of 8.4, resulting in a Residual_Affinity of 0.14. 
     328The distance of 155.3 degrees relative to the median distance of 83 results 
     329in a Distance_Affinity of 1.1.  The PPD is fixed at 1.0.  The composite 
     330affinity for this pick relative to the origin is 0.66 
     331(2.0 * 2.14 * 0.14 * 1.1 * 1.0).  Because the affinity is below 0.90, this 
     332pick would not be eligible for assignment to the origin. 
     333 
     334 
     335 
     336 
     337 
     338Relevant Origin Time Range 
     339 
     340 
     341 
     342 
     343In it's primary role of trying to assign a new pick to its most likely origin, 
     344the Associator grabs only the origins that are time relevant to the pick.  The 
     345relevant origin time window relative to the pick time is hard coded.  It 
     346starts 2400 seconds pick (hardcoded as OPCALC_dSecondaryAssociationPrePickTime) 
     347prior to the pick and ends at the time of the pick. 
     348 
     349 
     350 
     351 
     352 
     353Relevant Pick Time Ranges For An Origin 
     354 
     355 
     356 
     357 
     358When the Associator runs in it's alternate scope of reevaluating how all of 
     359the time relevant picks associate with an origin after that origin has been 
     360modified, it uses various time windows.  (this is a bug/feature). 
     361 
     362 
     363 
     364Picks not assigned to any origin 
     365 
     366The Associator uses a pick time range of (Origin_Time - 2400 seconds to 
     367Origin_Time) (2400 seconds is hardcoded as 
     368OPCALC_dSecondaryAssociationPrePickTime) 
     369 
     370Picks assigned to a different origin 
     371 
     372The Associator uses a pick time range of (Origin_Time - 2000 seconds to 
     373Origin_Time)  (2000 seconds is hardcoded) 
     374 
     375 
     376 
     377 
     378 
     379 
     380The Locator 
     381 
     382 
     383 
     384 
     385 
     386 
     387Overview 
     388 
     389 
     390 
     391 
     392The Locator refines Origin parameters based on a least-squares inversion of 
     393the residual vectors for associated phases.  (or something like that)  The 
     394residual vectors are calculated based on the residual and azimuth from each 
     395pick along with the dtdx(horizontal slowness) and dtdz (vertical slowness) 
     396for the phase association. 
     397 
     398 
     399 
     400 
     401 
     402Parameters Tunable 
     403 
     404 
     405 
     406 
     407The Locator has two tunable parameters: the location weight of each phase 
     408(set in the traveltime tables), and the number of iterations it will run 
     409each time it is invoked. 
     410 
     411 
     412 
     413 
     414 
     415Location Weight 
     416 
     417 
     418 
     419 
     420The Location Weight is set in the traveltime tables.  See Tunable Affinity 
     421Statistics Traveltime Tables under the Associator section for a description 
     422of traveltime table parameters.  Setting LocWeight to a value will cause the 
     423Locator to apply that weight to picks of that phase.  The default weight 
     424is 1.0. 
     425 
     426 
     427 
     428 
     429 
     430Number of Iterations 
     431 
     432 
     433 
     434 
     435A line similar to the following 
     436 
     437NumLocatorIterations 3 
     438 
     439Can be placed in the glass_assoc.d config file. This line would cause the 
     440locator to be run for three iterations each time the Locator is invoked. 
     441The default is 1. 
     442 
     443 
     444 
     445 
     446 
     447Parameters Untunable 
     448 
     449 
     450 
     451 
     452The Locator has no untunable parameters. 
     453 
     454 
     455 
     456 
     457 
     458The Filter 
     459 
     460 
     461 
     462 
     463 
     464 
     465Overview 
     466 
     467 
     468 
     469 
     470The Filter is the portion of Glass that eliminates origins or pick-origin 
     471associations because they don't pass certain validity tests.  The Filter 
     472consists of a conglomeration of filters that are split into different portions 
     473of Glass.  They attempt to filter coincident origins and coincident 
     474pick-associations from the Glass output.  The filters can be thought of as 
     475falling into 3 groups:  core, network specific, and output. 
     476 
     477 
     478 
     479 
     480 
     481Core Filters 
     482 
     483 
     484 
     485 
     486The Core filters are very simple.  They ensure that existing origins and 
     487origin/pick associations don't violate the original association requirements. 
     488They are used to remove origins that don't have enough pick associations 
     489because the location has changed or because its picks have been stolen by 
     490another origin.  They are used to remove assigned picks because their affinity 
     491has dropped due to changes in the parameters of the origin. 
     492 
     493 
     494 
     495 
     496Validate Origin 
     497 
     498 
     499 
     500A filter will delete an origin if it discovers any of the following 3 
     501conditions: 
     502 
     503 
     504 
     505   
     506Number of phases associated with the origin dropped below the number 
     507  of points required by the Nucleator to create a new origin. 
     508 
     509   
     510Number of phases used by the locator to compute the latest hypocenter 
     511  for the origin dropped below the number of points required by the Nucleator 
     512  to create a new origin. 
     513 
     514   
     515Number of P phases associated with the origin drops below (number of 
     516  points required to nucleate - 1).  The -1 is added as a bit of a buffer 
     517  against excessive origin deletion. 
     518 
     519 
     520 
     521 
     522 
     523Validate Associations 
     524 
     525 
     526 
     527 
     528A filter will delete an origin / pick association (unassign the pick from the 
     529origin) if it discovers that the pick / origin affinity drops enough below the 
     530minimum association value to exceed a slop buffer (hardcoded as 
     531(OPCALC_dAffMinAssocValue - OPCALC_dAffinitySlop = 0.9 - 0.5 = 0.4 )  The 
     532substantial slop buffer was added for two reasons:  to prevent association 
     533oscillations for borderline picks (picks with affinity near the minimum 
     534association value); to encourage associated picks to stay associated even if 
     535the locator swings the origin in some direction that is not favorable to the 
     536pick. 
     537 
     538 
     539 
     540 
     541 
     542Network Specific Filters 
     543 
     544 
     545 
     546 
     547Glass contains several origin oriented network specific filters that are 
     548capable of invalidating a given origin.  The key reason for these filters is 
     549to overcome anomalies in network uniformity and density.  In the NEIC Hydra 
     550network, the lion's share of sensors are located in North America, such that 
     551tuning Glass to preclude coincident events in North America would also 
     552preclude many valid medium sized earthquakes in the rest of the world; 
     553tuning Glass to include those medium sized events would also cause many 
     554coincident/noise events in North America to be produced. 
     555 
     556 
     557 
     558The current set of filters defines 5 regions: 
     559 
     560 
     561 
     562   
     563The Inter-mountain West region (46,-104   -  37.5,-113) 
     564 
     565   
     566Western hemisphere (85,-140  -  45,-40) 
     567 
     568   
     569Northwest quadrant (85,-170  -  0,-40) 
     570 
     571   
     572North polar region (Lat > 70) 
     573 
     574   
     575Rest of the world 
     576 
     577 
     578 
     579 
     580For each of these regions the filter checks for a minimum number of quality 
     581P phases.  The criteria for a quality phase is a residual within 2 seconds 
     582of the predicted arrival time.  In regions 2 - 4, phases from the networks 
     583UU, IW, and MB are not allowed to count towards the minimum requirement. 
     584 
     585 
     586 
     587If the epicenter of the origin falls in regions 1 - 4, then the origin will 
     588be invalidated unless one of the following criteria is met:  
     589 
     590 
     591 
     592   
     59310 quality P phases are associated with the origin. (10 is hardcoded 
     594  as MIN_QLTY_ARR) 
     595 
     596   
     5974 quality short-range P phases are associated with the origin, where 
     598  short-range is defined as distance less than 10 degrees. (4 is hardcoded 
     599  as MIN_QLTY_CLOSEIN_ARR) 
     600 
     601 
     602 
     603 
     604If the epicenter of the origin falls outside regions 1-4 (inside region 5), 
     605then the origin will be invalidated unless there are at least x quality 
     606arrivals, where x = number of points required to nucleate / 2 
     607This is an integral equation, so if number of points is 8 then you need 5, 
     608if 9 then 5, if 10 then 6, in order to avoid invalidation. 
     609 
     610 
     611 
     612 
     613 
     614Output Filters 
     615 
     616 
     617 
     618 
     619Glass contains one final set of filters that do not have a dramatic effect 
     620on the world of Glass, but affect what information that Glass exports to the 
     621outside world.  There are several filters that run in the publishing module 
     622that periodically exports event messages to the rest of Hydra. 
     623 
     624 
     625 
     626 
     627Minimum Number of Phases 
     628 
     629 
     630 
     631 
     632A filter prevents the publication of origins that have fewer than the minimum 
     633number of associated phases, as defined by the MinNumPhases is the 
     634glass_pub_params.d config file.  Events that don't reach the threshold are not 
     635deleted inside of Glass, but they are never published by Glass to the outside 
     636world. 
     637 
     638 
     639 
     640 
     641Ancillary Phases 
     642 
     643 
     644 
     645 
     646A filter tries to prevent certain coincidental associations with an origin, 
     647by requiring a minimum number of a certain phase type before phases of that 
     648type are published.  The current hardcoded limit is 3, and S phases closer 
     649than 10 degrees and all P phases are immune to this restriction.  For example, 
     650if there are two PKPab phases (VLC and MTE), and 4 PKPdf phases (MORC, PSZ, 
     651WLF, and CSS) with an origin, then there will be NO PKPab phases published 
     652for that origin, but all 4 of the PKPdf phases will be published. 
     653 
     654 
     655 
     656 
     657Pdif Phases 
     658 
     659 
     660 
     661A filter prevents Pdif phases > 110 degrees from being published.  I 
     662don't think there is a GOOD reason for this;  however Pdif phases beyond 110 
     663degrees for the current picker are almost always coincidental associations. 
     664 
     665 
     666 
     667 
     668Old Events 
     669 
     670 
     671 
     672A filter prevents quakes older than a threshold number of days from being 
     673published.  A command OldestEventToPublish in the glass_pub_params.d config 
     674file controls the length of the threshold in days.  For example: a quake 
     675occurs on 09/01/05 at 11:00 UTC, and OldestEventToPublish is set to 5.0. 
     676The quake is not picked up until some late arriving data enters the system 
     677on 09/06/05 and 12:00 UTC.  Glass now associates the quake, but does not 
     678publish it because it has been 5.04 days since the origin time, which is 
     679beyond the 5.0 day threshold. 
     680 
     681 
     682 
     683 
     684Dead Events 
     685 
     686 
     687 
     688A filter prevents an origin from being published once it is dead.  The 
     689publishing module tracks an origin through its life cycle in Glass, publishing 
     690it over and over again as it changes.  At some point the Publisher deems the 
     691Origin stale and marks it as dead.  This was done with the idea that Glass has 
     692a certain scope of time within which it operates, and at some point in time 
     693Glass should acknowledge that the quake has gone out of time scope for 
     694automatic processing and is being handled further down the processing stream. 
     695 
     696 
     697 
     698 
     699Publication Rate 
     700 
     701 
     702 
     703The publication module controls how often glass updates the outside world on 
     704how an origin is progressing.  Publication rate is potentially affected by 
     705both the amount of change an Origin is going through and the amount of time 
     706that has occurred after the origin.  Publication in general is controlled by 
     707the glass_pub_params.d config file, and the controlling parameters are 
     708documented within that file. 
     709 
     710 
     711 
     712 
     713 
     714Other Stuff 
     715 
     716 
     717 
     718 
     719There are several other mechanisms within Glass that affect processing, but do 
     720not affect output to the degree of the major four.  The Depth Refocus module 
     721attempts to discover alternate hypocenter depths that elude the Locator.  The 
     722State Processing orchestrates how origins and picks are processed by Glass. 
     723 
     724 
     725 
     726 
     727Depth Refocus 
     728 
     729 
     730 
     731Depth Refocus is a module that searches for an improved origin depth and 
     732time that cannot be discovered by the Locator.  Refocus assumes a correct 
     733epicenter, and does a depth/time grid search for a potentially better 
     734depth/time combination.  Refocus module utilizes all time-relative picks as 
     735input, regardless of their origin assignment status.  It attempts to associate 
     736each pick as either a P or pP phase for the origin at each point in the 
     737time/depth grid.  It was created to get the Locator out of local residual 
     738minima.  Currently there are no tunable parameters in the Focus module. 
     739 
     740 
     741 
     742 
     743State Processing 
     744 
     745 
     746 
     747Glass contains a state processing engine that controls how picks and origins 
     748are processed.  The engine is entity oriented where an entity is either a 
     749pick or an origin.  It's operation is configured by Tran commands in the 
     750glass_assoc.d config file.  At this point State Processing configuration is 
     751considered to be an engineering issue and is not meant to be modified by a 
     752seismologist/network operator. 
     753 
     754 
     755 
     756 
     757 
     758Hydra Administrator 
     759 
     760 
     761 
     762 
     763This section to be filled in later with information regarding how to configure 
     764Glass to run in a Hydra/Earthworm near real-time environment. 
     765 
     766 
     767 
     768 
     769 
     770Configuring Glass 
     771 
     772 
     773 
     774 
     775 
     776 
     777glass.d 
     778 
     779 
     780 
     781 
     782 
     783 
     784Error Reporting 
     785 
     786 
     787 
     788 
     789Glass, by default writes 3 levels of status messages: 
     790 
     791 
     792 
     793   
     794MAJOR ERROR 
     795  There are 39 Major Errors.  They include things like: 
     796 
     797   
     798 
     799     
     800Can't open config file. 
     801 
     802     
     803Can't load DLL (Module) 
     804 
     805     
     806Can't allocate memory 
     807 
     808     
     809Can't load traveltime tables 
     810 
     811     
     812Can't get EW message types 
     813 
     814     
     815Can't  access required module 
     816 
     817     
     818Can't attach to shared memory 
     819 
     820     
     821Can't create internal messages 
     822 
     823     
     824Can't parse config file command 
     825 
     826     
     827Can't write to temporary files. 
     828 
     829   
     830 
     831   
     832MAJOR WARNING 
     833  There are 3 Major Warnings 
     834  They are reserved for times when glass gets "CONFUSED" internally.  It 
     835  continues to operate, but wants you to know that you may regret it in the 
     836  morning. 
     837 
     838   
     839MINOR ERROR 
     840  There are somewhere around 90 Minor Errors.  They cover everything under the 
     841  sun, including Missed Messages, and so forth so on, and are a general catch 
     842  all for stuff that the operator or programmer may want to know about. 
     843 
     844 
     845 
     846 
     847To make matters more complicated, while the internal error levels are 
     848hardcoded in the code, the way glass reacts to them (i.e. what glass reports 
     849and how) is completely configurable via the .d files.  So you could (while not 
     850recommend it) configure glass via the .d file, to issue status messages for 
     851each DEBUG/INFO message and not issue them for any of the Major Errors. 
     852 
     853 
     854 
     855From the default glass.d file: 
     856 
    104857 
    105858#  DebugLevel commands 
     
    135888#  Example: 
    136889#  EarthwormDebugLevel  I:Level=2 I:OTF=1 I:OTD=0 I:OTE=0 I:OTS=0 I:OSM=0 
     890 
     891 
     892 
     893 
     894 
     895User 
     896 
     897 
     898 
     899 
     900This section to be filled in later with information regarding how to operate 
     901the Glass displays including the ManQuake display for manually testing a 
     902hypothetical hypocenter. 
     903 
     904 
     905 
     906 
     907 
     908Programmer 
     909 
     910 
     911 
     912 
     913This section to be filled in later with information regarding the 
     914architectural layout of Glass, along with notes on how to maintain/modify it. 
     915 
     916 
     917== Configuration File Commands == 
     918=== Example glass.d === 
     919{{{ 
     920 # Directory section  - allows you to select which directory glass will 
     921#  look in for particutlar files. 
     922# DLLs   - directory where glass will look for the Module DLLs specified below 
     923#  This should not be needed if you put the bin directory in your "PATH" 
     924#$ DLLs j:\src\usgs\home\earthworm\v6.2\bin\ 
     925$ DLLs e:\ew\v7.0beta\bin\ 
     926 
     927# DATA   - directory where glass will look for DATA files 
     928$ DATA glass_data\ 
     929 
     930# Module load section (load all modules before initializing parameters) 
     931mod {DLLs}Network.dll 
     932mod {DLLs}Flinn.dll 
     933mod {DLLs}Earth.dll 
     934mod {DLLs}Glint.dll 
     935mod {DLLs}Glass.dll 
     936mod {DLLs}Glock.dll 
     937mod {DLLs}Solve.dll 
     938mod {DLLs}ManQuake.dll 
     939mod {DLLs}Grok.dll 
     940mod {DLLs}Catalog.dll 
     941mod {DLLs}Earthworm.dll 
     942mod {DLLs}Summary.dll 
     943mod {DLLs}Residuals.dll 
     944mod {DLLs}Refocus.dll 
     945#mod {DLLs}FocusGUI.dll 
     946#mod {DLLs}FocusGUI_DP.dll 
     947mod {DLLs}Publisher.dll 
     948 
     949 
     950# enables nexus traffic monitor 
     951DISPLAY 
     952 
     953# Means: messages go to all modules 
     954BROADCAST 
     955 
     956# Processed by nexus.dll 
     957Initialize 
     958 
     959DISPATCH 
     960# Turns on glass status window(glass.dll) 
     961GlassMonitor 
     962 
     963# associator param file (glass.dll) 
     964GlassParams S:File={DATA}glass_assoc.d 
     965 
     966# Hypo station list (network.dll) 
     967HypoLoad S:File={DATA}glass.hinv 
     968 
     969# Init file for earth module (tt code) (earth.dll) 
     970TTInit S:File=tt_tables.d 
     971 
     972# map base (grok.dll) 
     973World S:Base={DATA}World.bmp 
     974 
     975# glass pub params 
     976PubAlgParams S:File={DATA}glass_pub_params.d 
     977 
     978# Reporting params (glass.dll) 
     979ReportInterval I:Interval=20 
     980 
     981# Earthworm params (earthworm.dll) 
     982RingIn S:Name=PICK_RING 
     983RingOut S:Name=ASSOC_RING 
     984HeartBeat I:Interval=30 
     985ModuleId S:Module=MOD_GLASS_EW 
     986LogFile 
     987 
     988# NoFlushInput  - uncomment this line to prevent glass from flushing 
     989#                 the earthworm input RING.  - not recommended 
     990                                               for normal operation 
     991#NoFlushInput 
     992 
     993 
     994# LOG_PICKS  -  Log picks to the glass_pick_log.txt file in EW_LOG dir. 
     995LOG_PICKS 
     996 
     997# LOG_ORIGINS - Log origins to the glass_origin_log.txt file in EW_LOG dir. 
     998LOG_ORIGINS 
     999 
     1000# SHOW_PICKS -  Display new picks in the Map window (grok.dll) 
     1001SHOW_PICKS 
     1002 
     1003# TERMINATE - uncomment this line to have glass terminate immediately after 
     1004#             processing the config file. 
     1005# TERMINATE 
     1006 
     1007 
     1008# Flinn Engdahl Regions 
     1009FlinnEngdahlLoad S:Dir={DATA} 
     1010 
     1011#  DebugLevel commands 
     1012#  CatalogDebugLevel | EarthwormDebugLevel | GlassDebugLevel | GlintDebugLevel | LocatorDebugLevel | PublisherDebugLevel 
     1013#    Level:  0-9 
     1014#           MAJOR_ERROR 0 
     1015#           MAJOR_WARNING 1 
     1016#           MAJOR_INFO 2 
     1017#           MINOR_ERROR 3 
     1018#           MINOR_WARNING 4 
     1019#           MINOR_INFO 5 
     1020#           FUNCTION_TRACE 9 
     1021# 
     1022#    OTF : OutputToFile 
     1023#    OTD : OutputToDebugger 
     1024#    OTE : OutputToError 
     1025#    OTS : OutputTimeStamp 
     1026#    OSM : OutputStatusMessage 
     1027# 
     1028#  Format: 
     1029#  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} 
     1030# 
     1031#  Default values:  {OTF,OTD,OTE,OTS,OSM} 
     1032#  {1,1,1,1,1},  // MAJOR ERROR 
     1033#  {1,1,1,1,1},  // MAJOR WARNING 
     1034#  {1,1,0,0,0},  // MAJOR INFO 
     1035#  {1,1,1,1,1},  // MINOR ERROR 
     1036#  {1,1,1,0,0},  // MINOR WARNING 
     1037#  {0,0,0,0,0},  // MINOR INFO 
     1038#  {0,0,0,0,0}   // FUNCTION TRACE 
     1039 
     1040# 
     1041#  Example: 
     1042#  EarthwormDebugLevel  I:Level=2 I:OTF=1 I:OTD=0 I:OTE=0 I:OTS=0 I:OSM=0 
    1371043EarthwormDebugLevel  I:Level=4 I:OTF=1 I:OTD=1 I:OTE=1 I:OTS=1 I:OSM=1 
    1381044GlassDebugLevel  I:Level=5 I:OTF=1 I:OTD=1 I:OTE=1 I:OTS=1 I:OSM=1