Changes between Version 8 and Version 9 of Example_Configurations


Ignore:
Timestamp:
11/16/11 18:45:34 (8 years ago)
Author:
branden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Example_Configurations

    v8 v9  
    2121Note that multiple message rings are used. There are two main reasons for this. One is conceptual: the configuration is easier to understand and maintain if different rings are used to carry related types of messages (and the diagram is easier to draw). The other is performance related: if the rate of message production into a single ring is too high, the computer may be unable to run all receiving modules quickly enough, with the result that some modules may miss messages of interest (note that this is a detectable error, and constitutes a system crash). Given contemporary processor speeds, this is generally no longer a problem. Missed messages do indicate that the hardware is being severely over-driven. 
    2222 
    23 Internal names: [wiki:Earthworm Earthworm] uses names to identify four types of system components. Each set is defined by a table of names and associated numeric values. In operation, the user creates the desired entries in these tables, and then uses the names in the configuration files. At run time, utilities are used to resolve the names to their respective numeric values. The four categories of names are: 
     23Internal names: Earthworm uses names to identify four types of system components. Each set is defined by a table of names and associated numeric values. In operation, the user creates the desired entries in these tables, and then uses the names in the configuration files. At run time, utilities are used to resolve the names to their respective numeric values. The four categories of names are: 
    2424 
    25  * '''Installation Ids:''' These are the names given to the various institutions that operate [wiki:Earthworm Earthworm] systems. It is the only set of names that is centrally administered. That is, installation names and the associated numeric values must be requested from Golden. The reason for this is that as Earthworms exchange data, only the Installation Id uniquely identifies the source of a message. This table is part of a compile-time C header file, .../include/earthworm.h. All other name sets are run-time; the defining tables are kept in .../run/params/earthworm.d. This file is read during system startup, and thus can be altered without recompiling any source code. The syntax of the table is as per standard [wiki:Earthworm Earthworm] parameter files (contributed by Carl). A # marks the start of a comment field. 
     25 * '''Installation Ids:''' These are the names given to the various institutions that operate Earthworm systems. It is the only set of names that is centrally administered. That is, installation names and the associated numeric values must be requested from Golden. The reason for this is that as Earthworms exchange data, only the Installation Id uniquely identifies the source of a message. This table is part of a compile-time C header file, .../include/earthworm.h. All other name sets are run-time; the defining tables are kept in .../run/params/earthworm.d. This file is read during system startup, and thus can be altered without recompiling any source code. The syntax of the table is as per standard Earthworm parameter files (contributed by Carl). A # marks the start of a comment field. 
    2626 
    27  * '''Message Rings:''' These are all the ring names known to the local [wiki:Earthworm Earthworm] system. The associated numeric values must be valid shared memory key values. This table is kept in [wiki:earthworm earthworm].d, and read by various utility routines at startup time. Each individual installation is free to define its own set if it so chooses. [wiki:Earthworm Earthworm] releases, however, include the default set. 
     27 * '''Message Rings:''' These are all the ring names known to the local Earthworm system. The associated numeric values must be valid shared memory key values. This table is kept in [wiki:earthworm earthworm].d, and read by various utility routines at startup time. Each individual installation is free to define its own set if it so chooses. Earthworm releases, however, include the default set. 
    2828 
    29  * '''Module names:''' These are all module names known to the local [wiki:Earthworm Earthworm] system. The conventions are as with Message Ring names. 
     29 * '''Module names:''' These are all module names known to the local Earthworm system. The conventions are as with Message Ring names. 
    3030 
    3131 * '''Message types:''' As with Module names above. 
    3232 
    33 The modules [wiki:copystatus copystatus] and [wiki:statmgr statmgr] are part of the [wiki:Earthworm Earthworm] error-processing scheme. The scheme offers two services: detection of lost heartbeats and individualized processing of various errors. Such processing includes use of pagers, email, permissible rates, limiting the number of notifications, and restarting the offending module. The scheme is optional in two ways: First, a given [wiki:Earthworm Earthworm] configuration may choose to not run [wiki:statmgr statmgr]. In this case, no system-wide error processing will be performed. Second, if [wiki:statmgr statmgr] is run, each module can decide whether to utilize the scheme. To participate, a module must do three things: 
     33The modules [wiki:copystatus copystatus] and [wiki:statmgr statmgr] are part of the Earthworm error-processing scheme. The scheme offers two services: detection of lost heartbeats and individualized processing of various errors. Such processing includes use of pagers, email, permissible rates, limiting the number of notifications, and restarting the offending module. The scheme is optional in two ways: First, a given Earthworm configuration may choose to not run [wiki:statmgr statmgr]. In this case, no system-wide error processing will be performed. Second, if [wiki:statmgr statmgr] is run, each module can decide whether to utilize the scheme. To participate, a module must do three things: 
    3434 
    3535First, submit to [wiki:statmgr statmgr] a file (.desc) containing processing instructions for the various errors that it can generate. This is done be creating such a file in the run/params/ directory, and making a corresponding entry in statmgrs parameter file (statmgr.d). 
     
    4141This configuration has three sources of trace data, all of which broadcast into a message ring named Wave_Ring: 
    4242 
    43 Four [wiki:reftek2ew reftek2ew] modules, each of which controls a communications line, receives trace data from a remote Reftek data logger, and broadcasts standard [wiki:Earthworm Earthworm] format trace data. 
     43Four [wiki:reftek2ew reftek2ew] modules, each of which controls a communications line, receives trace data from a remote Reftek data logger, and broadcasts standard Earthworm format trace data. 
    4444 
    4545A sun_demux module (now extinct), which receives trace data from University of Washington's own digitizer, demultiplexes it, and produces standard trace data messages, 
    4646 
    47 And an [wiki:import_generic import-generic] module: this is the long-distance message receiver. It communicates with its companion module export_scn via a TCP socket connection. Any type of [wiki:Earthworm Earthworm] messages can be shipped in this way; in this case, several channels of trace data are being received from Menlo Park. The shipping delay is on the order of several seconds, plus transmission time. 
     47And an [wiki:import_generic import-generic] module: this is the long-distance message receiver. It communicates with its companion module export_scn via a TCP socket connection. Any type of Earthworm messages can be shipped in this way; in this case, several channels of trace data are being received from Menlo Park. The shipping delay is on the order of several seconds, plus transmission time. 
    4848 
    49 The trace data messages must be in the standard internal [wiki:Earthworm Earthworm] format, as described in .../src/include/trace_buf.h. Briefly, this format consists of a header followed by a variable number of data samples, represented as either 16 or 32 bit signed integers in either byte order. This format supports two channel identification schemes: The dominant scheme consists of three ASCII strings defining the 'station', 'component', 'network', and 'location' (SCNL names). The second is the 'pin number'. This is an integer that can be used to identify the sensor and signal path of a channel. It addresses the case where a given sensor is acquired by two different telemetry paths. It also provides support for processing data from sensors that do not have SCNL names. 
     49The trace data messages must be in the standard internal Earthworm format, as described in .../src/include/trace_buf.h. Briefly, this format consists of a header followed by a variable number of data samples, represented as either 16 or 32 bit signed integers in either byte order. This format supports two channel identification schemes: The dominant scheme consists of three ASCII strings defining the 'station', 'component', 'network', and 'location' (SCNL names). The second is the 'pin number'. This is an integer that can be used to identify the sensor and signal path of a channel. It addresses the case where a given sensor is acquired by two different telemetry paths. It also provides support for processing data from sensors that do not have SCNL names. 
    5050 
    5151'''Four modules listen to the messages on the Wave_Ring:''' 
     
    6363 * [wiki:binder_ew binder_ew] is the event associator (conceived and written by Carl Johnson). This module listens to pick messages, and produces trial location messages as well as link messages that relate picks to trial locations (via sequence numbers). 
    6464 
    65  * [wiki:eqproc eqproc] is the first of a series of sub-modules that perform event locations via [wiki:hypoinverse hypoinverse]. The sub-modules are linked via operating system pipes, and as a group behave as an [wiki:Earthworm Earthworm] module. Briefly, their functions are as follows: [wiki:eqproc eqproc] assembles the trial locations produced by [wiki:binder_ew binder_ew] with the associated pick and coda messages produced by [wiki:pick_ew pick_ew], and if the event has not been recalled by [wiki:binder_ew binder_ew] within a time-out period, sends the assembled event parameters to [wiki:eqbuf eqbuf]. This acts as a buffer, in case events are produced faster than the remaining sub-modules can process them. From there it passes to [wiki:eqcoda eqcoda], which computes coda durations from the coda measurements generated by [wiki:pick_ew pick_ew]. It is then passed to [wiki:eqverify eqverify], which applies a series of sanity checks to eliminate spurious events. From there it is passed to hypo_mgr (extinct module, now hypo71_mgr and hypo2000_mgr), which is the encapsulation layer for [wiki:hypoinverse hypoinverse]. [wiki:hypoinverse hypoinverse] has not been modified for [wiki:Earthworm Earthworm]. The standard FORTRAN source code is used, permitting any future changes to [wiki:hypoinverse hypoinverse] to be directly inserted. The result of hypo_mgr is a message containing the standard [wiki:hypoinverse hypoinverse] arc file information. This message is broadcast into the Hypo_Ring. 
     65 * [wiki:eqproc eqproc] is the first of a series of sub-modules that perform event locations via [wiki:hypoinverse hypoinverse]. The sub-modules are linked via operating system pipes, and as a group behave as an Earthworm module. Briefly, their functions are as follows: [wiki:eqproc eqproc] assembles the trial locations produced by [wiki:binder_ew binder_ew] with the associated pick and coda messages produced by [wiki:pick_ew pick_ew], and if the event has not been recalled by [wiki:binder_ew binder_ew] within a time-out period, sends the assembled event parameters to [wiki:eqbuf eqbuf]. This acts as a buffer, in case events are produced faster than the remaining sub-modules can process them. From there it passes to [wiki:eqcoda eqcoda], which computes coda durations from the coda measurements generated by [wiki:pick_ew pick_ew]. It is then passed to [wiki:eqverify eqverify], which applies a series of sanity checks to eliminate spurious events. From there it is passed to hypo_mgr (extinct module, now hypo71_mgr and hypo2000_mgr), which is the encapsulation layer for [wiki:hypoinverse hypoinverse]. [wiki:hypoinverse hypoinverse] has not been modified for Earthworm. The standard FORTRAN source code is used, permitting any future changes to [wiki:hypoinverse hypoinverse] to be directly inserted. The result of hypo_mgr is a message containing the standard [wiki:hypoinverse hypoinverse] arc file information. This message is broadcast into the Hypo_Ring. 
    6666 
    6767 * As before, [wiki:copystatus copystatus] is used to conduct heartbeat and status messages from the Pick_Ring to the Hypo_Ring, where [wiki:statmgr statmgr] can hear them.