coherent WaveBurst Review Meeting 23 July 2009 09:00 Pacific / 12:00 Eastern
Agenda: Thursday 23 July 12:00 Eastern
- Updates on action items:
- Patrick: Segment lists and livetimes [web]
Dial-in number: 1 800 704 9896 International dial-in: +1 404 920 6472 Conference code: 5374 2349 #
AttendanceFrancesco Salemi, Marco Drago, Patrick Sutton (minutes), Igor Yakushin, Sergei Klimenko
Walk-through of agenda item(PJS: These are not in chronological order.)
- PJS: Reviewing tests of segment lists, livetimes to close out that aspect of the review. Working on final sanity checks; description of results in link on agenda.
- PJS: IY's checks that all triggers are in the final segment list, and that no significant amount of data was missed, both look satisfactory. However, have problem with the livetime check: can't find a record of the livetime processed by cWB LFS after final segment lists. Web pages report livetimes using original cat 1,2 flags, not final v2.5 flags.
- Action item: IY will combine segment lists used for trigger production with final segment lists to compute livetime for each of the network combinations (or at least for the main ones used for ULs).
- FS: Can also check LFS livetimes against HFS livetimes -- should be very close.
- FS: MD has done checks of the segment lists and livetimes for S5yr2. Updated post cat1, 2 segment list livetimes for Table 1 of the paper. (These numbers are raw livetimes, not those processed by pipelines.)
- MD showed where the segment files used were obtained. On HFS wiki, Code Review page, see here. LIGO link points to Cadonati's DQ v2.5 page.
- PJS: LIGO DQ files not properly archived. However, some months ago group decided to post "official" versions on twiki that everyone could reference (link). MD should double-check that the files he got from Cadonati's page match these.
- Action item: PJS will double-check coincident livetimes the MD computed (now committed to paper CVS).
- PJS: Trying a simple sanity check for the livetimes. MDCs cover entire run, with Poisson rate of 1/100sec. Therefore can just count the number of injections processed by pipeline in each network configuration, multiply by 100 sec to get pretty accurate estimate of livetime actually processed.
- FS: Assumes injection runs process all of the data used for production runs. E.g., user may not bother to rerun some failed injection jobs that would have been rerun for production triggers.
- IY: Use script to find and rerun failed injection jobs. The segments processed for injection runs and production triggers should be exactly the same.
- PJS: Do HFS results pages list livetime after final DQ flags? FS: Yes. Showed example page -- for H1H2L1V1.
- FS: "Efficiency Study" links on wiki show total number of injections processed / detected / missed. PJS can use these for his livetime sanity checks.
PJS: Have checks of triggers falling outside final segment lists (a la IY) been done for HFS? FS/MD: Yes. See link from summary page / internal review / sanity checks / first link. Found very small fraction of trigger lies outside final segment lists by amounts roughly the duration of the wavelet pixels. Suspect this is due to noise in reconstruction of timing.
(PJS, after call: Think this is because time of arrival in a given IFO is not estimated directly from black pixels in that TF map, but rather from TOA at Earth and sky position both estimated from the full network. Therefore reconstructed TOA at a detector may in principle lie slightly outside domain of black pixels in that detector.)
- PJS: Want to check offline / next week with IY about counts of WNBs processed by cWB and Omega. Was discrepancy reported several months ago connected with fact that WNBs were injected with two different amplitudes in the same MDCs. Led to confusion by factor of 2 in counting of injections.
- IY: Issue was resolved; there was an error in the Omega accounting. PJS: twiki summary of the issue is not clear and summary file of injection counts seems inconsistent with explanation. Would like to go over this offline.
- FS: Brought up issue in paper: Omega pipeline tuned for FAR = 1.4 events after cat 2, whereas cWB and EGC tuned for FAR << 1. Extensive discussion of how this affects upper limit, ability to claim a detection. No consensus on details (PJS worried about effect on ability to claim a detection, SK and FS worried about impact on UL from having relatively lower threshold for Omega). All agree that it is inconsistent with stated tuning strategy used in S5yr1 paper and that used by cWB and EGC and agreed to by burst group. May want to ask Omega people (Brennan?) to raise Omega threshold and re-compute efficiencies. SK has asked Peter Shawhan to put this on the agenda for the next burst telecon.