Changes between Version 1 and Version 2 of Overview


Ignore:
Timestamp:
11/11/11 16:44:28 (10 years ago)
Author:
branden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Overview

    v1 v2  
    11[[PageOutline]] 
    22 
    3 = [wiki:earthworm Earthworm] Overview = 
     3= [wiki:Earthworm Earthworm] Overview = 
    44 
    55== History == 
    66 
    7 The [wiki:earthworm Earthworm] project was started in 1993, mainly in response to a number of common needs identified by regional seismic networks: The automatic processing systems used by most regional networks were aging, and maintenance costs were growing; advances in seismic research required data from new, sophisticated sensors in order to provide viable research data; growing demands for immediate societal utility called for new and highly visible real-time products; and finally, shrinking funding meant that most individual networks could no longer support local system development efforts. 
     7The [wiki:Earthworm Earthworm] project was started in 1993, mainly in response to a number of common needs identified by regional seismic networks: The automatic processing systems used by most regional networks were aging, and maintenance costs were growing; advances in seismic research required data from new, sophisticated sensors in order to provide viable research data; growing demands for immediate societal utility called for new and highly visible real-time products; and finally, shrinking funding meant that most individual networks could no longer support local system development efforts. 
    88 
    99Most of the processing systems then in use had a number of drawbacks which made it difficult to enhance them to meet the new requirements: They were built on vendor-specific products, which tied them to high-price vendors, and deprived them of the benefits of the rapidly growing mass market. They tended to be tightly integrated, in the sense that functionally unrelated parts of the system shared a common resource, such as processor cycles, internal data paths, or peripheral devices. This resulted in systems that were difficult to modify, as changes to one function could cause malfunctions in an unrelated area. 
    1010 
    11 The initial [wiki:earthworm Earthworm] effort had the specific mission of replacing the aging Rex Allen / Jim Ellis Real Time Pickers (RTPs) at Menlo Park. These devices had functioned well for decades and had become the mainstay of Menlo Park's ability to produce rapid event solutions. However, replacement parts were no longer available, and there was an urgent need to produce a replacement system in minimum time. This meant producing a system which could process over five hundred channels of data quickly and reliably. 
     11The initial [wiki:Earthworm Earthworm] effort had the specific mission of replacing the aging Rex Allen / Jim Ellis Real Time Pickers (RTPs) at Menlo Park. These devices had functioned well for decades and had become the mainstay of Menlo Park's ability to produce rapid event solutions. However, replacement parts were no longer available, and there was an urgent need to produce a replacement system in minimum time. This meant producing a system which could process over five hundred channels of data quickly and reliably. 
    1212 
    1313In response to this, a delegation from Menlo Park was dispatched to present these problems to Carl Johnson, then at the University of Hawaii. Carl had produced many, if not most, of the seismic processing systems to date. The hope was that having been instrumental in creating the current situation, he might be in position to assist us in getting out of it. The visit bore fruit. Carl provided a number of ideas and algorithms that became the core of a new, common real-time seismic processing system. 
    1414 
    15 Since the initial objective of this system was to provide rapid notification of seismic events, the system that evolved had no 'memory' of past events. The emphasis was on speed and reliability, and an event was completed when the system produced a notification. As the project progressed, however, we were requested to address additional needs, such as interactive review of acquired events, association of late-arriving data, incorporation of strong motion data, and production of catalogs and archive volumes. This interactive [wiki:earthworm Earthworm] as initially part of early 6.x versions and then abandoned. [wiki:earthworm Earthworm] currently (as of 2011) has no interactive review. 
     15Since the initial objective of this system was to provide rapid notification of seismic events, the system that evolved had no 'memory' of past events. The emphasis was on speed and reliability, and an event was completed when the system produced a notification. As the project progressed, however, we were requested to address additional needs, such as interactive review of acquired events, association of late-arriving data, incorporation of strong motion data, and production of catalogs and archive volumes. This interactive [wiki:Earthworm Earthworm] as initially part of early 6.x versions and then abandoned. [wiki:Earthworm Earthworm] currently (as of 2011) has no interactive review. 
    1616 
    1717  
     
    3636== System Architecture == 
    3737 
    38 Carl Johnson also provided a system architecture which implemented the above design goals. This basic scheme was developed by the [wiki:earthworm Earthworm] team at Menlo Park, and resulted in the scheme described below. 
     38Carl Johnson also provided a system architecture which implemented the above design goals. This basic scheme was developed by the [wiki:Earthworm Earthworm] team at Menlo Park, and resulted in the scheme described below. 
    3939 
    40 An [wiki:earthworm Earthworm] system consists of a set of modules 'immersed' in a message passing 'medium'. Each module performs some coherent task, such as data acquisition, phase picking, etc. Modules communicate by broadcasting and receiving various messages such as packets of trace data, phase picks, etc. The message passing scheme is analogous to radio communications: It consists of a message-carrying 'medium' and a set of standard routines which can be thought of as multi-frequency two-way radios operating in this medium. Modules can use these routines to broadcast messages into this medium on a specified 'frequency', and to 'tune in' to messages on specified 'frequencies'. Significant properties of this scheme are that: (1) a module cannot be prevented from broadcasting a message whenever it chooses; (2) any number of modules can listen in to some sending module(s) without affecting that module; (3) a module receives only the messages of interest to it and it is notified if it missed a message. 
     40An [wiki:Earthworm Earthworm] system consists of a set of modules 'immersed' in a message passing 'medium'. Each module performs some coherent task, such as data acquisition, phase picking, etc. Modules communicate by broadcasting and receiving various messages such as packets of trace data, phase picks, etc. The message passing scheme is analogous to radio communications: It consists of a message-carrying 'medium' and a set of standard routines which can be thought of as multi-frequency two-way radios operating in this medium. Modules can use these routines to broadcast messages into this medium on a specified 'frequency', and to 'tune in' to messages on specified 'frequencies'. Significant properties of this scheme are that: (1) a module cannot be prevented from broadcasting a message whenever it chooses; (2) any number of modules can listen in to some sending module(s) without affecting that module; (3) a module receives only the messages of interest to it and it is notified if it missed a message. 
    4141 
    42 This 'medium' (the [wiki:earthworm Earthworm] transport layer) operates within one computer as well as between different computers. Standard TCP/IP network broadcasts (UDP) are used to carry a batch of messages between computers and shared memory regions are used to simulate such broadcasts within a computer. Each participating computer can be equipped with multiple network ports and multiple shared memory regions. Special adapter modules are used to link the message flows between a shared memory region and a network cable. Thus an [wiki:earthworm Earthworm] system can be configured to have a geometry of message passing paths tailored for a specific application, operating on any number of computers. Note that this scheme operates within one [wiki:earthworm Earthworm] system, spanning a maximum distance of several hundred meters. Message exchange between remote [wiki:earthworm Earthworm]s is handled by a different mechanism. The selective 'frequencies' of this 'medium' are implemented by attaching 'shipping tags' to all messages. They specify the module which created the message, the type of message it is, and the installation where the [wiki:earthworm Earthworm] system is running. Thus, for example, a message may be labeled as being a p-pick produced by the Rex Allen picker at Menlo Park, or a location produced by Hypo-inverse at Seattle. These tags are then used by the receiving routines to provide only the desired messages to a listening module. 
     42This 'medium' (the [wiki:Earthworm Earthworm] transport layer) operates within one computer as well as between different computers. Standard TCP/IP network broadcasts (UDP) are used to carry a batch of messages between computers and shared memory regions are used to simulate such broadcasts within a computer. Each participating computer can be equipped with multiple network ports and multiple shared memory regions. Special adapter modules are used to link the message flows between a shared memory region and a network cable. Thus an [wiki:Earthworm Earthworm] system can be configured to have a geometry of message passing paths tailored for a specific application, operating on any number of computers. Note that this scheme operates within one [wiki:Earthworm Earthworm] system, spanning a maximum distance of several hundred meters. Message exchange between remote [wiki:Earthworm Earthworm]s is handled by a different mechanism. The selective 'frequencies' of this 'medium' are implemented by attaching 'shipping tags' to all messages. They specify the module which created the message, the type of message it is, and the installation where the [wiki:Earthworm Earthworm] system is running. Thus, for example, a message may be labeled as being a p-pick produced by the Rex Allen picker at Menlo Park, or a location produced by Hypo-inverse at Seattle. These tags are then used by the receiving routines to provide only the desired messages to a listening module. 
    4343 
    44 The modules are independent main programs. Each module has free use of the file system and other system facilities. However, the [wiki:earthworm Earthworm] system offers several suites of support routines that can be used by the program to make it a compliant [wiki:earthworm Earthworm] module. One such suite is the collection of message passing routines (transport routines). These are used to acquire input data by requesting messages of certain type(s), and to broadcast output messages. Another set of routines is used to effect operating system independence by providing a common set of 'wrapper' routines for system-specific functions. For example, the system routines for starting a thread are different on Solaris and NT; the [wiki:earthworm Earthworm] system provides routines for both systems with the same name and arguments. Thus, if a program uses that routine, it can run on either operating system: the proper system-specific version of that routine will be automatically inserted when the program is built. This suite currently contains such 'wrappers' for all common functions. Routines are added as required. Moving [wiki:earthworm Earthworm] to a new operating system involves creating a new set of such 'wrapper' routines. [wiki:earthworm Earthworm] currently offers 'wrappers' for OS/2, Solaris, and Windows NT. 
     44The modules are independent main programs. Each module has free use of the file system and other system facilities. However, the [wiki:Earthworm Earthworm] system offers several suites of support routines that can be used by the program to make it a compliant [wiki:Earthworm Earthworm] module. One such suite is the collection of message passing routines (transport routines). These are used to acquire input data by requesting messages of certain type(s), and to broadcast output messages. Another set of routines is used to effect operating system independence by providing a common set of 'wrapper' routines for system-specific functions. For example, the system routines for starting a thread are different on Solaris and NT; the [wiki:Earthworm Earthworm] system provides routines for both systems with the same name and arguments. Thus, if a program uses that routine, it can run on either operating system: the proper system-specific version of that routine will be automatically inserted when the program is built. This suite currently contains such 'wrappers' for all common functions. Routines are added as required. Moving [wiki:Earthworm Earthworm] to a new operating system involves creating a new set of such 'wrapper' routines. [wiki:Earthworm Earthworm] currently offers 'wrappers' for OS/2, Solaris, and Windows NT. 
    4545 
    46 Modules generally read a configuration file at startup time. This file contains basic [wiki:earthworm Earthworm] parameters which define the module, specify which message 'medium' (message ring) it wishes to listen to, and which message ring it wishes to broadcast it's output messages to. In addition, this file can contain arbitrary operating parameters specific to its operation. 
     46Modules generally read a configuration file at startup time. This file contains basic [wiki:Earthworm Earthworm] parameters which define the module, specify which message 'medium' (message ring) it wishes to listen to, and which message ring it wishes to broadcast it's output messages to. In addition, this file can contain arbitrary operating parameters specific to its operation. 
    4747 
    48 Error detection is accomplished via several mechanisms: Any module may broadcast an error message. Such messages are forwarded to a special module (StartStop), which takes appropriate actions based on the nature of the complaint. Each module can also provide a periodic heartbeat; if this heartbeat should cease an error would then be declared and processed. A module may also request to be restarted if its heartbeat should cease. In addition, the [wiki:earthworm Earthworm] as a whole can produce a heartbeat to an external monitoring device. Such a monitoring device, capable of generating pager messages, is available as part of the [wiki:earthworm Earthworm] system. 
     48Error detection is accomplished via several mechanisms: Any module may broadcast an error message. Such messages are forwarded to a special module (StartStop), which takes appropriate actions based on the nature of the complaint. Each module can also provide a periodic heartbeat; if this heartbeat should cease an error would then be declared and processed. A module may also request to be restarted if its heartbeat should cease. In addition, the [wiki:Earthworm Earthworm] as a whole can produce a heartbeat to an external monitoring device. Such a monitoring device, capable of generating pager messages, is available as part of the [wiki:Earthworm Earthworm] system. 
    4949 
    5050 
    5151 
    5252== Developers == 
    53 [wiki:earthworm Earthworm] development team was originally headed by Alex Bittenbinder and coordinated by Barbara Bogaert; both with the U.S. Geological Survey (USGS).  Funding for this release was provided by the USGS and many other contributors. 
     53[wiki:Earthworm Earthworm] development team was originally headed by Alex Bittenbinder and coordinated by Barbara Bogaert; both with the U.S. Geological Survey (USGS).  Funding for this release was provided by the USGS and many other contributors. 
    5454 
    55 Principal [wiki:earthworm Earthworm] development is now provided by members of the the Earthworm Community.  
     55Principal [wiki:Earthworm Earthworm] development is now provided by members of the the Earthworm Community.  
    5656 
    57 In 2005, [http://www.isti.com/products/earthworm ISTI] and [http://www.ceri.memphis.edu/index.shtml CERI] (University of Memphis) have taken on lead roles in software development and user support of [wiki:earthworm Earthworm]. Please join the Earthworm community by coming an active developer (join ewdev-subscribe @ isti . com) mailing list. 
     57In 2005, [http://www.isti.com/products/earthworm ISTI] and [http://www.ceri.memphis.edu/index.shtml CERI] (University of Memphis) have taken on lead roles in software development and user support of [wiki:Earthworm Earthworm]. Please join the Earthworm community by coming an active developer (join ewdev-subscribe @ isti . com) mailing list. 
    5858Send any bug reports or configuration problems to the earthw mailing list. 
    5959