home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / chile / chilel / 1499 < prev    next >
Encoding:
Internet Message Format  |  1993-01-27  |  6.8 KB

  1. Path: sparky!uchdcc!@uchdcc.dcc.uchile.cl
  2. Return-Path: <@cecux1.cec.uchile.cl,@uchcecvm.cec.uchile.cl:CHILE-L@USACHVM1.BITNET>
  3. Message-ID: <m0nHJz8-000CqhC@cecux1.cec.uchile.cl>
  4. Sender: Discussion regarding Chile <CHILE-L%USACHVM1.BITNET@uchcecvm.cec.uchile.cl>
  5. From: "Juan Carlos Barroux - Technical Consultant - Latin America"
  6.               <Juan.Barroux@CORP.SUN.COM>
  7. Subject: Re: Earthquake Alarm?
  8. Original-To: Multiple recipients of list CHILE-L <CHILE-L@USACHVM1.BITNET>
  9. Newsgroups: chile.chile-l
  10. Distribution: chile
  11. Sender: Mailing.List@dcc.uchile.cl
  12. Approved: Mailing.List@dcc.uchile.cl
  13. Date: Wed, 27 Jan 1993 14:07:16 CST
  14.  
  15.   Estimados CHILE-Len{o,a}s,
  16.  
  17.   Adjunto encontraran la descripcion teorica de un sistema de alarmas
  18. para terremotos que tendria una excelente aplicacion practica en Chile.
  19.  
  20.   A mas de alguien le podria interesar esto en Chile, digo yo....
  21.  
  22.   Muchos saludos a todit{o,a}s.
  23.  
  24.   Frase del Dia Patron:
  25.  
  26.   "I submit to you that if a man hasn't discovered somthing he will die
  27.   for, he isn't fit to live."
  28.  
  29.   Martin Luther King 1929-1968 - Speech in Detroit, 23 June 1963
  30.  
  31. ----- Begin Included Message -----
  32.  
  33. >From barroux Tue Jan 19 14:06:10 1993
  34. From: barroux (Juan Carlos Barroux - Technical Consultant - Latin America)
  35. To: me
  36. Subject: Re: Earthquake Alarm?
  37. Content-Length: 5651
  38.  
  39.  
  40. In article 51873@seismo.CSS.GOV, stead@skadi.CSS.GOV (Richard Stead) writes:
  41. >In article <41350005@hpindda.cup.hp.com>, jeffb@hpindda.cup.hp.com (Jeff
  42.  Bandle) writes:
  43. >> quake hit.  The seismologist said that he was walking into a safe area
  44.  because
  45. >> their earthquake alarm had gone off a few seconds before the shaking.
  46. >>
  47. >> Does anybody have any details on what this earthquake alarm is and is it
  48. >> possible to get one for a home?
  49. >
  50. >Short answer is no.  But I'll explain how such a system operates, and then
  51. >explain how I would run a real early warning system.
  52. >
  53. >It is probably like to Caltech's (which has been running for years).
  54.  Basically,
  55. >it is an alarm connected to the computer responsible for automated detection.
  56. >The way Caltech's works is that more than 200 stations throughout S CA are
  57. >telemetered realtime to the seismo lab there.  They are then digitized and
  58. >streamed into a computer.  An algorithm called a "detector" is then run
  59. >on the data.  There are a wide variety of detectors, the most common is
  60. >"STA/LTA" (short-term average to long-term average ratio).  In this algorithm,
  61. >the signal for each station is run through several bandpass filters and
  62. >then each bandpass has STA and LTA computed continuously, when the ratio
  63. >exceeds a certain minimum, a detection is registered.  There is some post
  64. >processing to verify the detection, compute onset time, etc.  At that point
  65. >the station has a detection at a certain time with a known amplitude.
  66. >The Caltech method then waits for a certain minimum number of stations
  67. >in a "subnet" group of stations to "trigger" within a limited time window.
  68. >This is then called a subnet trigger.  A crude location of the event is
  69. >also made available, so the magnitude becomes known.  To trigger the alarm,
  70. >certain pre-configured subnets must all trigger at their minimum magnitudes.
  71. >The alarm is then triggered.  At Caltech, the alarm also dials the beepers
  72. >of key lab personel (to summon them to the lab for work), and also rings
  73. >at Caltech security (where they have a checklist they follow when this alarm
  74. >rings).  It is very hard for this system to get a false alarm, but it often
  75. >misses big events.  The alarm itself was not designed to be ideal - it was
  76. >more or less attached to the system as an afterthought (the system is
  77. >required to perform well - it is responsible for the initial solutions and
  78. >setting aside the data the analysts will use to get the final locations
  79. >and magnitudes).
  80. >
  81. >From time to time, the "early warning" question appears in this group.
  82. >I have long claimed this is a solved problem, but somewhat expensive to
  83. >implement.  I think to get it implemented, the state really only has to
  84. >contract with a team of companies that would include some seismological
  85. >expertise, but mostly communications and instrumentation.  It would
  86. >require a seismologist in charge who recognixes that this would not be
  87. >about collecting interesting data or about research.  Most seismologists
  88. >would have an interest in using such a project to do seismology, and it
  89. >is not about that.  What needs to be done is to design a very simple,
  90. >very inexpensive instrument package that could provide simply time,
  91. >amplitude and period each time its detection requirements are met.
  92. >Some means of sending this detection information to a central site
  93. >would be required.  It would not be much information - could be up
  94. >to 10 Kbytes a day.  But it would have to be realtime.  This is why
  95. >communications may be the most important aspect.  In this design, there
  96. >would be 1000's of these detectors carpeting CA.  Once at the central
  97. >site, a single workstation would be sufficient to recognize events in
  98. >realtime, get a "good enough" location and a pretty good magnitude,
  99. >then send it to the broadcast system.  The broadcast system would be
  100. >responsible for sending the notice of location and magnitude to all of
  101. >CA.  Receivers for this signal would be design to be inexpensive,
  102. >and would have a simple capability to have their location input (or know
  103. >it from GPS), and compute the distance between the announced location
  104. >and the receiver location, then compute the expected intensity at the
  105. >receiver and sound an alarm if this exceeds some minimum.  Fancier ones
  106. >could provide closed circuits at a variety of minimum intensities for
  107. >automated shutdowns, switchovers to generators, etc.  I would estimate
  108. >that 3 seconds of signal would be required at each of the three nearest
  109. >stations, 2 seconds of propagation time (for the quake to reach each of
  110. >3 nearest stations), 2 seconds of instrument and communication overhead,
  111. >4 seconds of processing at the central site, 2 seconds communication
  112. >overhead on the broadcast and 1 second processing by the receiver.
  113. >That's 14 seconds from the start of the event until you hear the alarm.
  114. >The damaging shaking will have only gone about 5 km in that time.
  115. >Of course, these are optimistic numbers, I suspect that damaging shaking
  116. >might get 2 or 3 times that far before someone could receive and react to
  117. >the alarm.  Nevertheless, in a big quake, the fault would still be
  118. >breaking at this time.  The system would issue updates as the earthquake
  119. >grows in size, triggering more receivers.  It would work, it would likely
  120. >have few false alarms (and if a receiver waited for confirmation from
  121. >later updates, the false alarm rate could be adjusted at the receiver),
  122. >and would get every real event.  The communication would cost a fortune,
  123. >but could probably be offset by a "subscription" cost for the broadcast
  124. >service.
  125. >
  126. >
  127. >--
  128. >Richard Stead
  129. >Center for Seismic Studies
  130. >Arlington, VA
  131. >stead@seismo.css.gov
  132.  
  133.  
  134.  
  135.  
  136.  
  137. ----- End Included Message -----
  138.