Learning Center
Plans & pricing Sign in
Sign Out

V. Web Interface


									                     Duty Review Page (DRP)

I.    Overview

    This is a description of the Duty Review Pages (DRP) used by SCSN duty
seismologists to review and modify automatic event solutions. Using this interface an
Duty Seismologist can review event waveforms to determine if the current solution in the
database is correct. The interface allows various actions to be taken which will directly
and immediately affect the database and alarm actions.

    The DRP can be broken down into two functional parts: 1) processes to create and
deliver waveform snapshots and 2) scripts to create and display web pages and carryout
user actions initiated from those the web interface. In addition, there are two version of
the DRP web interface – one to accommodate the smaller form factor and limited
function of the SideKick device and one with more functionality for use with desktop
browsers (described here). When possible, both versions share the same scripts.

II. Redundant Architecture
       For robustness there are two independent and redundant streams of processing that
create snapshots for the DRP. There are also two independent web servers. All
components of a processing stream are located together in one or the other of the SCSN
computer rooms. The notion of which of these streams is “primary” can change day-to-
day, however, under normal operational conditions the duty seismologist can work on
either server – it makes no functional difference.

        Function                 Processing Stream #1            Processing Stream #2
Physical Location                 USGS Yellow House             S. Mudd Telemetry Room
RT event creation                       pacific                         atlantic
Archive Database                      makaludb                            k2db
Snapshot creation                        nickel                         amosite
Web server                              craton                             rift
CMS server                               rtem1                           rtem1
III. Snapshot Generation

    An event snapshot is a graphics image in gif
format that shows 120 seconds of waveform for the
closest 15 stations with phase picks. (These values
can be modified.) The waveforms are sorted by
distance from the hypocenter and plotted on a
constant time scale with no moveout (i.e. it is not a
record section). Waveform amplitudes are autoscaled
to the full height of each channel’s graphics panel.
Optionally, green “phase queues” may appear at the
times of the calculated P and S-wave arrivals. Red
flags show the time and description of the actual
phase picks used in the current solution. Additional
phases beyond the 15 channels shown my also have
contributed to the solution.

   Waveforms are color coded by type.

Waveform Color Key:
      Black: broad-band, high-gain, digital channel
      Brown: broad-band, low-gain, digital channel
      Blue: short-period, “analog” channel

Process Control System
When events are inserted into the database or are modified they are posted to a PCS state
that causes them to be acted on by the web page creation scripts.

You can manually resubmit an event with:

> post <evid> EventStream <dbase-machine> MakeGif

Where <evid> is the event’s ID number and <dbase-machine> is either one of the dbases
machines associated with a DRP processing stream; “k2”or “makalu” (see the description
of processing streams above.)

When an event is processed it is ‘resulted’ (given a result code) which will cause it to
either transition to another state or be removed from the PCS, depending on how
transition states are configured.
Snapshot Creation Scripts
Scripts are found in /home/tpp/drp/bin. The makeDRPcont script is started by a ‘cron’
job of user ‘drp’ that runs every 10 minutes. If the cron job does not find the The DRP gif
creation script runs continuously.

This script is run as a cron job to check the existence of the makeDRPcont process. If it is
missing it will be restarted.

This is a continuously running script that drives the creation and publishing of SnapShot
.gifs. At intervals (default = 30sec) it looks for events posted to a particular state in the
Process Control System (PCS) (see above). When an event is found it’s “age” is checked.
Events greater than a threshold value (default = 7 days) are not processed. This is to
prevent creating gifs for old, historic events that are retimed or reprocessed in batch

This script deletes old gif files (default > 7 days), both locally and on the web servers it
publishes to. It also reports regularly to the Big Brother system.

The script writes a log to /home/tpp/drp/event/makeDRP.log which is closed out at

Event Snapshot – To make a snapshot gif the script runs the Java program SnapGif that
creates the event gif file. File names are of the form <evid>.gif. The script then copies
the file, via ssh, to the web servers. The local gif files are written to

The behavior of the SnapGif program is controlled by a Java properties file
/home/tpp/drp/bin/properties_event and by variables set in the makeDRPcont script.

Synopsis Snapshot – If the event exceeds a magnitude threshold (default=3.0) the script
creates a “synopsis” snapshot gif that shows a set list of channels that span the network.
This is done with the Java program SnapShotFromList. This is useful as a network
overview in the case where an event is badly mislocated. This snapshot is published to
the DRP web servers. Synopsis file names are of the form <evid>_synops.gif.

The behavior of the SnapShotFromList program is controlled by a Java properties file
/home/tpp/drp/bin/properties_synopsis and by variables set in the makeDRPcont

Web page creation directory structure

      /home/tpp/drp
          o /bin – scripts
           o /event – drp event files
                   /gifs – event and synopsis gif files
           o /trigger – drp trigger files

Supporting Environment

The following are required to support gif creation.

      Perl 5.8 or higher with DBI and POSIX libraries installed
      Java Runtime Environment 1.4 or higher + jiggle.jar, acme.jar
      Several supporting scripts in /home/tpp/bin including:
           o snapgif
           o synopsgif
           o eventAge
           o eventMag
      PCS system scripts
           o next
           o result
      Oracle client environment
      mailx
      ssh with keys on target web servers
      Big Brother scripts
      Cleanup scripts in local and target directories

IV. Web Interface

   The web interface is hosted on two servers:

    (located in the
       telemetry room of S. Mudd)
    (located in the
       USGS Yellow House)

The web server directory structures, files, and
behavior are identical on the two servers.

