Skip banner and navigation tools.

 |  site map

Skip sidebars of related page links.

Extracting light-curves using XSELECT

Here we demonstrate how to extract source and background light-curves. The light-curve correction thread explains how to correct the bins for losses caused by bad columns and/or the use of an annular extraction region.

Alternatively, use the online tool to build light-curves etc. This is the easier (and usually recommended) method.

Here, the PC data from the first observation of GRB 091109A are used as an example.

              **  XSELECT V2.2a  ** 

> Enter session name >[xsel]
xsel:ASCA >read event
> Enter the Event file dir >[ ] ./
> Enter Event file list >[ ] sw00375246000xpcw3po_cl.evt

Got new mission: SWIFT
> Reset the mission ? >[yes]

Notes: XSELECT set up for      SWIFT
 Time keyword is TIME       in units of s
 Default timing binsize =   5.0000

 Image  keywords   = X          Y           with binning =    1
 WMAP   keywords   = X          Y           with binning =    1
 Energy keyword   = PI                     with binning =    1

Getting Min and Max for Energy Column...
Got min and max for PI:     0   1023

Got the minimum time resolution of the read data:   2.5073
MJDREF =  5.1910000742870E+04 with TIMESYS = TT
 Number of files read in:            1

******************** Observation Catalogue ********************

