Real-time GPS and Earthquake Early Warning

1
Real-time GPS and Earthquake Early Warning

• Jessica Murray-Moraleda1,
• Adrian Borsa2, Kenneth Hudnut1, Nancy King1, John
  Langbein1, Michael Lisowski1
• 1 U.S. Geological Survey
• 2 UNAVCO Inc.
• Jannuary 28, 2009

2
GPS complements seismic data
San Simeon Earthquake
Ji et al., GRL (2004)
Langbein and Bock, GRL (2004)
Miyazaki et al., GRL (2004)
3
Station Coverage
4
Potential uses Real-Time Damage Distribution
Maps

• Multiple sensor package
• Acceleration / Velocity
• Displacement (GPS)
• Rotation (tilt-meter)

• Pre-earthquake
• Reference static displacement
• Reference static rotation
• Mean and variance of
• dynamic characteristics

• Post-earthquake
• Permanent static displacement
• Permanent static rotation
• Mean and variance of
• dynamic characteristics

• During earthquake
• Changes in dynamic
• characteristics
• Hysteretic behavior
• Damage initiation

Figure courtesy of Ken Hudnut
5
Potential real-time GPS uses slip sensor

• Rapidly detect large offsets with sites spanning
  fault at either end
• Detect large slip within seconds, contributing to
  EEW
• Instrument major lifeline infrastructure crossings

Figures courtesy of Ken Hudnut
6
Potential uses rapid finite fault inversion

• In poorly instrumented regions, data are
  insufficient to constrain strong ground motions.
• Rapid finite fault inversion using broadband data
  can be used to augment ShakeMap.
• Geodetic data could be used as well, in joint or
  independent inversions.
• Provides rupture finiteness, directivity, ability
  to simulate near-fault strong motion.

Dreger et al. 2005
7
Potential uses rapid finite fault inversion
30
10
40
0
20
Minutes after origin time
BSL, 2006-2007 annual report
8
Steps to using high-rate real-time GPS for
earthquake warning and response

• Reliable data acquisition
• Real-time processing
• Event detection
• Incorporation into algorithms
• Earthquake early warning
• Finite fault inversion
• Utilization of results (e.g., ShakeMap)

9
Data Acquisition Bay Area
BARD real time
PBO real time
BARD
PBO
Strong motion
Broadband
10
Data Acquisition Bay Area
USGS and UNAVCO are collaborating to establish
robust data pathways for real-time high-rate data.
11
A word about latency

• PBO site in Salton trough streaming data via
  hi-speed radio
• Ntrip server latency is time required for data
  to get from site to server (radio/internet).
• Ntrip client latency is time required for data
  to get from server to clients (internet).

Figures courtesy of Adrian Borsa
12
Data Acquisition Southern California
Strong motion
USGS SCIGN real time
USGS SCIGN
Broadband
PBO
PBO real time
13
Data Acquisition Southern California
USGS-Pasadena Southern San Andreas Seismic
Network build-out, now in progress, with
real-time GPS co-located at several sites
14
GPS data processing

• Relative positioning
• Eliminates satellite clock errors and many
  atmospheric effects
• Reference station(s) must be nearby (50 km)
  problematic for real-time displacement
  determination
• Precise Point Positioning
• Absolute positioning
• Requires clock corrections
• Less precise

15
Real-time processing software requirements

• Reliability if the output positions show an
  offset, we must know, without further analysis,
  if we can believe it
• Robustness software should give reliable
  results even during times of routine
  perturbations such as satellites rising/setting
• Precision 2 cm to 10 cm level depending on
  application
• Latency on the order of seconds for early
  warning minutes acceptable for some response
  activities
• Absolute positioning or at least the ability
  to use a reference station sufficiently far away
  to not be contaminated by seismic shaking
• Cost, both up-front and recurring

16
Real-time software RTD

• Relative positioning ambiguity resolution at
  every epoch
• Being used in Canada for tsunami warning system
  and in Japan
• Horizontal scatter 2 cm IQR vertical 9 cm IQR

Dragert et al. 2005
17
Real-time software RTnet

• Relative positioning or PPP with sat. clocks from
  regional network
• Being used in Japan
• Horizontal precision 2 cm median r.t.
  processing time 1 sec.

Retrospective real-time test, point positioning
http//www.gps-solutions.com/develop/kushiro/
18
Real-time software RTG

• Precise Point Positioning using satellite clock
  corrections from a global network
• Horizontal precision 10 cm
• Latency for clock corrections 4-6 sec.
• Will be used in planned PNW real-time monitoring
  project

http//www.gdgps.net/monitoring/index.html
19
Software testing Relative positioning
An example of poor performance
Examples of more successful packages
20
Software testing PPP and real-time
Post-processed point positioning (green only)

• Above three component time series for a site at
  Three Sisters
• All positions
• Positions after eliminating outliers defined as
  exceeding 6 interquartile range

21
Software testing PPP, global clock corrections
Quiet periods are good, but problems with
convergence can occur.
22
What is needed?

• Reliable data acquisition
• Collaborations are being established to increase
  data availability and funding has been obtained
  from a range of sources (e.g. municipalities,
  surveyors groups)
• Need funding for receivers, telemetry, and
  operational support staff to maintain and extend
  spatial coverage
• Real-time processing
• Promising software packages identified limited
  funding obtained from various sources (NASA,
  USGS)
• Need longer-term funding for licenses and
  implementation
• Utilization of results
• Much of the basic machinery exists (e.g., finite
  fault inversion)
• Need more research and development personnel to
  implement event detection and incorporate data
  into EEW, ShakeMap, and other algorithms