Skip banner and navigation tools.

Dept. of Physics & Astronomy
XROA

US Site | Italian Site | UK site

Skip sidebars of related page links.

Home > Data Analysis > XRT > Digest > Science

Leicester XRT digest

Things to know, or to look out for, when analysing XRT data. See also the SDC XRT Digest Page which links to various useful documents and the XRT threads page for step-by-step guides to analysing the data.

XRT Science Analysis Status

See also the XRT Calibration digest page

Index

• Optical Loading
• Open issues
  • Bad columns
  • Pointing stability
  • Pile-up
  • Event screening
  • Velocity Aiding
  • Mode-switching
  • Timing
• Closed issues
• Hot spots
• Incorrect RA/Dec in the header
• GRB in the middle of a scheduled observation
• Failure of xrthotpix

Bright optical sources can deposit significant charge in the CCD pixels, affecting the detection of X-rays. This is described on the optical loading page, where we provide graphs showing when optical loading becomes an issue for different stellar types. We also provide an optical loading calculator to predict the level of optical loading for a given star.

OPEN ISSUES

Bad columns

At the end of May 2005, the XRT CCD was hit by a micrometeorite. This has led to a small number of hot columns in PC and WT modes being vetoed in order to prevent saturation of the telemetry. Because of the way the CCD is read out, this method cannot be used for Photo-Diode mode, so this mode is currently disabled.

Unfortunately, because some of the bad columns run down the centre of the CCD, sources occasionally lie on top of, or very close to, them. In this case, the loss of counts have to be corrected for, both when extracting spectra and light-curves. Examples of such a chance alignment are shown below.

The bad columns closest to the centre of the field of view (and, therefore, the most likely to affect any observations) are located at DETX positions of 291-294 for PC (291-295 for WT) and 319-321 (both PC and WT). DETX=290 is an additional partial bad column for PC mode (between DETY=199 and 290). Note that the columns will only be obvious when plotting the image in detector coordinates, or for a single orbit at a time, since using sky coordinates will blur different pointings together, concealing the fact that some orbits may be over the bad columns while others are not.

