Summary of our discussion of the event coordinator.
Desired, additional functionality.

1) Accomodate Md

Because the NC system cannot compute reliable Mls for all 
events, we need to continue the computation of Md.

Modifications to hyp2ps and the event coordinator are
required to support Md values delivered by eqproc.

2) Facilitate rapid magnitudes - eqprelim events

We want to facilitate rapid magnitudes (faster than waiting
for eqproc and the associated Mds).  The proposal is to 
use eqprelim events to trigger Ml/Me processing and then
report the magnitudes if they are reliable.

-- eqprelim events are generated hey reach the picks threshold
(typically 25), typically 30-50 secs after an event.  They will 
contain a preliminary location, but no magnitude information.
   Some eqprelim events will NOT be followed by eqproc events.

-- eqproc events are generated when they have aged sufficiently
to permit an estimate of duration magnitude, typically 2-4
minutes.
   Not every eqproc event will have an eqprelim solution.

Issues:
-Eqprelim/eqproc will need to forward delete messages from binder
      which in turn will be handled by the event coordinator.
-Event coordinator will insert eqprelim hypocenter information as
      one origin; add the eqproc hypocenter when available.
-Should the eqprelim track have its own version of trimag or
      should it utilize the "main track" which is first come,
      first serve?
-Do we need to keep track of version numbers?  Source (a hyp
coming from eqprelim as opposed to eqproc) might trigger different
activities (eg, don't want to start waveform retrieval until the
final version of the event).


3) Handle delayed data arriving in the rt system

Telemetry outages can lead to delayed data.  If enough stations
are affected - and the outage is long enough - picks from the
delayed stations may not associate with already declared events.
If there are enough picks, new events may be declared - potentially
duplicates of previously associated events or entirely new events.

What we want:
	If the event is older than the depth of the binder pick ring,
	we want to compare the new event with events already in the
	data base.

		If a match is made, could either
		-discard the hypocenter
		-include as a new orid, but not as the preferred

		If a match is not made, then it is a new earthquake.
		Process the event (trimag/ampgen/etc).  Issues here TBD
		on processing events older than the depth of the ADA.
		See (6).

	This could be implemented either by the event coordinator or by
	having the event coordinator pass "old events" off to a separate
	module that would handle the attempt to associate these hypocenters
	with events in the database.

4) Handle events coming from external sources

We will have several sources of events, including NEIC, Geysers, remote
EW systems, HRSN, etc.  

What we want:
	Import these events through a separate path.  Either the event
	coordinator or a new module would compare these external events
	with events in the database (similar to the functionality in (2)).
	
            If a match is made, could either
            -discard the hypocenter
            -include as a new orid, but not as the preferred

            If a match is not made, then it is a new earthquake.
		Depending on the source, process the event (presumeably
		we would not process teleseisms from NEIC but we would
		want to process events from the Parkfield waveserver).
            Issues here TBD on processing events older than the 
		depth of the rad. See (6).


5) Handle reviewed events

We need a way to reprocess events after a quick review (assuming a 
tool other than Jiggle).  The general model here is that a relocation 
needs to retrigger trimag/ampgen/etc.  Where should the revised hypocenters 
go?  Do they go into the hypo ring?  If so, we would need the event 
coordinator to have a longer memory in order to recognize a reviewed 
event.  Potentially, reviewed hypocenters could be handled by another 
module.  As with (2) and (3), we would want to process the event
with trimag/ampgen/etc, which raises the issue of the depth of the ADA.
Also issues here with respect to alarming, but we didn't discuss those.

6) ampgen/trimag

We either need to (a) modify ampgen and trimag so that they handle the situation
where the event is too old for the data in the ADA or (b) develop stand alone 
versions for this purpose.  Having (a) would be more robust, as it would reduce 
the need to have modules decide whether an event is "too old" for processing and 
would allow it to be handled in the normal way for other modules that rely 
on waveforms (Mw/MT, for example).  In principal, one program could do the
rad processing of the older waveforms, making the data available to trimag 
and ampgen.