Changes between Version 12 and Version 13 of Installation_and_Configuration


Ignore:
Timestamp:
11/16/11 13:11:33 (10 years ago)
Author:
branden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Installation_and_Configuration

    v12 v13  
    1313  
    1414 
    15 == 1. DETERMINE THE DESIRED FUNCTIONS == 
     15== 1. Determine the Desired Functions == 
    1616 
    1717Earthworm currently offers the following general features: 
     
    4545  
    4646 
    47 == 2. ESTIMATE THE HARDWARE REQUIREMENTS == 
     47== 2. Estimate the Hardware Requirements == 
    4848 
    4949Earthworm has been developed under the mandate of speed and reliability. It therefore tends to use fast, low-level operating system services rather than high-level end-user packages. A side effect of this is that Earthworm is fairly economical in terms of hardware requirements. In general, a contemporary Pentium- or Ultra- class machine is adequate for most regional network loads. Specifically, the hardware requirements can be divided into four categories: 
     
    6767  
    6868 
    69 == 3. PRODUCE A TEST EVENT == 
     69== 3. Produce a Test Event == 
    7070 
    7171This is an optional step which has proven to be extremely useful in rapidly producing a reliable configuration in low-seismicity areas. It will not be needed until testing, but the effort should be initiated early to produce a timely result. The procedure is to find a suitable past event recorded on digital media, and to convert this to an Earthworm 'player' file. Earthworm includes a 'player' module ([wiki:waveserverV waveserverV]) which can be used to repeatedly inject the trace data of the event to test the operation of the system. 
     
    7575  
    7676 
    77 == 4. PRODUCE A NETWORK STATION LIST == 
     77== 4. Produce a Network Station List == 
    7878 
    7979* Request an FDSN network code by submitting the form at http://www.fdsn.org/forms/netcode_request.htm. This two-letter code is used throughout the system as part of the trace data naming convention. It is also essential if any data exchange with other networks is contemplated. 
     
    8787  
    8888 
    89 == 5. CREATE THE Earthworm SOFTWARE DIAGRAMS == 
     89== 5. Create the Earthworm Software Diagrams == 
    9090 
    9191For each node, draw a diagram showing modules, message rings, and message paths. Examples are given at [wiki:Example_Configurations Example Configurations]. The diagram should include: 
     
    103103  
    104104 
    105 5.1 Earthworm NAMING SCHEME (BACKGROUND): 
     1055.1 Earthworm Naming Scheme (Background): 
    106106 
    107107There are four types of names within the Earthworm system: "Installation Id", "Module Id", "Message Type", and "Ring Name". Each type of name is represented as an ASCII string at the human interface level, but is resolved to a numeric value when the system is running. The motivation for the naming scheme is that 
     
    129129  
    130130 
    131 == 6. LOAD THE Earthworm SOFTWARE == 
     131== 6. Load the Earthworm Software == 
    132132 
    133133The Earthworm Directory Structure: 
     
    175175  
    176176 
    177 == 7. CREATE THE RUN DIRECTORIES == 
     177== 7. CReate the /run Directories == 
    178178 
    179179It is recommended that each node have the same directory structure. This is not required, but has been found useful in simplifying maintenance and updates. 
     
    187187  
    188188 
    189 == 8. CONFIGURE THE Earthworm ENVIRONMENT FILES == 
     189== 8. Configure the Earthworm Environment Files == 
    190190 
    191191* The [wiki:earthworm_global earthworm_global].d file should contain your Installation Id. Contact Mitch Withers at [http://www.ceri.memphis.edu/index.shtml CERI] (Center for Earthquake Research and Information, University of Memphis, USA), who acts as control for this file. Local editing of this file is possible, but will prevent the installation form exchanging data with other sites. 
     
    209209  
    210210 
    211 == 9. MODULE CONFIGURATION == 
     211== 9. Module Configuration == 
    212212 
    213213For each module within a node you will need to create a parameter (.d) and an error processing file (.desc). Samples of these files are in the source directory for each module (e.g. c:\earthworm\v#.#\src). 
     
    229229  
    230230 
    231 === 9.3 OTHER MODULES === 
     231=== 9.3 Other Modules === 
    232232 
    233233The Earthworm release currently includes over 100 modules. However, several key modules are discussed below: 
     
    259259  
    260260 
    261 == 10. INITIAL STARTUP ==  
     261== 10. Initial Startup ==  
    262262 
    263263After all modules are configured, the system can be started. 
     
    271271* The window should display a list of modules and their status, as produced by "startstop" pressing 'enter' will re-display this list. The window will also display any error messages from modules which are sharing this window (see below). 
    272272 
    273 == 11. DEBUGGING TOOLS AND HINTS == 
     273== 11. Debugging Tools and Hints == 
    274274 
    275275In the startstop configuration file ([wiki:startstop_nt startstop_nt].d), each module which is to be run has a "!NewConsole" / "!NoNewConsole" specification. This determines whether the module's standard output is written to its own command window or into the window used to start the system. For initial testing, it is recommended to set all these to "!NoNewConsole". In routine operation, individual windows are convenient for checking on system status. During initial debugging, however, modules tend to exit due to gross configuration errors (typical are invalid "Module Id" and "Ring Name" values). Under Windows 2000 this causes the window of the deceased module to vanish, carrying with it the module's error messages. The "!NoNewConsole" setting permits the user to analyze terminal error messages. 
     
    287287  
    288288 
    289 == 12. COMMON CONFIUGRATION ERRORS == 
     289== 12. Common Configuration Errors == 
    290290 
    291291* Module ID: 
     
    311311  
    312312 
    313 == 13. INCREASING THE NUMBER OF SHARED MEMORY RINGS UNDER SOLARIS == 
     313== 13. Increasing the Number of Shared Memory Rings Under Solaris == 
    314314 
    315315Under Solaris 2.6 (and probably other versions as well), the maximum number of shared memory segments is six. This means that on an out-of-the-box machine you can only configure six rings. If you try to configure more than that, you will see a cryptic message from tport_create about too many open files. The fix to this problem is to add the following lines to the /etc/system file, and then reboot the system.