The partner database used by each web server is
set for all scripts in the file cgi-
bin/phpmods/db_conn.php. Note that this is
NOT the same concept as the “masterdb”.

Active scripts can be broken into three groups:
      Web page creation scripts
      Action scripts
      Support scripts and modules

Web page creation scripts

The DRP is a set of three frames controlled by HTML and JavaScript. Unless otherwise
noted all scripts are found in /home/htdocs/trinet/review/cgi-bin. The following scripts
create the DRP contents.

Frame creation scripts and html
This is the entry point. It defines the frame sizes, positions and names and calls cgi-

Queries the database and creates the catalog frame (lower) contents. Prints events >3.0 in
red. Creates a hyperlink for each event ID. Creates a JavaScript array of ID numbers for
internal use. Calls the JavaScript function selectNewEvid($evid) to select the most recent
event in the list (top of the list). Only 3 days of “local” events are shown in the list. If an
event is deleted it will disappear from the list when the frame is refreshed.

Creates event-specific contents for the two upper frames.
    Calls makeSnapshotFrame.php to create the snapshot view in the waves (upper
       left) frame.
    Calls makeButtonPanel.php to create the contents of the button frame (upper
       right). The selectNewEvid($evid) function is also called when the user clicks a
       hyperlinked event ID in the catalog list or uses the arrows in the button panel.

Dynamically creates the contents of the waves frame (upper left). Checks for a synopsis
gif and adds it if it exists.
     Checks for synopsis view, Recent Earthquakes page, ShakeMap page and DYFI
        and adds links if they exist.
     Dumps text summary of event’s history (/home/tpp/bin/eventhist <evid>)
     Dumps list of alarm actions from both RT and DB dbases.

Dynamically create the contents of the button frame (upper right). The style of the
button panel is defined using a Cascading Style Sheet (css) called buttonpanel.css. The
         Looks up and writes current time and event info
         Creates buttons
         Checks for synopsis view and adds links if it exists.

What the Buttons do (and how they do it)

The Accept, Cancel, and Delete buttons all call the
JavaScript routine
doAction.php?EVID=<id>&ACTION=<action>” which is
located in cgi-bin/phpmods/event_actions.php. Each button
inserts the appropriate ACTION argument. This php routine
calls other routines to accomplish the desired actions.

   1. sets Event.rflag = “H” in the dbase (makaludb &
        k2db) to indicate the event has been human reviewed.
   2. sends event alarm message to the CMS system. This
        should result in reevaluation of the event by the
        postprocessing version of the alarm system and the
        sending of revised alarms.
   3. writes log entry

  1. Calls “jasi.accept_Event ($_evid)” stored procedure in the server’s partner dbase.
  2. Calls “/home/tpp/alarm/bin/alarmsendCMS” to send the CMS message.
  3. Writes log entry to: /home/htdocs/trinet/review/logs/review.log

   1. sends event cancellation message to the CMS system. This should cause both the
        RT and the postprocessing versions of the alarm system to cancel any event
        messages they had sent earlier. Note that some alarm actions may not be
        cancelable. The alarm system will not send cancellation messages for old event
        (>7 days?).
   2. writes log entry

  1. Calls “/home/tpp/alarm/bin/alarmcancelCMS”
  2. Writes log entry to: /home/htdocs/trinet/review/logs/review.log

   1. sets Event.selectFlag = “0” in the dbase (makaludb & k2db) to indicate the event
      has been deleted.
   2. sends event cancellation message to the CMS system. This should cause both the
      RT and the postprocessing versions of the alarm system to cancel any event
      messages they had sent earlier. Note that some alarm actions may not be
      cancelable. The alarm system will not send cancellation messages for old event
      (>7 days?).
   3. writes log entry

  1. Calls “jasi.delete_Event ($_evid)” stored procedure in the server’s partner dbase.
  2. Calls “/home/tpp/alarm/bin/alarmcancelCMS”
  3. Writes log entry to: /home/htdocs/trinet/review/logs/review.log

               (Arrow buttons)
        Display next event up or down the catalog listing. Will wrap if it hits either the
top or bottom of the list.

       Move one entry up or down in the catalog frame’s internal array of event IDs.
Then calls the selectNewEvid($evid) function.

   1. Presents a new window with a list of allowed event
        types: Local, Regional, Teleseism, Quarry blast and
   2. Clicking a type sets the event’s type in the dbase.
   3. Writes a log entry
   (Note: alarms are not resent)

  1. Calls “makeSetTypePage.php” to create new frame.
  2. Calls “setEventType.php” which calls the call “jasi.setEventType($evid, $type)”
     stored procedure in the database.
  3. Writes log entry to: /home/htdocs/trinet/review/logs/review.log

   1. Presents Location/Magnitude editing panel to allow user input to form
   2.            check that entered values are valid and commit changes to dbase. Bad
        entries will be described and the form repainted if errors are present.
  3.            reset form values back to original
  4.            close panel, make no changes to event

  1.   Calls “locEditPanel.php”
  2.   Calls various php library functions.
  3.   HTML form feature
  4.   HTML form feature
   1. Put e-mail editing panel in the upper-right
        frame allowing user to edit and send
        preformatted email message.

  1. Calls “makeEmailPanel.php” which call
     php library function that call the stored

   1. Show the last 50 log entries for this Duty Review Page (note that actions
        performed on the alternate DRP server (rift/craton) are not visible.)

  1. Calls “logAsHtml.cgi” which dumps the contents of a the command “tail -50
     ../logs/review.log” to a new window.

To top