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 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 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 ( , ) ( , ) ( , ) 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 of processing 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 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=1234 job2.x arg1 arg2 arg3 hostname2 date m 300 pid=2345 job3.x arg1 arg2 hostname3 date m 60 pid=3456 job4.x arg1 arg2 arg3 arg4 hostname1 date s pid=4567 noticeboard hostname1 listener hostname2 listener hostname3 listener listener grabs job from noticeboard listener updates noticeboard hostname1 forks child pid job queuing
ITW2007, Tokyo noticeboard hostname1 listener hostname2 listener hostname3 listener listener updates noticeboard if job is re-entrant job2.x arg1 arg2 arg3 - date m 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
ITW2007, Tokyo job queuing Infer Noticeboard –starting jobs list 1 23 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 name: Rabaul name: Langila name: Garbuna_Group name: Pago name: Ulawun name: Lolabau Region: Java Location: name: Merapi name: Ruang name: Kelut Region: Lesser Sunda Location: name: Batu_Tara name: Soputan Alert Name: Standard ================================================== Region: All lat lon Location: name: All - - job queuing regions file
ITW2007, Tokyo job queuing alert issued –alert name + region name in subject heading Volcano Alert: New Britain ================================================= Station: IS04 Azimuth: 56.4 Frequency: 1.0 Time(UTC): :38:23 Fstat: 24.8 Duration: 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 alert 6 INFER_LISTNER/bin/infer_det checks the wfdisc table for unprocessed data, places entries onto noticeboard to initiate detector Infrasonic Event: ================================================= Lat: Lon: Time(UTC): :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 Oracle 10gXE database/xe/htdocs/102xelinsoft.html python2.4, Pmw NA LockFile April/ html
ITW2007, Tokyo Large explosion woke residents along northern NSW coast Significant acoustic signals recorded on IS05, IS07 IS deg 19:24:08 IS 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: IS deg 2.0 Hz IS deg 2.0 Hz IS deg 0.06 Hz IS deg.0.06 Hz Infrasound Automatic Alert ========================================= Station: IS05 Azimuth: 23.8 Frequency: 2.0 Time(UTC): :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 Infrasonic Event: ========================================= Lat: Lon: Time(UTC): :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 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