11/11/2004 - Some revisions/comments/questions from the Northern California group with a lot of additional comments from Pete. -------------------------------------------------------------------- Here are some magnitude specifications as heard by Paul and modified by the NC crowd. Look for "NC note:". 1. A generator of magnitudes should insert its results into the database 2. A generator of magnitudes should not set a preferential magnitude (should not set event.prefmag field in db) NC note: Does there need to be a database table to record the preferred magnitude of a given type (the preferred Ml, etc)? If so, what program should make those entries, the magnitude generators or the magnitude coordinator? 3. A generator of magnitudes should signal another process to coordinate the preference of magnitudes once its magnitude is published to the db (That is, a magnitude generator should publish its magnitude as soon as its available). 4. The coordinator of magnitudes (mc) should have some criteria and rules to govern the preferential selection of magnitudes (Ml, Md, Me, Mw) Rules TBD 4a. mc should write its preference to the event.prefmag table 4b. mc should be triggered by the publishing of a magnitude NC note: The term "publishing" is confusing here: does it mean "entering the information in the database" or "publishing a message to CMS"? 4c. mc should chose a preferred magnitude immediately upon the publishing of a magnitude value (that is, NO DELAYS in releasing a preferred magnitude). Update's later will fix any early mag problems. NC note: What about manual over-rides? Is this part of the rule set or is it handled some other way? 5. A coordinator of magnitudes should activate an alarm decision making process whenever a prefered magnitude is chosen in the db. 6. each automatic magnitude preference selection should increment the event.version NC note: Is this version number intended to be used as the QDDS version number? 7. historical versions of preferred magnitudes should be maintained in the db 7a. likewise historical versions of preferred mecs, preferred origins should be too. Each preferred selection should increment the version of the event view. NC note: What does this mean? Does it mean the any magnitude that was ever a preferred magnitude in the life of an event should not be deleted from the database (but other magnitudes could be deleted)? This presumably could be done with few or no changes to the schema. Or does it mean that the time history of an event and all its preferred origins, magnitudes, mechanisms should be maintained? This could be done, for example, by changing the primary key of the event table to (evid, version number) and adding start and end times to the event table. 8. alarm decisions should allow new criteria to be based on magnitude type. (e.g., Alarm if preferred magnitude is "ANY, Mw, Ml, Md, Me, fast-Md") A preference on mag type is needed to account for early Mag calculations that might saturate at certain mag levels and thus alarming might have saturation criteria for different M types. NC note: The alarm system needs to be changed to allow event location and magnitude to change between the time an alarm decision is made and and alarm is distributed. Currently the alarm system is asynchronous but assumes that the event does not change once the alarm system is first notified of an event 9. Md calculations should be made faster 2-3 minutes after hypo (note that trimag is currently 16-20 seconds after hypo, and UCB mentioned that 144 seconds duration was minimum needed, but that they have 150 seconds of cross network travel time to account for as well (4-4.5 minutes after an event OT.) NC note: Maybe. We're not sure there was concensus on this. One option is to have the EC wait the "usual" amount of time. That would result in a "complete" Md that may be based on a "slightly" different hypocenter from the one forwarded by the EC after 90 sec. That complete Md may be between 2-4 minutes after event origin time. Alternatively, take the Md at 90 sec and run - which is what Paul's note suggest. The advantage is consistency in the hypocenter, the disadvantage is the poor or incomplete Md for larger events. The advantage of waiting is that it provides a more complete view of the earthquke - the Md can be compared with other magnitudes for consistency. How would the revised hypocenter be handled (insert in database - does it require any further action? - see below) Addition from Pete: There are two time delays in eqproc that control the release of the event. One (configurable with the rpt_dwell parameter) controls how long eqproc waits for the binder location to be stable. The second one (hard coded at 150 seconds) is the time to wait for coda messages to arrive. This is based on the 144 seconds pick_ew waits for coda decay before it gives up and passes the decay values to eqcoda for coda estimation. 144 seconds of coda duration corresponds to Md of about 4.0; surely we don't care about Md for that large an event. I think we could shorten the wait for codas to around 100 seconds (Md ~ 3.6) Can we shorten the rpt_dwell time (I believe this is 60 seconds now)? See attached figure for my plot of Md vs coda duration, using the Md relations in hypo2000 and Menlo Park's configuration. Along the same lines, we would want the system to be able to handle the eqprelim hypocenters (generated when a solution reaches 25 picks). In our current system, these are distributed to qdds and show up as event locations without magnitudes. The functionality we would want to see is: Insert eqprelim hypo in database Generate alarm action (qdds notification) Another possible function would be to trigger the Ml/Me computation, and, depending on the reliability of those accelerated estimates, distribute a preliminary estimate of magnitude. Based on discussion here, the additional functionality of triggering an Ml/Me computation does not appear to buy much, so the idea of just generate QDDS notification. However, that aside, what should the Ml, moment tensor, and amplitude programs do when the event location is updated? This may happen while the event is being processed by these programs: should they discard their results and try again instead of recording the results in the database? If these programs have finished and recorded their results, should they repeat their calculations and record the possibly revised results? Presumably a simple rule can be established for how much a location must change before Ml, Mw and amplitudes need to redone. -------------------------------------------------------------------- Some implementation suggestions/comments that I heard were: 1. Md could easily be incorporated in EC and it makes the most sense to have an EC thread publish the Md when it is available (because the binder_id to evid mapping exists here). NC note: Another issue we discussed was the implication of the multiple magnitudes - and multiple hypocenters - on the alarming thread. 2. Mw can be introduced at any time in the cycle and the solution is much more stable than the TMTS CMT. NC note: ?? 3. Trimag should have the current business rules removed once a magnitude coordinator is built. NC note: We assume you mean "the current business rules for choosing Ml or Me as the preferred magnitude" as opposed to some other rules used by trimag. 4. The selection of preferred mag, origin, or mec should activate a database trigger or stored procedure to increment the version number AND also store a historical snapshot of the "previous version" in a transaction table. NC note: How much journaling is needed? hypos, mags, mechs, ... amps? 5. The magnitude coordinator should probably be a database centric solution that involves an INSERT TRIGGER on the netmag table that launches a STORED PROC to update the event.prefmag field. 6. Likewise, the updating of the version number and the maintenance of historical versions of preferred event items to a database table (event_history?) should be done by a stored procedure that sees updates to the version number via an UPDATE TRIGGER on the event table. NC note: Items 5 & 6 - We think the mc should run outside of the DBMS. The mc should be triggered CMS, perform all the appropriate actions including increment the version number, and then commit. We're concerned with activities getting out of sync if the mc is a DBMS trigger. 7. If the magnitude coordinator is done via TRIGGERS and STORED PROCS, then the alarm decision process needs to be signaled from the database. That is, a stored proc must be able to issue a CMS signal externally. Research needs to be done on this to determine if it is possible. NC note: We are concerned about the implications of the multiple magnitudes - and potentially multiple hypocenters - on the alarming thread.