Figure 1. These panels show the supernova remnant, Cas A, positioned over the bad columns (top panel: PC; bottom panel. Clearly, the number of counts and the flux will be underestimated if this occurs. The software (version 2.3 and after) compensates for these columns during spectral analysis through the production of an exposure map (though see below for a caveat). The extraction of light-curves, however, is still an open issue.

To correct for the bad columns, exposure maps need to be created, and incorporated into the ARFs generated. This procedure is covered by the XRT exposure map thread.

Pointing stability

Occasionally, when Swift is settled on a target (rather than slewing), an instability can cause the source to drift around on the detector. If the source is close to one of the bad columns, a small movement can cause the core of the PSF to become hidden by the bad columns, leading to a drop in the detected count rate. An example of such an event is shown below.

Figure 2. The plot above shows an observation of RS Oph, where an instability in the pointing direction caused the source to wander towards and over the bad columns, then jump away again. The ordinate shows the position of the source in terms of DETX, while the abscissa shows increasing time (from left to right).

In an upcoming release of the software, there will be a new XRT tool which will correct light-curves for the presence of bad columns. As well as an orbit-by-orbit correction, it will be possible to correct up to the maximum time resolution of the onboard frame times (i.e., about 2.5 seconds for PC and 1.07 seconds for WT), to compensate for such pointing instabilities as discussed here.

Pile-up

Pile-up in CCD cameras occurs when there is a significant probability that two or more photons registering within a given CCD frame will have overlapping charge distributions. This can lead to a spectral distortion if the resulting distribution is recognised as a single event whose energy is the sum of the overlapping events (i.e., two or more soft X-ray photons can be registered as a single higher-energy photon), or a flux loss if the charge distribution has a pattern, or grade, outside that clasified as a true X-ray event (0-12 for Swift Photon Counting mode; 0-2 for Windowed Timing).

For basic details on how to estimate the level of pile-up, and how to correct for it, see the pile-up analysis thread.

Useful papers containing details about Swift pile-up analysis:

• Swift observations of the X-ray bright GRB 050315, Vaughan, S. et al., 2006, ApJ, 638, 920
• Multi-wavelength study of the prompt and afterglow emission of GRB 060124, Romano, P. et al, 2006, A&A, 456, 917
• The Swift X-ray flaring afterglow of GRB 050607, Pagani, C. et al, 2006, ApJ, 645, 1315

Event screening

There are a number of issues of which users should be aware when it comes to data screening.

Temperature

Because of the failure of the Thermo-Electric Cooler power supply, the XRT CCD routinely operates between about -70 and -50C. By default, xrtpipeline excludes any data which were obtained at temperatures higher than -47C (from v1.2 of the software onwards). This can be changed either by including a GTI expression directly when running the pipeline (this method is needed to include data taken at higher temperatures which would usually be thrown away, e.g. xrtpipeline gtiexpr="CCDTemp>=-102&&CCDTemp=<-45"), or by later filtering within XSELECT (e.g. select mkf mkf_dir=./ mkf_name=sw[obsid]s.mkf "CCDTemp<-55").

While less stringent filtering on the temperature will sometimes lead to more exposure time, there is the possibility of more hot pixels appearing within the data.

Bright Earth and Elevation angles

When the angle between the XRT and the limb of the Earth is small, the average background level is higher. An extreme example is shown below.

Figures 3 and 4. The left-hand image shows the field of GRB050223 before filtering. The right-hand image has been cleaned within XSELECT (filter pha_cut 30 1000; i.e., photons below 300 eV have been removed). The green circle shows the position of the burst in both cases.

Velocity Aiding

Velocity aiding was switched off onboard the spacecraft at 21:57 UT on 31st January 2005. Data obtained before this date should include the command aberration = yes when running xrtpipeline (the default for all recent versions of the pipeline is aberration = no).

Mode-switching

When the CCD temperature is around -52C, certain hot pixels become active. Although many are masked out, this can lead to "mode-switching"; this occurs when the count-rate within the centre of the field of view is close to the PC/WT switch point. This means that, even if you expect your object to be in PC mode, a substantial portion can end up in WT event files. Exposure time is lost with each mode change. This is annoying, but there is nothing that the user can do about it. The science planners at PSU do a very good job at keeping the temperature down, but sometimes it's not possible (or a new burst turns out to be in a part of the sky which causes the XRT to become particularly hot).

Timing

• Up to and including version 3.6 of the Swift software

Prior to version 3.7 of the software (HEASoft 6.10), extractor/xselect ignored the TIMEPIXR keyword which defines whether the TIME keyword refers to the start (TIMEPIXR=0), middle (TIMEPIXR=0.5) or end (TIMEPIXR=1) of the frame. Instead, it always assumed that the time corresponded to the centre.

The values of the TIME column of PC event files actually refer to the beginning of the CCD frame (duration=2.507s) - i.e., they have the TIMEPIXR keyword of 0. For software earlier than version 3.7, light-curves produced via xselect/extractor will have the keyword incorrectly set to 0.5. This can be changed (for a file called lightcurve.lc) using the following command: fparkey 0. lightcurve.lc+1 TIMEPIXR. This corrected file can then be analysed as usual within xronos/lcurve, which does take account of the TIMEPIXR keyword.

This is only the case for PC data, however. The event time values for WT data correspond to the middle of the bin, meaning that the extractor/xselect bug for these earlier software versions is not a problem.

• Version 3.7 of the Swift software

Extractor/xselect now checks for the TIMEPIXR keyword, with an event now being defined as good if the middle of the frame lies within the Good Time Interval (GTI). However, the GTI START and STOP times (and event file TSTART and TSTOP keywords) produced by extractor are not set to the frame boundaries but fixed at the user-specified values; this means that, for short exposures the exposure times may be significantly incorrect. It also means that events can be included in an extracted dataset which have TIME values which lie outside the GTI range. This can cause problems in downstream software such as xrtexpomap. At present the only solution to this is to ensure that your time filter values match up with frame boundaries.

A new version of extractor has been produced which should be included in the next release of the software. This has a (hidden) parameter: adjustgti. If set to "yes" this will automatically cause user-supplied time-filters to be reset to frame boundaries (without changing which events are included), which solves the problem.

In addition, TIMEPIXR is incorrectly set to 0 in the WT event lists; while the extractor/xselect bug cancelled out this error in earlier versions of the software, this is no longer the case. The keyword will be corrected in a future release of the software, however will not immediately be retroactively applied to the archival Swift data, or to new Quick Look data. Users should issue the command fparkey 0.5 wtmodeeventfile.evt+1 TIMEPIXR for any WT mode event list they use. Note that we always recommend that users run xrtpipeline (see analysis thread) themselves, rather than using the cleaned event lists taken directly from the archive.

This file explains how to check for a periodicity in XRT data.

CLOSED ISSUES

Hotspots

There are 3 "hot spots" or "burn marks" in the centre of the XRT CCD. These are areas of enhanced dark current due to focussing of X-rays during the ground calibration before launch. These would not be visible below about -90C, but, because the CCD is not as cool as expected, the spots were sometime visible in earlier data and could be mistaken for a GRB afterglow if the user is not vigilant! The positions are known in detector coordinates. These are labelled in the image below. Filtering out the lowest energies tends to make these spots disappear. Do this by using the pha_cut command in XSELECT (e.g., filter pha_cut 30 1000 filters between 0.3 and 10 keV).

These areas are now masked out as bad pixels, so should seldom be a problem.

Figure 5. The three "hot spots" are located at (321, 298), (325, 263) and (340, 285) in detector coordinates (set xyname detx dety before extracting an image in XSELECT).

Incorrect RA/Dec in the header

For some of the early (start of 2005) Swift data, the RA and Dec in the headers of the raw files are set to zero or 90, rather than the position of the target. This causes the pipeline to crash in normal circumstances. To side-step this problem (very rare now), use the dummy attitude file sw00000000000sat.fits.gz as follows: xrtpipeline attfile=sw00000000000sat.fits.gz

The problem is believed to be fixed for all recently-processed versions of the data.

New GRB during a Manual State observation

This event can only occur if the XRT is in Manual State, rather than its usual Auto State; some of the earlier (before April 2005) datasets were interrupted in this manner. If this happens, the event-list for the original target may also include data for the slew to the burst and subsequent snapshots. This complicates matters, since the RA and Dec have changed part way through the observation. The header files will include the coordinates of the original target, rather than those for the burst, thus processing the data in the normal way will show a field of view not containing the GRB.

To fix this problem, RA_PNT and DEC_PNT in the xhd.hk file must be changed to the required position:

Within the sw<obsid>/xrt/hk directory there will be a file called sw<obsid>xhd.hk, within which can be found keywords called RA_PNT and DEC_PNT (in 2 separate extensions). These should be changed from the values of the original target to those of the GRB of interest using the fparkey command

For example, if the required RA and Dec are 278.103333 and 42.365000 respectively, use the commands (obviously including the correct <obsid>):

fparkey 278.103333 sw<obsid>xhd.hk+0 RA_PNT
fparkey 278.103333 sw<obsid>xhd.hk+1 RA_PNT
fparkey 42.365000 sw<obsid>xhd.hk+0 DEC_PNT
fparkey 42.365000 sw<obsid>xhd.hk+1 DEC_PNT

Then xrtpipeline can be run as normal. Following this, the cleaned event-list should be read into XSELECT as normal. Then the housekeeping file also needs to be read in, using the command read hk; XSELECT then prompts for the location of the housekeeping directory (sw<obsid>/xrt/hk) and the name of the HK file (sw<obsid>xhd.hk). The select command can then be used to choose the relevant RA and Dec. For the example here, this would be:

select hk "RA>260&&Dec<50"

Failure of xrthotpix

Occasionally xrthotpix failed with older versions of the Swift software, giving the message:

ERROR: Operation not permitted
Task xrthotpix 0.1.5 terminating with status 1

If this happens, the cleaned event-list will not be generated for the pointing observation.

When running xrtpipeline, include impfac=2000 on the command line. This parameter is used to compute the background level. The problem has been fixed for v1.2 (and later versions) of the software.