ITW2007, Tokyo

Infrasound Data Processing at

Geoscience Australia

David J Brown

ITW2007, Tokyo

• Current State of the automatic infrasound processing system operating at GA.– signal detection– source location– job queuing– example– summary

Overview

ITW2007, Tokyo

Image Space, S Parameter Space, P

Hough Transform

ij

ij

ij

ijii

xx

yy

xx

yyxy

Signal Detection

ITW2007, Tokyo

Initial state M=0.24 Iteration one M=0.24

Iteration two M=0.004 Iteration three M=0.004

The Neighbourhood algorithm:minimise the misfit

Source location

N

i i

N

iTi

TTM

1

25.1

)(

(pred)i

(obs)i

1

25.1

)(

(pred)i

(obs)i),(

• distribute points in computational domain

• find the region about each point that is closer to that point than any other (voronoi cell)

• distribute the same number of points randomly in the first few voronoi cells with the smallest values of misfit

ITW2007, Tokyo

(24.0948, 63.4349) 24.0948.063.4349

(23.8670,76.7989) 23.8670.076.7989

(35.2644,75.0000) 35.2644.075.0000

Unique 16-digit string

– access travel-time data using lat/lon information via a minimal perfect hash

Source location

data file generated for each station and stored as a shared memory segment on the host

travel-time and azimuthal deviation information assuming each grid point is a source location and acoustic propagation for some prescribed climatological model is determined and stored in a vector accessible using an index that is a hash of the lat/lon string

ITW2007, Tokyo

job queuing• main operation controlled by the Infer Listener GUI

– an instance will need to run on each host that wants to process data

colour panel shows state ofprocessing for each hour for each station

Start/Stop button to toggle operation of the current instance. Stop All button to stop operation of all instances

Infer Listener is constantly trawling the infer noticeboard looking for jobs to run. Currently processing jobs are displayed in this panel

ITW2007, Tokyo

job queuing• main operation controlled by the Infer Listener GUI

– an instance will need to run on each host that wants to process data

Infer Listener is constantly trawling the infer noticeboard looking for jobs to run. Currently processing jobs are displayed in this panel

ITW2007, Tokyo

job1.x arg1 arg1 arg3 arg4 - date s -job2.x arg1 arg1 arg3 - date m 300 -job3.x arg1 arg1 - date m 60 -job4.x arg1 arg1 arg3 arg4 - date s -

noticeboard

job1.x arg1 arg2 arg3 arg4 hostname1 date s pid=1234job2.x arg1 arg2 arg3 hostname2 date m 300 pid=2345job3.x arg1 arg2 hostname3 date m 60 pid=3456job4.x arg1 arg2 arg3 arg4 hostname1 date s pid=4567

noticeboard

hostname1

listener hostname2

listener

hostname3

listener

listener grabs jobfrom noticeboard

listener updates noticeboard

hostname1forks

child pid

job queuing

ITW2007, Tokyo

noticeboard

hostname1

listener hostname2

listener

hostname3

listenerlistener updates noticeboard if job is re-entrant

job2.x arg1 arg2 arg3 - date m 300 -job3.x arg1 arg2 - date m 60 -

listener constantly checking for defunct child processes (i.e. zombies)

job queuing

ITW2007, Tokyo

INFER_LISTNER/bin/check_alert alert_type=Volcano Region=‘New Britain’ sta_list IS04 IS05 IS07

INFER_LISTNER/bin/check_alert alert_type=Volcano Region=‘Java’ sta_list IS04 IS05 IS07

INFER_LISTNER/bin/check_alert alert_type=Volcano Region=‘Lesser Sunda’ sta_list IS04 IS05 IS07

INFER_LISTNER/bin/check_alert alert_type=Standard Region=‘All’ sta_list IS04 IS05 IS07

INFER_LISTNER/bin/check_event

INFER_LISTNER/bin/infer_det

INFER_LISTNER/bin/infer_loc sta_list IS04 IS05 IS07

INFER_LISTNER/bin/tickle_man

INFER_LISTNER/bin/remove_logs

job queuing• Infer Noticeboard

– starting jobs list

1

2

3

4

5

6

7

8

9

ITW2007, Tokyo

job queuing• Infer Noticeboard

– starting jobs list

1 2 3

INFER_LISTNER/bin/check_alert alert_type=Volcano Region=‘Java’ sta_list IS04 IS05 IS07

checks the arrival table for significant signals from a volcanic region for the sta list

4

INFER_LISTNER/bin/check_alert alert_type=Standard Region=‘All’ sta_list IS04 IS05 IS07

checks the arrival table for significant signals from any region

ITW2007, Tokyo

Alert Name: Volcano================================================= Region: New Britain lat lon Location: name: Manam -4.10 145.06 name: Rabaul -4.271 152.203 name: Langila -5.525 148.42 name: Garbuna_Group -5.45 150.03 name: Pago -5.58 150.52 name: Ulawun -5.05 151.33 name: Lolabau -4.92 151.158

Region: Java Location: name: Merapi -7.542 110.442 name: Ruang -8.125 114.042 name: Kelut -7.93 112.308

Region: Lesser Sunda Location: name: Batu_Tara -7.792 123.579 name: Soputan 1.108 124.730

Alert Name: Standard================================================== Region: All lat lon Location: name: All - -

job queuing

• regions file

ITW2007, Tokyo

job queuing

• alert email issued– alert name + region name in subject heading

Volcano Alert: New Britain================================================= Station: IS04 Azimuth: 56.4 Frequency: 1.0 Time(UTC): 2007304 18:38:23 Fstat: 24.8 Duration: 320.0 Arid: 37829

ITW2007, Tokyo

job queuing• Infer Noticeboard

– starting jobs list

5

INFER_LISTNER/bin/check_event

checks the origin table for formed events+sends email alert

6

INFER_LISTNER/bin/infer_det

checks the wfdisc table for unprocessed data, places entries onto noticeboard to initiate detector

Infrasonic Event: ================================================= Lat: -22.1459 Lon: 134.5100 Time(UTC): 2007304 05:22:18 Ndef: 3

ITW2007, Tokyo

job queuing• Infer Noticeboard

– starting jobs list

7

INFER_LISTNER/bin/infer_loc sta_list IS04 IS05 IS07

queues consecutive four hour intervals for location for stations in the sta_list

8

INFER_LISTNER/bin/tickle_man

tickle shared memory segment used in source location if non-constant velocity model used

9

INFER_LISTNER/bin/remove_logs

remove processing log files

ITW2007, Tokyo

noticeboard

logfile

Oracle• arrival• detection• infra_features• site• wfdisc• lastid• affiliation• origin

hostname1

listener

hostname2

listener

hostname4

listener

hostname3

listener

job queuing

• NFS atomic-level file-locking

(discretionary)

ITW2007, Tokyo

job queuing:

• software design– no commercial software or expert knowledge to install– standard languages

• ANSI-C• python• fortran

– free-ware• FFTW http://www.fftw.org/

• Oracle 10gXE http://www.oracle.com/technology/software/products/

database/xe/htdocs/102xelinsoft.html

• python2.4, Pmw http://www.python.org/ http://pmw.sourceforge.net/

• NA http://rses.anu.edu.au/~malcolm/na/na.html

• LockFile http://mail.python.org/pipermail/mailman-developers/

2000-April/006657.html

ITW2007, Tokyo

Large explosion woke residents along northern NSW coast Significant acoustic signals recorded on IS05, IS07

IS07

125.5 deg

19:24:08

IS05

23.8 deg

18:27:48

Example: The Taree Bolide, December 06, 2004

ITW2007, Tokyo

Example: The Taree Bolide, December 06, 2004

wfdisc data for 7 hours known to contain signals is loaded into Oracle db

Listener ready to start

ITW2007, Tokyo

Example: The Taree Bolide, December 06, 2004

• infer_det has run and has queued all hours for processing.

• Alert checking code continually being re-loaded.

• each instance is limited to two concurrent processes.

ITW2007, Tokyo

Example: The Taree Bolide, December 06, 2004

• after some time 5 hours of data have successfully passed detection, one hour is currently processing and one hour is queued for processing

• check alert has run and found several significant signals:

• IS07 125.5 deg 2.0 Hz• IS05 23.8 deg 2.0 Hz• IS05 110.0 deg 0.06 Hz• IS05 125.0 deg .0.06 Hz

Infrasound Automatic Alert========================================= Station: IS05 Azimuth: 23.8 Frequency: 2.0 Time(UTC): 2007309 18:27:48 Fstat: 24.8 Duration: 60.0 Arid: 2010

ITW2007, Tokyo

Example: The Taree Bolide, December 06, 2004

• all hours have successfully passed detection and infer_loc has queued them for location

• needs 4 consecutive hours that have passed detection

ITW2007, Tokyo

Example: The Taree Bolide, December 06, 2004

• processing complete:• one event formed and check_event has generated email

Infrasonic Event: ========================================= Lat: -30.6793 Lon: 153.5019 Time(UTC): 2007309 17:11:07 Ndef: 2

ITW2007, Tokyo

Summary• Purpose of the infrasound processing system is to

provide non-expert users:– a facility for detecting significant acoustic signals in IMS

array data– an alert via email for significant signals– an estimate of when and where the event occurred for

multiple station recordings

• Ease of installation and use:– no software engineering knowledge required or a necessity

to resort to commercial software

ITW2007, Tokyo

Summary• Automatic infrasound processing system is maturing

– signal detection is rugged• population of arrival, detection and infra_features table is

reliable

• need to incorporate uncertainty estimatefor az+time

– source location process is maturing• occasionally NA location algorithm gets trapped in local minima

• conflict resolution in the association phase needs further testing

• need to provide uncertainty in location

ITW2007, Tokyo

Summary• Automatic infrasound processing system is maturing

– python queuing code works in general• a few idiosyncrasies

– possible in rare circumstances for two hosts to execute the same job.

– need mechanism to restore lost jobs when host dies

• need to add extra features to the GUI:– user selectable detector/locator parameter selection– waveform display– improved error reporting