-
Notifications
You must be signed in to change notification settings - Fork 350
PyGRB TimeSlides SkyGrids Development
PyGRB targets the time and sky positions of GRBs (and FRBs, etc.) but in order to perform this analysis we need two key features to be added: time slides and sky grids. There may be overlap in the code development for both, hence combining the two in this page. There is a relevant issue #3467.
Time slides are used to build up an extended estimate of the background rate of noise triggers. They work by taking background data (data in the off-source) from different IFOs and combining them after applying unphysical time shifts. Under the assumption that the noise in the IFOs are independent and representative of the on-source, the distribution of triggers in the combined shifted data will approximate that in the un-shifted off-source and provide a legitimate way of estimating on-soure significance. See Section III in Williamson et al. (2014).
This technique is applied in the existing all-sky, all-time PyCBC search. Much of the code used to process slides can be found in the pycbc.events module (source on GitHub).
We can adapt this approach for our use. Since we have an on-source trial we will need to ensure that this time, and any additional buffer time we define, isn't slid into a time slide background trial, which would unblind the analysis.
The old code performed long and short slides. Short slides are defined as those that are less than a segment duration. Data segments from each IFO are read into memory to collect the un-slid triggers, and while already in memory these data streams could be cheaply shifted with respect to one another to collect time slides. The old code could reach p-values down to around 10-4 with this approach, but needed more slides to typically achieve p < 10-5.
Long slides involved taking completely separate data segments from each IFO, reading them into memory and sliding. This therefore involved aroughly linear additional computational cost per long slide since everything including data i/o was done afresh.
We may be able to achieve sufficient background without resorting to long slides in our new code, but it might still be desirable to add them as a feature since, for example, we might have so little science data for a GRB that short slides cannot generate enough trials.
Development ongoing in this branch
First pull request: #4059. In this pull request, Andrew wrote, "This is the current implementation of time slides. It is still work in progress. For example, we will need to consider how to properly do the book-keeping required to avoid unblinding an analysis. Triggers with SNR coming from the on-source in any IFO will have to be left out of the background when looking at a closed box."
Preliminary work has started for short slides in pycbc_multi_inspiral_slides. #3467 work should be largely overlapping with skygrid wiki
pycbc_multi_inspiral is the executable, currently it does only zero lag triggers. How do we call into timeslide code from here? Look at coinc code (pycbc_inspiral) to see how it's done there.
events/coinc.py has trigger handling related to coinc search. We want an equivalent coherent.py.
events/eventmgr.py already has a class for coherent events (EventManagerCoherent) which we will likely need to modify.
From the pull request, there was an example/ test implementation for multi_inspiral. Doing run.sh calls multi_inspiral.
One issue was ensuring that you wrap your timeslide around so that the segments are the same length. This was the "wrap around solution" and its subsequent fix within the pull request. This _should _be complete.
Current goals include making sure that we do not un-blind ourselves during closed/ open box analysis. To do so, we must know what calls multi_inspiral and where it is used. EventManagerCoherent has a write_to_hdf function. This could split the triggers into those in the onsource and those outside of it. It possibly would require a flag on the onsource events, such as that from a dictionary/key pair. The current goal is to decide the most efficient way to mark these onsource triggers.
The code will need to search over a list of points on the sky covering the GRB error box. We will also need to be able to generate grids.
At each different point on the sky there will be a different time offset between the IFOs and there will also be different antenna factors for each IFO. It might be possible to make use of time sliding routines to handle the timing shifts here? See Section V in Williamson et al. (2014).
Tessa Carver's commit here might be useful. Other than Tessa's commit, no work has been done towards this task since then, but there is a wiki page from Tessa here