Skip banner and navigation tools.

 |  site map

Changes made to the light curve software — 2014 January 13

Contents

Introduction

On 2014 January 13 a major revision to the software used at the UKSSDC to create X-ray light curves, both of GRBs or objects requested by users, was released. This page gives details of those changes; the contents list above shows what areas have been changed.

The need for this change was driven by the first three entries: the correction cadence, WT-mode centroiding, and to support different attitude files. However, these were fairly significant changes, so we took the opportunity to make several other changes we had been considering for a while. These changes, such as allowing bins to be upper limits, or determined using Bayesian statistics, provide better support for faint sources: the original software was designed for GRBs and then modified to work more generically whereas this new code has been written from scratch to be a generic tool. We also made the code much more memory-efficient and fast: it now takes typically just a few seconds to rebin a light curve. Details of all of these changes are given below.

Note We have added a couple of columns to the output light curves; the definition in the documentation have been updated accordingly, but any scripts designed to read these files may no longer work.

Back to contents | Back to repository

Correction Cadence

The calculation of the correction factors (correcting for bad columns and the size and shape of source extraction region used) has been changed to use the xrtlccorr tool which was released after the original light curve code was built. This unifies the correction factor method employed by our online tools with those recommended for use in manual analysis of XRT data. It has been noticed that Swift is sometimes moving while the XRT is gathering data, especially early in an observation. If the source is near the bad columns, this can introduce spurious artifacts (see the XRT digest). By using xrtlcorr with the recommended cadence (4 s for WT mode, 10 s for PC mode) this can be largely alleviated - provided the position of the source is well constrained in the XRT coordinate frame as discussed next.

Back to contents | Back to repository

WT-mode centroiding

In order to calculate the effect of the bad columns properly, the location of the source on the XRT must be well known. Previously, this has been a problem for Windowed Timing mode, as we have only 1-D spatial information. The position was taken from PC mode data or the user's input and assumed to be correct, but this relies on the spacecraft attitude to be well known, and the systematic uncertainty on this is 3.5′′ (90% confidence) when using the onboard star-trackers. We have produced a tool which fits the 1-D WT-mode PSF to the WT-mode ‘image’ in order to accurately localise the source within the XRT coordinate frame.

Back to contents | Back to repository

Support for different attitude files

In addition to the standard spacecraft attitude file, which determines Swift's pointing direction using the on-board star trackers, new files have been created which contain corrections to this. It is likely that, in the near future, these will be recommended for use instead of the standard attitude file. We have therefore modified the light curve code to determine which attitude file was used to create the cleaned event lists from which the light curves is built, and to ensure that the same file is used by the light curve creation software.

Back to contents | Back to repository

Pile-up

Objects which are piled-up in WT mode can vary by more than an order of magnitude while remaning piled up. This is particularly true for GRBs, which may fade from several thousand counts per second to only a few counts per second in a single snapshot. Previously, if the source was above the fidcual pile-up level (150 count/sec) in WT mode, a single annular region was created for source counts to be extracted from, for the entire time that it was above this level; the size of the annulus was set to ensure that the count-rate never exceeded 150 count/sec. Clearly, this meant that the annulus was much larger than necessary as the source faded. In the new version of the code every time the count-rate changes by a factor of 2 a new annular region is created, appropriate to the count-rate in the newly defined interval. This gives better time resolution while the data are piled up, without diminishing the accuracy of the pileup correction.

Back to contents | Back to repository

Minimum SNR

We have introduced a new parameter for the fixed counts (i.e. GRB-style) binning of light curves: a minimum signal-to-noise ratio (SNR) which is needed for a bin to be considered full. The SNR is defined as S/σS, where S and σS are the number of counts from the source and its uncertainty. This allows us to avoid bins where the count-rate is consistent with 0 even though the detection significance (i.e. S/σbg) is more than 3. By default for the GRB processing, this is set to 1.5

Back to contents | Back to repository

Upper limits and Bayesian bins

To better support fainter sources, users can now select to allow bins to be upper limits (if the detection significance falls below the minimum level specified), or to be determined using Bayesian statistics (if the number of measured counts or the SNR in the bin falls below some level). Previously, upper limits and Bayesian bins were only permitted in GRB-like binning, and only for the final bin of the light curve. The calculation of the Bayesian statistics and upper limit slows the binning process down significantly, therefore it is not advised to set the switch-points arbitrarily high. The default values are that Bayesian statistics are used when there are fewer than 15 counts in a bin (i.e. where Poisson statistics start to converge with Gaussian statistics) or the SNR of the bin is below 2.4. The latter is based on the SNR at which the Bayesian method would claim the detection significance of the bin to be <3-σ whereas the frequentist method would put it at >3-σ (for bins with 15—55 counts in them). For bins with larger numbers of counts or a detection threshold other than 3-σ users are advised to determine the optimum SNR threshold for switching between the Bayesian and frequentist approaches themselves.

Back to contents | Back to repository

Maximum orbital gap (fixed-counts binning only)

This is similar to the maximum bin length, but refers to the maximum duration between snapshots or observations (formally, between Good Time Intervals) that a single bin can span. This is designed so that, when an observation is deliberately scheduled some time after the previous one, to ascertain if the GRB has faded further, the data from this new observation can be forced into a new bin, rather than being tagged onto the previous bin because it was not ‘full&rsquo. As with the maximum bin length it is strongly recommended that Bayesian bins and upper limits be allowed when this is active; GRB 080702B is an example where this feature has been used to separate a single upper limit compiled from several observations into two bins; in this case, both non-detections. For GRBs these values are set by default to 10 days for BAT-triggers GRBs and 1 day for non-BAT GRBs which reflects the typical follow-up strategy of the bursts.

Back to contents | Back to repository

Handling of data gaps (fixed-counts binning only)

Some small tweaks have been made to the way data are handled when a snapshot ends, and the current bin is not full. The logic which decides whether to extend the bin across the gap to the next observation, or whether to append the counts in the incomplete bin to the previous bin, has been improved, with the goal of maximising the fractional exposure in the bin. This results in fewer long, low fractional exposure bins that previously.

Back to contents | Back to repository

Efficiency Improvements

The binning code was previously written in Python, and has been completely redone in C++, with a particular focus on more efficient memory usage. This also has the effect of dramatically reducing the runtime (a typical GRB light curve can now be rebinned in under a second; indeed it takes longer to produce the postscript and gif plots than to bin the data). It is hoped that this will allow the largest XRT datasets to be succesfully processed en masse, although this has not yet been tested.

Back to contents | Back to repository