1 / 24

Real-time Gravitational-wave Burst Search for Multi-messenger Astronomy

Junwei Cao LIGO Scientific Collaboration Research Group Tsinghua University, Beijing, China November 4, 2010. Real-time Gravitational-wave Burst Search for Multi-messenger Astronomy. Outline. Introduction LSC Burst Group What’s Real-time Search Motivation Our method and pipeline

lucus
Download Presentation

Real-time Gravitational-wave Burst Search for Multi-messenger Astronomy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Junwei Cao LIGO Scientific Collaboration Research Group Tsinghua University, Beijing, China November 4, 2010 Real-time Gravitational-wave Burst Search for Multi-messenger Astronomy

  2. Outline • Introduction • LSC Burst Group • What’s Real-time Search • Motivation • Our method and pipeline • Decentralized GWB data processing • DMT monitor on pipeline trigger for glitch study • GPU acceleration in GWB data processing • Pattern recognition method for veto analysis • Conclusion

  3. Our Group • The LSC member group in China, including 3 faculty members and 5 students • Expertise lies in GW data analysis and computing infrastructure • Also involved in LCGT, AIGO and ASTROD • With close collaboration with MIT, Caltech and UWA • This talk provides an introduction to our several existing efforts on GW data analysis

  4. LSC Burst Group • Mission: Detection of unmodeled bursts of gravitational radiation • Three dedicated pipelines: • Omega Pipeline • https://geco.phys.columbia.edu/omega • Coherent Wave Burst (CWB) Pipeline • S. Klimenko et al, Class.Quant.Grav.25:114029,2008 • Kleine Welle for online detector characterization • LIGO Document, LIGO-G050158-00-Z, 2005 • One group-crossed pipeline (mainly Burst Group): • X-Pipeline for directional search • https://geco.phys.columbia.edu/xpipeline

  5. Real-time Search • Real-time: between online and offline mode for large-scale data analysis Online Monitoring Data Streams On-site Real-time Search Data Streams+ Data Production On-site+ Off-site Offline Analysis Data Production Off-site

  6. Motivation • Prompt E/M follow-up by LIGO’s external collaborators • Detect astronomy events earlier than traditional observation methods • Increase the confidence of the GW candidate event • Obtain more information about GW candidate event and its source: more accurate sky position, distance, …

  7. Motivation Blue: SNR>5 Green: SNR>10 Red: SNR>20 Star: Loudest trigger Rapid detector characterization

  8. Burst Search in S6 Nearly Real-time low latency analysis for the first time

  9. Burst Search in S6 • But low latency’s price is low precision • Potentially increase false alarm rate at the expense of fully utilization of AUX channels info • Less accurate sky position and other info of GW candidate events • Multi-messenger astronomy can be performed better in Burst search • Directional search is not merged into current real-time burst search

  10. Challenges in AdvLIGO Era • More potential IFOs: LCGT, AIGO, … • More data streams flood into central location • Larger Data Volume Cite from LIGO-G0900008

  11. Our Pipeline

  12. Key Features Decentralized GWB data processing DMT monitor on pipeline trigger for glitch study GPU acceleration in GWB data processing Pattern recognition for veta analysis

  13. Distributed Pipeline • Decentralized GWB data processing • For example, Omega Pipeline’s 3 main functions • Single site trigger generation • Coincidence check between detectors • Followup analysis • In current Burst search, all 3 functions are in CIT, waits for all 3 sites data ready, then run • In decentralized GWB data processing, trigger generation function runs on single site, only the triggers transferred to CIT, coincidence check will decide whether to get h(t) data and AUX data. This can • Lowers down CIT’s IO throughput • Reduce latency

  14. OmegaMon Trigger Rate on L1 Trigger Rate on H1 Triggers’ scatter plot on L1 Triggers’ scatter plot on H1 • DMT monitor • An example, OmegaMon, Omega Pipeline’s DMT monitor

  15. GPU Acceleration • Time consuming algorithms in burst search: such as Omega’s followup function, it can cost a couple of minutes on a 64 seconds block of data, which cannot meet real-time requirement • Condor job fail problem: Both Omega and CWB need background estimation, which needs run hundreds of condor jobs on cluster. But condor jobs could fail due to various reasons. If GPU acceleration can get hundreds of condor jobs run on only one PC, then this problem would not exist.

  16. GPU Acceleration A case: GPU acceleration on IIR (Infinite impulse response) filtering For a predicted inspiral waveform, it can be decomposed into a series of constant frequency decaying sinusoids. Each sinusoid is used to define a single IIR filter. The coherent addition of the output of the set of IIR filters recovers predicted waveforms with near optimal signal to noise ratio. Since among IIR filters , the independence are significant, which is suitable for GPU acceleration parallel process.

  17. GPU Acceleration • 50-fold speedup over the traditional CPU implementation

  18. GPU Acceleration • We can currently handle 3000 templates in real time.

  19. Veto Analysis • Pattern recognition in trigger veto • To identify background events during Burst data analysis, one common way is to use information from multiple auxiliary channels. Traditional veto method is to analyze the coincidence between GW trigger and every AUX trigger independently. If there exits a coincident AUX trigger similar with the GW trigger in certain kind, the GW trigger is believed to be generated by the corresponding AUX channel, not by gravitational wave.

  20. Veto Analysis • Pattern recognition in trigger veto • Compared with traditional single–channel fixed-window approach, pattern recognition provides another vision. It utilizes hundreds of auxiliary channels’ information at the same time and classify glitches more efficiently. • Take SVM (Support Vector Machine) method as an example. In general, SVM works by finding a maximum-margin hyperplane to separate samples in a transformed space, defined by a kernel function.

  21. Veto Approach • The veto process can be considered as a classification problem of instrument status: • The input of the classifier is the combination of properties of all coincident AUX/ENV triggers at the time ti, assuming there is a GC trigger at the time ti. • The output of the classifier is whether the instrument is fault or not. • If yes, the GC trigger is a glitch; • If not, the GC trigger is a GW signal No signal and no glitch either! No instrument faults! perfect for training the classifier We want to know if this is a signal or a glitch This is definitely a GW signal GC 1 1 0 0 AUX1 0 1 0 0 AUXn 0 0 1 0 ENV1 0 0 1 0 ENVm 0 1 0 0

  22. Veto Analysis

  23. Veto Analysis Efficiency: fraction (%) of GW triggers rejected. Dead-time: fraction (%) of live-time lost due to veto application. • Pattern recognition in trigger veto • Comparison between SVM and traditional method on S4 L1 data set

  24. Conclusion Current Burst real-time low latency search is successful, but not perfect To be ready for AdvLIGO, burst search infrastructure should evolve Advanced computing technology and method can significantly boost real-time multi-messenger astronomy

More Related