I heard of an idea we used to use in Sonar to
look at Seawater characteristics.

Monitor the speed of sound through deep rocks
and look for any speed changes over time
and possibly see stresses as they actually build.

I saw this idea on TV just a few days ago
and we did they very same thing in Sea Water
to understand how sound travels wherever we were.

Sound Velocity is a physical characteristic fairly easy to measure.


-----Original Message----- 
From: Dan Bolser
Sent: Monday, March 07, 2011 11:39 PM
To: PSNLIST@.............. ; Oliver Boyd ; Anyone? ; webmaster@........ ; leslie@........ ; tim@................... ; kent@........ 
; james.gridley@........ ; John Taber ; admin@.........
Subject: Representative stations (and IRIS station list)

Hi all,

I've been looking to collect a dataset of seismograms for an
'earthquake prediction competition' idea (see below for more
information), and struggling quite a lot along the way!

I'm looking for a list of 20 or so 'representative' stations from
around the world with extensive and consistent records. If possible
I'd like a list of station and network codes so I can collect data via
BREQ FAST.

Is there a concept of a representative station in the field? (I'm not
an expert). Anyone want to go out on a limb and suggest such a list?
;-)


As a first step, I thought I'd just get a list of stations (and
network codes), however, the list I found here:
http://neic.usgs.gov/neis/station_book/ seems to use 3-4 letter
network codes (or blanks), while the BREQ FAST instructions here:
http://www.iris.edu/manuals/breq_fast.htm suggests that I need two
letter network codes (indeed, my test bfast request failed).

For your interest, I scraped a "year / network / station" table from
here: http://www.iris.edu/SeismiQuery/day_f.html - Please just let me
know if you want that table in spreadsheet format. Using that I found
688 stations with data between 2002 and 2010.

Other than suggested reading material:
* http://cseptesting.org/experiments/RELM
* http://www.iaspei.org/downloads/Ex_Sum_v5_THJ9_A4format.pdf

I haven't received much feedback on the overall idea, which is
presented below for your feedback, comments and criticism. Please just
let me know if you'd like to help with this project, as currently I'm
more or less stabbing in the dark!

Faithfully,
Dan.


Dear colleagues,

I'm trying to put together a dataset of seismograms for a community
data prediction competition that would be hosted on Kaggle
(http://www.kaggle.com/). The idea is to improve earthquake prediction
methods and raise awareness of approaches, tools, data, charities and
organizations like yours.

I'm very inexperienced at handling seismograms, so I'm having
difficulty deciding the form of the data to use and the actual data
collection for the competition. I would greatly appreciate a) your
feedback on my proposal, described briefly below, and b) help
collecting the required data.

I know this is a highly optimistic project, but in the words of the
Kaggle website: "By exposing problems to a wide audience, with
different participants trying different techniques, competitions can
very quickly reach the frontier of what's possible for a given
dataset."

Thanks for any help or advice that you can provide.


Yours faithfully,
Dan Bolser.



Here is the outline my naive plan:

1) Pick a set of (perhaps 20?) representative stations distributed
around the world.

2) Pick around 1000 points in time at random for which all 20 stations
have data, and collect 30 days (?) of seismic information from each
station leading up to this point. This dataset will form the set of
'negatives' for training.

3) Pick around 1000 'events' at random for which all 20 stations have
data, and collect 30 days (?) of seismic information from each station
leading up to this 'event'. This dataset will form the set of
'positives' for training.

4) Repeat step 2 and 3 to generate a private testing set.

5) Host the competition on Kaggle (see,
http://www.kaggle.com/About-Us/how-it-works).


My ignorance of the field leads me to question weather the number of
stations (20), number of events (1000) and number of days of seismic
information (30) all look reasonable (assuming the overall scheme
looks reasonable). Do any of these values look inappropriate or
problematic? Can you suggest better values?

Also, two other weaknesses / questions come to mind:

1) How should we define 'leading up to'? Current predictions are in
the order of minutes, but it would be useful to predict hours, days or
weeks in advance (if possible). Should we try to develop predictions
(and therefore collect data) in all these ranges?

2) Should we try to predict event severity as a continuous numeric
variable, or should we define a binary or some other ordinal scale? If
so, where would you suggest we place the ranges?


Here is my first working(!!!) BFAST request:

..NAME Dan Bolser
..INST NA
..MAIL 8c Dalgleish Road
..EMAIL dan.bolser@.........
..PHONE +44 (0)1382 521 383
..FAX
..MEDIA FTP
..ALTERNATE FTP
..ALTERNATE FTP
..LABEL Test request 03
..QUALITY B
..END

PPNAF PN 2005 01 17 00 00 00.0000 2005 02 16 00 00 00.0000 1 BHZ
MHD   UU 2005 01 17 00 00 00.0000 2005 02 16 00 00 00.0000 1 BHZ
HONU  UU 2005 01 17 00 00 00.0000 2005 02 16 00 00 00.0000 1 BHZ
USIN  NM 2005 01 17 00 00 00.0000 2005 02 16 00 00 00.0000 1 BHZ
PD11  IM 2005 01 17 00 00 00.0000 2005 02 16 00 00 00.0000 1 BHZ
JTS   II 2005 01 17 00 00 00.0000 2005 02 16 00 00 00.0000 1 BHZ
LBNH  US 2005 01 17 00 00 00.0000 2005 02 16 00 00 00.0000 1 BHZ
CIA   CI 2005 01 17 00 00 00.0000 2005 02 16 00 00 00.0000 1 BHZ
__________________________________________________________

Public Seismic Network Mailing List (PSNLIST)

To leave this list email PSNLIST-REQUEST@.............. with
the body of the message (first line only): unsubscribe
See http://www.seismicnet.com/maillist.html for more information. 

__________________________________________________________

Public Seismic Network Mailing List (PSNLIST)

To leave this list email PSNLIST-REQUEST@.............. with 
the body of the message (first line only): unsubscribe
See http://www.seismicnet.com/maillist.html for more information.