Data Directory is: /home/work/kpa/2009/grb091109a/00375246000-xrt/
HK Directory is: /home/work/kpa/2009/grb091109a/003752460001-xrt/

        OBJECT      OBS_ID      DATE-OBS    DATAMODE
      1 Burst (309. 00375246000 2009-11-09T PHOTON

Here we repeat the information given for the spectral analysis thread:

Source and background regions should be defined within ds9; circular regions can be used for both WT and PC modes (examples). If xrtpipeline was run with cleanup=no, the region produced (a 20 pixel radius circle) can be used if the source is not piled-up; if the source is bright, a 30-pixel radius may be a more suitable choice, whereas faint sources are better extracted using smaller areas.

In the case of this example dataset, the first snapshot of data is piled-up, such that the central 3-pixels should be excluded. The pile-up page gives some information about such a situation, but see the pile-up walk-through for a complete step-by-step guide. To change the shape of the region from a default circle, click on the region button at the top of the ds9 window, move down to the "shape" option and pick annulus.

Note that, if the source lies over the bad columns, it may be difficult to determine by eye where the extraction region should be centred. If the coordinates of the source are known, it is often better to input these directly (click on the image in the ds9 field of view, to bring up a circle, then double click on the circle to bring up a box listing the position and radius. Set the coordinates to WCS and then input the decimal degrees, or sexagesimal values, depending on how your preferences are set), since correction factors can vary significantly if the region is poorly placed over the bad columns.

It is a good idea to use a larger region to extract the background spectrum (or light-curve) when using PC data, to get a better average value. A larger circle (radius of 50-60 pixels), multiple small circle or a large annulus centred on the source are all suitable options. Just make sure to avoid any field sources in the extraction region!

Assuming the source extraction region is called ann.reg and the background, bgd.reg, then the following commands will result in a light-curve for the first snapshot of data only:

> filter region ann.reg
> extract curve
> filter time cursor

To start selection enter quit at the PLT prompt then

Enter QUIT at PLT prompt to continue

Time filtering

An image like that shown above (click image for a bigger version) will be displayed once quit has been typed at the prompt. Click just before and after the time of interest - in the above example, the first snapshot has been chosen, as indicated by the white horizontal line. Pressing x (with the cursor still in the window showing the light-curve) will return you to the XSELECT prompt, while writing the time selection to a temporary file:

> quit

Writing timing selections to file xsel_cursor_gti001.xsl

Now a light-curve can be extracted for this first snapshot alone.

> extract curve
> save curve
> clear region
> filter region bgd.reg
> extract curve
> save curve

Additional commands which may be useful are filter pha_cutoff 30 1000 (to filter on 0.3-10 keV; the numbers are in terms of channels, each of which is 10 eV) and set binsize 10 (if you want to set the binsize of the light-curve to 10 seconds). The minimum bin length suitable for use is the frame time of the mode - i.e., 1.8 ms for WT or 2.51 s for PC.

Once the light-curve has been corrected for bad columns and the loss of counts caused by the use of an annulus, and been background subtracted, timing analysis packages can be used, such as the XRONOS suite of FTools available as part of the HEASARC HEASOFT software download.

flx2xsp - light-curves with fixed numbers of counts per bin

For GRB light-curves - or, in fact, any source where the count rate changes dramatically over time - it may be useful to produce a light-curve with a fixed number of counts per bin, rather than a constant time binsize. The FTool flx2xsp is useful in this case, since it takes an ASCII file and produces a file which can be easily binned using the same grppha task as used for spectra. It also enables the light-curve to be read into XSPEC, allowing use of the ready-made models (power-laws, broken power-laws etc). The steps are explained below.

For the default time binning in XSELECT, PC time bins will be 5 seconds in duration, while WT bins are 1 second. The times which come out of XSELECT are with respect to the start time of the event-list, whereas a light-curve with the trigger or outburst time (for GRBs or transients, respectively) may be required. In this case, the bins just need to be shifted in time.

If a light-curve has been extracted as above and corrected for bad columns and background, then the easiest way to get the data into ASCII format (as required for flx2xsp) is to use fplot and then write out the data. For example:

Name of X Axis Parameter[error][ ] TIME
Name of Y Axis Parameter[error] up to 8 allowed[ ] RATE[ERROR]
Lists of rows[ ] -
Device: /XWindow, /XTerm, /TK, /PS, etc[ ] /xw 
Any legal PLT command[ ]
> wd
0 5.9281383 1.5843617
5 2.5406308 1.0372082
10 5.5046997 1.526729
15 2.5406308 1.0372082
20 2.9640691 1.1203128
25 2.5406308 1.0372082
30 2.5406308 1.0372082
35 2.9640691 1.1203128
40 5.0812616 1.4668338
45 2.1171923 0.94683719
50 1.6937538 0.84687692
600 0.42343846 0.42343846
605 0 0
610 0 0

As can be seen, this file (wd filename.txt would save the data to filename.txt, rather than writing it to the screen) is in the form
where TSTART is the start time of the bin, CR - the count rate in the bin and CR_ERR - the uncertainty on the count rate.

However, flx2xsp takes an ASCII file with four columns:


[where, additionally, TSTOP is the stop time for the bin (which must be equal to the start time of the following bin), CR*(TSTOP-TSTART) gives the number of counts (count rate multipled by time) and CR_ERR*(TSTOP-TSTART) - the uncertainty on the number of counts], so the file should be changed into this format.

Once this ASCII file has been created, it should look something like this (again using GRB 091109A as an example):

175.23  180.23  29.64   7.92
180.23  185.23  12.7    5.19
185.23  190.23  27.52   7.63
190.23  195.23  12.7    5.19
195.23  200.23  14.82   5.6
200.23  205.23  12.7    5.19
205.23  210.23  12.7    5.19
210.23  215.23  14.82   5.6
215.23  220.23  25.41   7.33
220.23  225.23  10.59   4.73
225.23  230.23  8.47    4.23
775.23  780.23  2.12    2.12
780.23  785.23  0       0
785.23	790.23	0	0

This should be saved in a text file (e.g. pc1.txt) and run through flx2xsp in this manner:

> flx2xsp pc1.txt pc1.pha pc1.rsp

Make sure that there are no blank lines at the end of the text file (although there should be a carriage-return at the end of the final line of data), since this can lead to problems in some versions of the software.

The pc1.pha file can then be read into grppha and binned as required (e.g. to 20 counts per bin - see the spectral analysis thread for an explanation of how to use grppha). The file only needs binning, however; no other parameters (bad channels, ARFs etc) need to be changed, since this file is not really a spectrum.

flx2xsp requires a separate file for every snapshot (or data bin at times when the source is fainter and multiple snapshots need to be combined for a detection). As a rule of thumb, multiple bins within one snapshot (method as above) are probably useful when there are > 50 counts in the snapshot. If there are 10-50 counts, then a single bin may suffice; when the source is even fainter, multiple snapshots will need to be combined. In these latter two cases, the flx2xsp input should be a single line file of the same form as above:


but here TSTART and TSTOP refer to the start and stop times of the entire snapshot (or the start of the first and the end of the last), rather than the 5 second (for example) time bin. These pha files do not need to be read into grppha, since there is only one data point.

You can determine the numbers of source and background counts either within XSELECT (filtering on the respective region before extracting anything - image, spectrum, light-curve or event-list - since you can read the number of counts from the screen after extraction, as demonstrated in the XSELECT thread for example) or using XIMAGE (read in an image for the relevant time; see XIMAGE thread).

Note that the reason why the files need to have CR*(TSTOP-TSTART) is that XSPEC plots spectra as count s-1 keV-1 against keV. Thus for light-curves, reading in a file in terms of count s-1 against time in seconds would lead to the y-axis being interpreted as count s-1 s-1!

Once the files have been read into XSPEC - along the lines of:

data 1 pc1.pha
data 2 pc2.pha
data 3 pc3.pha

- the complete light-curve can either be fitted within XSPEC itself, or within QDP by typing iplot at the XSPEC prompt.