Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

First the effects of the fixed depth and the effects of the tides must be removed. The "detider" analyzes the most recent pressure readings as well as samples from each of the past 3 hours. The data is are analyzed using a third-order polynomial curve fitting algorithm in order to predict the next sample. The difference between the predicted value and the actual value is the output of the detider. Typically those values are close to 0 but when a tsunami arrives a non-zero signal is seen.

...

The final algorithm is a "not-a-tsunami" detector called a Seismic Wave Detector. Knowing that earthquakes cause shaking of the seafloor, which will cause the BPRs to shake and effectively create their own signals similar to what would be caused by ocean waves, this detector distinguishes between false alarms caused by seismic ocean crust waves and tsunami waves on the ocean surface. The first step is to compute a high pass filter to detect the seismic waves which have a higher frequency than tsunami waves. The output signal is improved using an STA/LTA method. The output of that is compared with a threshold.

For this particular BPR (only)any single BPR, a tsunami is declared if any 2 out of 3 tsunami detection algorithms exceed their thresholds within a certain time window and the Seismic Detector does not detect a seismic wave at the same time. This is the function of the Watcher.

The above process is repeated on each of the BPRs. Note that the BPRs are spaced far apart so they detect the tsunami at different times. The Correlator watches for a tsunami declaration from at least 3 BPRs. The correlation has two conditions - 1) the BPRs that have reported must be at least 15km apart from each other (to rule out false alarms), and 2) the arrival time of the tsunami at each BPR must occur within a certain time window relative to all other reporting BPRs. The time window is determined by the longest possible travel time of a tsunami between each BPR pair knowing the distance and the bathymetry between them, since the travel time of a tsunami depends on the bathymetry or the profile of the ocean depth. If all of these conditions are met the Correlator passes on the detection timestamp, the height of the tsunami wave at the time of detection, and the maximum height over a certain time window after detection, to the Event Notification process.


 

Event Notification

The Event Notification component allows ONC staff to define and activate events, to manually test events, and to allow others to subscribe to certain events and to decide how they wish to be notified. For WARN the two events that are most important are WARN Earthquake Detection and WARN Tsunami Detection.

...

As of April 2015 all event subscriptions are restricted to 1) those who have created an account in Oceans 2.0 (http://dmas.uvic.ca) AND 2) they have been given software permissions by ONC to allow them to subscribe to events (ie. a member of the Event Subscription group). Those meeting these conditions can subscribe to events on the Event Maintenance page of Oceans 2.0 at http://dmas.uvic.ca/EventMaintenance  under the Event Subscription tab - see below. Note that in the screenshot below you will see other WARN events. These are mainly for test purposes to analyze the output from the algorithms that contribute to the earthquake or tsunami detection. Unless you are trying to understand the internal workings of WARN we recommend that you only subscribe to WARN Earthquake Detection and/or WARN Tsunami Detection.


All events are logged and can be viewed on the Event Maintenance page under the Event Log tab. Here is an example of some test earthquake events. Note that the OriginTimes are in millisecond since 1970, also known as Unix Time. There are converters on the internet that can convert this to human readable date and time.


Notification Contents

The e-mails are sent using the CAP (Common Alerting Protocol) format. Here is an example. Note the fifth line, which will either use the word "Actual" for a real event, or "Test" for a manually generated test.
----

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <alert xmlns="urn:oasis:names:tc:emergency:cap:1.2">

...