Publications

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

This document contains 10 use cases generated from the rnodel contained in Rational Software Architect.

This document contains 4 use case realizations generated from the model contained in Rational Software Architect.

This document contains 10 use cases generated from the model contained in Rational Software Architect.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

This architecturally significant use case describes how the Analyst refines an event hypothesis. The Analyst checks waveform quality (see 'Determines Waveform Data Quality' UC). For waveforms of sufficient quality, the Analyst enhances signals and suppresses noise on waveforms for relevant stations (see 'Enhances Signals' UC), adds and associates missing detections, and modifies or unassociates detections already associated with the event hypothesis (see 'Detects Signals' UC). The Analyst rejects event hypotheses that are invalid. For valid event hypotheses, the Analyst measures signal features associated with the detections (see 'Measures Signal Features' UC) and evaluates the moment tensor ('Evaluates Moment Tensor' UC). The Analyst uses these signal features to refine the location (see 'Refines Event Location' UC) and magnitude (see 'Refines Event Magnitude' UC) of the event hypothesis. The Analyst compares events to determine how similar events were constructed (see 'Compares Events' UC). The Analyst repeats these steps until satisfied with the results. Analysts may provide feedback for previous Analysts during any of these steps (see 'Provides Analyst Feedback' UC). This use case is architecturally significant because it captures the interplay between all of the Analyst activities.

This architecturally significant use case describes how the System User observes the change history of a given event. The change history is a series of one or more saved event hypotheses. System Users view all the event hypotheses and the set of location solutions for each hypothesis. The System User views the relationship between event hypotheses including the preferred hypothesis for each processing stage. The event change history persists across work sessions for subsequent review. This use case is architecturally significant because it covers review of stored versions of event hypotheses

This architecturally significant use case describes how the Analyst compares events to determine how similar events were constructed. The Analyst compares waveforms from comparison events by visually inspecting an overlay of the waveforms to determine if the events are from a similar source. The Analyst searches for comparison events or creates agglomerative hierarchical clusters of waveforms from events and determines that the events are from a similar source if the correlation coefficient is above a selected threshold. This use case is architecturally significant due to the introduction of the capability to compare events within an operational context.

This architecturally significant use case describes how the System refines event hypothesis location solutions. The System locates events by finding the event location minimizing the difference between signal detection feature measurements and signal detection feature predictions (see 'System Measures Signal Features' UC). The System references both empirical knowledge from past events and geophysical models to form the signal detection feature predictions. The System also computes an uncertainty bound for each event hypothesis location solution describing a region bounding the event hypothesis' hypocenter and origin time at a particular confidence level. The System creates a variety of location solutions for each event hypothesis. These location solutions vary from one another in either the input parameters the System uses or in the location solution components the System restrains to fixed values (e.g. depth) during event location calculations. The System computes location solutions using input parameters configured by the System Maintainer (see ‘Configures Processing Components’ UC). The Analyst has the option to override input parameters originally configured by the System Maintainer (see 'Refines Event Location' UC). This use case is architecturally significant due to the processing and memory resource consumption of 3D earth model calculations.

Abstract not provided.

This document contains the brief descriptions for the actors and use cases contained in the IDC Use Case Model. REVISIONS Version Date Author/Team Revision Description Authorized by V1.0 12/2014 SNL IDC Reengineering Project Team Initial delivery M. Harris V1.1 2/2015 SNL IDC Reengineering Project Team Iteration I2 Review Comments M. Harris

This document contains the system specifications derived to satisfy the system requirements found in the IDC System Requirements Document for the IDC Reengineering Phase 2 project. Revisions Version Date Author/Team Revision Description Authorized by V1.0 12/2014 IDC Reengineering Project Team Initial delivery M. Harris V1.1 2/2015 IDC Reengineering Project Team Iteration I2 Review Comments M. Harris