====== Duty Review Procedures ====== ===== Background ===== * ** Response thresholds ** - Bay Area: M3 and higher - Northern California: M3.5 and higher * ** Make sure you have an account for the Duty Review Pages ** * ** Sign up at ENS for text earthquake notifications. It's useful to have: ** - Bay Area (predefined) M3 and higher - California (you could use several of the pre-defined or make your own polygon) M3.5 and higher - Western US (this can be in the eye of the beholder but I use M 4.0 and higher day time and 5 night time) - https://earthquake.usgs.gov/ens/ * ** Text messaging the name of the game (pagers have been retired!) ** - A set of four-five texts are issued each day (two at noon from the two systems in Menlo Park and two-three at 3:30 PM from the two-three systems in Berkeley). ===== Overview ===== - Bring up the EHP earthquake pages (https://earthquake.usgs.gov/) and check to see if the event is showing. - Log into the Duty Review Page * The preference is to log into the primary system because there can be delays in replication of the moment tensor solution. You can check which system is primary by looking at which system is referenced under "alarm history" for a specific event * Does the location seem reasonable? * Look at the RMS, the azimuthal gap, the number of stations * Examine the waveforms * are they from a local event? do the P and S arrival predictions look about right? Is a local event riding on top of a teleseism? * Wait for the TMTS message (whether you are accepting or deleting an event) * If things are ok - accept the event; if things are not ok, see the problem section below. - Check the ShakeMap * Is there a ShakeMap? * Does the ShakeMap look similar to the DYFI map? * Does the ShakeMap have data from stations * In most cases, you should see NP, NC, CE, and BK stations * Are there any obvious outliers such as a bullseye around a station? * If you observe problems, call Lisa. If Lisa is on vacation or away, call Jeff. - You may receive a call from CalOES personnel * Generally, they want to know whether the event is real. You can respond appropriately. Often, they also want to know what fault it is on and other details about the relevance. You can response with "We are just looking at this and will get back to you with more details". You can also suggest they call Lind. ===== Help ===== - If you are having difficulty responding for any reason, issue a //send-a-page// [[http://escweb.wr.usgs.gov/sendapage]] to the "//Eqalarm//" group. If you are not on duty, receive a “help” page, and have the capability to help out (more experience, access to Jiggle, etc), it is your responsibility to follow up immediately with a similar page to the group indicating that you are taking over response for the event. Inform NEIC (303-273-8680) what’s going on. - If you are responding to an event but taking longer than usual (or exceed 20 minutes and a reminder page is generated), issue a //send-a-page// [[http://escweb.wr.usgs.gov/sendapage]] to the "//Eqalarm//" group indicating that you are still working on the event. Inform NEIC (303-273-8680) what’s going on. - If you have put out a call for help and no NCSS DR staff member has indicated they are taking over, instruct the NEIC on-duty seismologist at 303-273-8680 to respond. ===== Problems ===== * ** Foreshock/mainshock ** - When a foreshock is immediately followed by a mainshock within ~10 sec, subjective decisions regarding whether to **accept**, **cancel**, alter the magnitude, or re-time via //Jiggle// need to be made rapidly. Here are some guidelines for different situations. - __Separation between two events is small, and the associator combines both events into one poorly located event__. - **Accept** the event if it is reasonably located (examine .prt file), regardless of the solution parameters (e.g., high RMS ). Mislocations up to 5km are “reasonable”. Begin relocation efforts via //Jiggle// after acceptance - If it is mislocated by more than 5km, do __**not**__ “accept” the event. Issue a message via //send-a-page// [[http://escweb.wr.usgs.gov/sendapage]] indicating what the problem is and what you are doing about it. Call NEIC. Relocate the event in //Jiggle// and "**Finalize**" it (__**not**__ "Save"). See Post-Processing section below. - __Binder recognizes two events, and the system assigns both events the magnitude of the mainshock__ - If the mainshock is poorly located (see 4I), **cancel** the mainshock, **accept** the foreshock, and issue a //send-a-page// [[http://escweb.wr.usgs.gov/sendapage]] describing what you have done. Tell Hal Macbeth what you have done. Call NEIC. - If the mainshock is reasonably located, **accept** the mainshock and set the Mh for the foreshock to be __2.9__. Tell Hal what you have done. Call NEIC at 303-273-8680. * ** Teleseism causing phantom events ** - In most cases, telestifle works well. Remember to check and release local events after a telestifle window. - But it isn't perfect, so -- if you think a teleseism has created one or more local events - Wait until the TMTS message has been generated. It's counter-intuitive (you'll want to start deleting everything you see), but wait. - Cancel the event(s) - Check to see that they have been deleted from the Web page - Write an errata (you can crib from this Web page [[http://earthquake.usgs.gov/earthquakes/errata.php | Errata for recent earthquakes]] - Check to see whether there are lingering NEIC products such as [[http://earthquake.usgs.gov/earthquakes/dyfi/|DYFI]] and [[http://earthquake.usgs.gov/earthquakes/pager/|PAGER]] - Check to see whether ENS issued a delete message - Contact NEIC (via email TBD and phone - Send them your errata and let them know what outstanding problems you see - Let Steve Hickman and Susan Garcia know what is going on * ** Teleseism biasing magnitude of local events ** - Edit the magnitude. Set it to something innocous, like 2.9 - Accept the event * ** NCSS mislocated event - actual event is outside the NC authoritative region ** Text below taken from Lind's January 2018 experience. So, from the DRP I could see that these were real events. It was also clear that the event was located further away than our location (the predicted arrival times were poor - in particular, the predicted S-arrival times were way too early). Looking at the Web, I could see a solution from one of the tsunami warning centers (TWC) - and it was located further west - just outside of our authoritative polygon and far enough away that the algorithm that decides whether two submitted events are the same earthquake failed. As a result, there were two earthquakes on the web. I had three choices: 1. Move the NC event to the correct location. I could have relocated it in Jiggle (time consuming) or I could have set a fixed location in Jiggle (faster, but still requires effort and a location to fix it to). The tsunami warning center solution looked good - and the NEIC solution wasn't out yet - so I would have used the TWC solution. 2. Force an association between the TWC and the NC solutions. That could be done a couple of ways. A duty seismologist can call NEIC and ask them to do this. I was recently given access to the tool the NEIC uses - and I could have done this. If the association had been made, I think the result would have been for the NC event to be authoritative. So the two events would have reduced to one - but the one with the poorer solution. So a second step would have been to make the TWC solution authoritative (possible in the NEIC tool). 3. Cancel the event. I chose #3 for the M5.8 and then had buyer's remorse. NEIC strongly prefers 1 or 2. 3 - while ok in this case because the event really was outside the network - causes confusion because of the cancellation emails and the products can get "lost" when they are cancelled. I didn't try #2 - partly for an obscure problem in an application called CISN Display. If I had merged the events and made made the TWC solution authoritative, it would have corrected the web but not CISN Display. For the second event, I attempted #1. I went into Jiggle and entered the coordinates and origin time of the TWC solution. I screwed up somehow - Jiggle gives you a pop quiz when you do this and I apparently failed one of the questions. So after thrashing a bit, I cancelled it as well. I didn't perform particularly well for this event. I should have been more familiar with setting a fixed solution. Hal walked me through this yesterday so I am hopefully prepared if something happens this weekend. ===== Post-Processing Response ===== - It is your responsibility to be familiar with using //Jiggle// for basic event relocation, if necessary. This will require that you - maintain and periodically test drive a recent version of //Jiggle// + current configs files on your **work** machine - maintain and periodically test drive a recent version of //Jiggle// + current configs files on your **home** machine - successfully configure and periodically test drive eRAS on your home machine - It is your responsibility that you understand the following techniques in //Jiggle// - Pick P and S phases, locate the event, compute an ML, and review the solution output for errors - Strip more distant picks (to remove mainshock picks from a foreshock) - Up-weight near-in picks (to remove foreshock picks from a mainshock) - Fix a location and/or magnitude - Finalize an event - Verify that the solution/magnitude have updated the information on the recenteqs page. - Notify Hal Macbeth any time that you have performed preliminary processing and finalized an event.