LSC-Virgo Burst Analysis Working Group


Burst Group Home
ExtTrig Home
CBC Group Home
LSC, LIGO, Virgo


'How-to' docs
[2008, 2007, earlier]
Talks/Posters [pre-wiki]
Paper plans
White papers


Analysis projects
Old notebook [General, S2, S3, S4, S5]
Virgo workarea
External collabs


Main review page

Review Committee Meeting Monday 13 February 2006 09:00 PST / 12:00 EST

Minutes: Monday 13 February 2006 09:00 PST / 12:00 EST

Agenda and Contact Info


  1. Continue the review of the GRB GWB search

Contact Info

AccuConference teleconferencing service:
   Phone: 1-800-704-9896, participant code: 038621#
   International callers ++1-404-920-6472 with same code


  1. Code Review
    • Peter Kalmus will be conducting the code review. He has received code from Isabel and Soumya and will be reviewing it. He is preparing a list of claims of what the code does from the technical documentation.
    • Objectives of code review are:
      1. Establish that there are no conceptual errors in algorithm/parameter/operation choices.
      2. Establish the code implementation and use is in complete agreement with the documentation.
      3. Establish that this code implementation is free from any (major) bugs.
      4. Establish the provenance and correct accounting of the data products.
      5. Make suggestions of what conceptual implementation changes that authors should be persuing in improving astrophysical reach.
    • Fourth item is new. The goal here is to make sure that all of the data that should have been analyzed was analyzed successfully, produced valid data products, and was correctly accounted for in the post analyses. It includes things such as making sure that all the data was analyzed with the same CVS-tagged version of the software, that due to some bug some analyses were accidently omitted, etc.
    • Items 1 and 5: these items refer more to the work of the review committee as a whole rather than the code reviewer. The code reviewer is not really responsible for performing these tasks, but may have unique insights because of their intimate knowledge of the working of the code.
    • Code review should feel free to comment on possible improvements to code efficiency and style. But these are of lesser importance to those points listed above.
    • Suggestion: maintain code review documentation on a burst enotebook page.
    • Target is to review substantial parts of the code by the LSC meeting.
  2. What needs to be done by Sunday, Feb 19 deadline?
    • Review committee would like specifics about what is to be in APS presentations. For example, descriptions of the figures, sensitivity statements, and results statements that are to be given (that need review).
    • Preliminary presentations are not required.
    • We need to know what we have to review in advance so that we can plan to have it reviewed by the LSC meeting. Goal is for us to be able to say "we have reviewed this material" after the presentation at the LSC meeting so that the APS presentation can be approved then.
    • It will not be possible to have complete reviews of the various analyses so we need to isolate those aspects that are to be presented. We may need to do triage if we cannot review everything that people want to present.
    • What about S5 results? These will not be available by Feb 19. Depending on what exactly will be presented we do not perhaps need to have full details by Feb 19. For example, if the statement will be "we find no evedence for a GWB associated with the GRBXXXXXX with our preliminary analysis" then the review should be fairly straighforward. If the statement is "we bound the strength of GWBs associated with GRBXXXXXX to h less than YY" then substantial review may be required.
    • Also: be aware that there is traditionally only one "preliminary" result. So if preliminary S5 results were shown, we would not want to have another set of preliminary S5 results with new calibration, etc. The next set of results would have to be "final". This should be considered when deciding whether a result is sufficiently mature to be shown at APS.
    • Unlikely that we will have results from the population study of S5 triggers for the APS presentation.
  3. Isabel has prepared new plots for the data conditioning sanity checks [ HTML ].
    • There is another set of plots comparing Tukey vs. Hann windows.
    • There are corrected plots for the L1 time-series segmentation.
    • Jolien is still worried about spectral leakage causing the data not to be properly "whitened" at low frequencies. (See, e.g., Fig 4 of technical documentation, frequencies between 40 and 65 Hz.) This is probably OK since these frequency should be suppressed. Still, need to make sure that there is not any spectral leakage and this probably needs to be done for each IFO and each data run (and perhaps several epochs within the runs) since the nature of the ASQ spectrum changes.
    • Brian is worried about up-conversion and whether the spectrum accurately captures this effect. Specifically in the 60 - 100 Hz region where ther might be some difference between the 4s Hann spectrum and the 1s Tukey spectrum. Again: would need to see average spectra to clearly distinguish between two estimates.
    • Jolien is still worried about discontinuities in the whitened timeseries. ACTION: produce one whitened time series with one set of transition times, then shift the data so that the transition times are different and produce a second whitened time series. Overlay these two series to see if the discontinuities are actually there in the data or if they are associated with the data conditioning procedure.
    • If discontinuities are due to data conditioning, need to establish whether they significantly affect the CC statistic. Perhaps by comparing distribution of CC stats that span a transition vs. those that do not.
$Id: minutes-2006-02-13.html,v 1.3 2006/02/13 22:21:08 jolien Exp $