• Antelope Release 5.10 Linux CentOS release 7.6.1810 (Core) 3.10.0 2020-05-12

 

NAME

rtexec_setup - setting up an rt processing node

DESCRIPTION

This describes how to set up a directory to run as a real time system node. Such a node is highly configurable, so this is not simply a matter of rote, but this gives a general outline of the procedure.

This presumes that the computer is already configured with the correct operating system, with the Antelope real time software installed under /opt/antelope, including perl and tcl/tk. It's often useful to have top(1), xcpustate(1) and less(1) installed also.

Initial Setup

A processing node is usually run in the home directory of a dummy user rt. Multiple people may have access to the rt account, to perform common maintenance operations. Begin, therefore, by creating the rt user account.

Next, make a subdirectory of ~rt to hold the processing for this network. We have found that a generalized name, such as rtsystems allows for flexibility in operations, particularly when more than a single processing node will be run. Then, within this subdirectory, create all the files and directories necessary to run the network.

The shortcut approach at this point is to run rtinit, which creates a number of directories, and copies in a number of parameter files. You must still at least create the master database, and customize the parameter files, however.

In a more complex installation, you might wish to have a central server for database ids, and use locks which allow machines which nfs mount the rt directory write access to the database (e.g., for dbloc2(1)). To accomplish this, you must

If more than one real time system is running on a single machine, the orbservers must use different ports. Specify a different port on the orbserver command line with the -p option, and use a hostname:port notation for the clients. The easiest method is to change the default definition of ORB in the Defines array from ":" to :ddddd: you choose the port number ddddd. This number must be greater than 2049, and less than 65537. It should be chosen to not conflict with other services. Most numbers are available, but it may be useful to look at /etc/services to make sure your choice is available.

You can also make this port number a name by editing the file $ANTELOPE/data/pf/orbserver_names.pf; this is more mnemonic, but the orbserver_names.pf file must be copied around to any machines which have separate installations of Antelope.

Ring Buffer

At least one ring buffer is needed per node. This ring buffer contains both the incoming data, and various processing results: detections, arrivals, and locations. Some systems may have additional orbservers for special purposes: a ring buffer for communicating with Quanterra dataloggers, or a separate ring buffer to separate and save low sample rate data for longer periods, for example.

Data input

Data may arrive in the ring buffer from a variety of sources, either directly from data loggers, from other ring buffers, or (in replay mode) from an existing database. Depending on the sources for this node, you may need to copy and edit the parameter files for datalogger import modules, like q3302orb(1) for Quanterra Q330 dataloggers. Other modules like orb2orb(1) (for copying from another orbserver) and dbreplay(1) (for copying from a database) don't require a parameter file.

Event Detection, Location and Magnitudes

Saving waveforms and locations

Try the Configuration

At this point, you are probably ready to try things out. Begin by running rtm(1). rtm complains if the directory structure is not what it expects.

After fixing any initial configuration problems, you should have a graphical window which has two large buttons Stop and Start. Press the Start button, and also press the Processing Tasks button below the top panel to open a panel which shows the individual tasks which make up this node.

When the Start button is pressed, rtm runs rtexec, which in turn starts up the Processes which were specified in the rtexec parameter file. Watching the Processing Tasks panel, you should see tasks starting up in the order they were specified in the parameter file.

Here you may discover additional problems if a program starts and immediately dies. Use the menu button under the task name to look at the log for the program to see why it failed, and fix the problem. If the command line is the problem, you can edit it using another of the menu options for that task.

Once all the programs are running properly, you may take some time to get the detection and location parameters properly configured. Typically, you should run dbloc2 to review the automatic locations.

Monitoring Operations

Once a processing node is properly setup, it should run independently and without too much trouble. However, it's important to monitor some aspects. The current condition is indicated by the real time monitor rtm(1) display; operators typically leave rtm running continuously on the computer running rtexec, along with an orbmonrtd displaying network waveforms.

It's also useful to run daily reports rtsys(1) and rtreport(1), which send email summarizing the previous day's performance. rtsys searches for problems and error messages in the log files, and reports on disk availability. rtreport summarizes the data returned, and the number of arrivals and events. These programs should be run from the rtexec crontab, typically sometime after midnight UTC, e.g. 2:00.

SEE ALSO

rtinit(1)
install_boot_scripts(1)
rt(5)
rtsetup(8)
rtm(1)
rtexec(1)
orbserver(1)
q3302orb(1)
orbdetect(1)
orbassoc(1)
orbevproc(1)
dborigin2orb(1)
orb2db(1)
orb2dbt(1)

AUTHOR

Daniel Quinlan
Printer icon