The CUSP Backlog Problem
------------------------
We have a bunch of CUSP .grm files which have not been reviewed.
We would like to get all of them "loaded" into the database
so that analysts can review them using Jiggle. The sooner we
can do this, the sooner we can get rid of CUSP!

We are given two lists:
1. CUSP .GRM & .MEM
    Files of waveform data collected for subnet triggers, not yet
    reviewed by analysts. No hypocenter information is included.
    All channels start/end at approximately the same time.
    Trigger time ~ earliest start time + 30 sec.

2. Automatic Events
    Events detected by the realtime associator, consisting of a
    hypocenter and associated pick/coda data, but no waveforms.
    These events are already loaded in "the database."


Step 1: Associate Events/GRMs, Load into Database
-------------------------------------------------
For each event, find the GRM file which contains the waveforms for that
event. When a match is found, associate all complete waveforms in the
GRM with the event (these waveforms were already grouped together for
a reason, so let's keep them together!). Keep tabs on which GRMs and
events have been associated. In the end, we will find these cases:

1. GRM matches one event
    Simplest case. Associate all of the waveforms in the GRM with that event!

2. GRM matches multiple events
    GRM file will be "cloned" and associated with all events that match.
    This means that duplicate copies of the GRM will exist. This is exactly
    what happens when CUSP timers find more than one event in a single GRM.

3. GRM matches no events
    A "trigger" event will be created in the database and all the
    waveforms of the GRM will be associated with it. Somehow, Jiggle
    will be able to access these "trigger" events.
  * This will likely require some modifications to the schema and
    maybe jiggle?

4. Event matches one GRM.
    Easy.

5. Event matches multiple GRMs.
    Choose the GRM which most closely matches. Easy to say. Might choose the
    GRM whose trigger time is closest to the event origin time. Or might have
    to compare picks with GRM waveforms and find the GRM that has the
    most pairs.

6. Event matches no GRM
    Event must be a garbage association, throw it away.
    This what happens now after a month is deemed to be "complete" by CUSP,
    right?


Step 2: Analyst Review
----------------------
Jiggle will now be able to access all of the GRM waveforms, either by an
automatic eventid or a trigger eventid.

1. Automatic event review
When reviewing waveforms for an automatic event, analysts may discover that
there is another event visible in the waveforms. This event could be:
a. another automatic event (case 2 above).
    This event will already exist in the DBMS with its own associated 
waveforms
    associated, and should be reviewed separately.
b. an event that was never detected by binder.
    In this case, the analyst should declare/time a new event within jiggle.
    Somehow, magically, jiggle will make sure the event and associated 
waveforms
    get stashed away in the database.
The analyst must carefully review the catalog to decide which course of action
to take with each multiple event.

2. "Trigger" event review
These waveforms were not associated with any automatic events, so we're not
really sure what they contain.  They could contain:
a. one or more real earthquakes.
    Any and all events that are timed out of a "trigger" event will be
    "new" events. For each event in a trigger, the analyst should declare a new
    event within jiggle and have jiggle stash it into the DBMS when review is
    complete for the event.
b. noise/garbage.
    These triggers/waveforms should be removed from the DBMS.

That's it! All done.