Skip banner and navigation tools.

 |  site map

The Swift-XRT data products generator

Build XRT products.

Contents

Overview

This facility allows the creation of publication-ready X-ray light curves, spectra and images, and the calculation of positions, of any point source in the Swift XRT field of view. Images of the field of view can also be created. Instrumental artifacts such as pile up and the bad columns on the CCD are corrected for.

The tools which create these products are based on those which run automatically for GRBs, and those developed for the 2SXPS catalogue , which in turn, make heavy use of the Swift software and FTOOLs. All products are fully calibrated and corrected for effects such as pile-up and the bad columns on the CCD. The following products can be created:

Although spectra are automatically fitted, the spectral files are available for download as a tar file should you wish to fit different models or interact with the fit.

To create products, simply fill out and submit the form. At the top of the form is a list of the products you can build, which are initially all deselected. Please only select those which you require, since we have a finite number of processors available, and unnecessary jobs may delay another user's important processes. For each product you select, a new form will appear, allowing you to give the specifics of what you want. The object details section is mandatory and identifies the object you want to analyse, and the datasets in which it can be found. The label for each form field is a link; following it opens a help box in the top left of the window, which gives summary information about the field. Full details for each option follow here. Note that any control characters (& ; etc) will be removed from your input.

For details of how the products are constructed, please see the refereed papers, listed below.

Back to contents | Back to product generator

Usage and acknowledgement policy

Users may publish any products created using these web tools, provided that this facility is acknowledged. We request this be done both by citing the relevant paper (see the list below) when the data products are introduced, and by including the following text in the acknowledgements section of the paper (not necessary for ATELs or circulars):

This work made use of data supplied by the UK Swift Science Data Centre at the University of Leicester.

The appropriate references are:

Light curves
Evans et al. (2007) [BibTeX], Evans et al. (2009) [BibTeX]
Spectra
Evans et al. (2009) [BibTeX]
Standard/Enhanced positions
Goad et al. (2007) [BibTeX] Evans et al. (2009) [BibTeX]
Astrometric positions
Evans et al., (2014) [BiBTex]
Source detection
Evans et al. (2020) [BiBTeX]

If images created through this facility are used, e.g. in a press release or on a website, please ensure that the correct image credit is used: (Phil Evans/Swift/UKSSDC).

Back to contents | Back to product generator

How to use the products generator

To build the data products, simply complete the relevant sections of the web form, and click “Build products”. Your request will be queued in our system and executed as soon as possible, and you will be redirected to a web page showing the status of the job and (for most products) an indication of the progress. Jobs are allotted a maximum runtime of 24 hours once they are executed (i.e. if they are first queued, the queue time does not count as part of the 24 hours), after which the system terminates them, however it is very rare for a job to require this amount of time. Upon completion the results will be available for at least 3 days, however we recommend that you download them as soon as possible after completion.

The products generator form consists of up to six sections, all of which are described below. The first two are mandatory and are always visible; the other four relate to the specific products which can be built, and are only shown when those products are selected. The sections are:

Object details form [Mandatory]

In this mandatory section of the form you should supply the basic details of the object to be analysed.

Name
The name of the object. Primarily a cosmetic detail, however the "Find" button will use the name to determine the target ID, RA, Dec and start time if possible. The RA and Dec will be taken from SIMBAD, if the name can be resolved. If not, the values will be taken from the spacecraft pointing information during the first observation of the source. This may differ from the object position, so the default search radius is increased to 3′ in this case. When you submit the form, the co-ordinates supplied are not checked against any catalogued position for the source name. Although your products will be labelled with the name you supplied, they will be produced for the position you supplied.
Important notes:
  • SIMBAD coordinates may not reflect the most accurate position, especially for transient events in which the SIMBAD position may reflect the discovery position (e.g. from MAXI or INTEGRAL) which can be some distance from the true position found in follow up. It is strongly recommended that you verify the position.
  • Instead of entering a name, you can enter a position; in this case the "Find" button will identify all observations that overlap that position.

Target ID
The target ID of the observations of your object. If your object has been observed using multiple target IDs, these should be separated by commas, with no spaces, e.g. 00050100,00058990. This field is filled in automatically if the name is resolved successfully.
Start time
The time zero-point of the observations. This is used to scale the x-axis in the plots. If this is left blank, the TSTART value of the first event list will be used. Accepted time formats are given below. If the name is successfully resolved this field will be automatically set to contain the Swift Mission Elapsed Time at which the first observation of your target began.
“All input times since this”
If a start time is supplied, this can also be used as the zero-point for any times entered elsewhere on the form. This only affects times entered in seconds: MJD values, for example, are absolute and are not adjusted if this option is selected.
Coordinates
The position of the object of interest, epoch J2000. This is filled in automatically if the name is resolved succesfully. Note that, if the name could not be resolved by SIMBAD, but matches a target name in the Swift observation database, the RA and Dec are taken from this database. Coordinate entry is free-format (see the acceptable coordinate formats section below).

Global options [Mandatory]

In this mandatory section of the form you set options which affect multiple products.

Try to centroid?
Whether the software should attempt to centroid on the source, to get the best position in the XRT astrometric frame. This only affects the light curves and spectra. Ordinarily this should be set to Yes unless there are no PC-mode data available. For faint sources, or very crowded fields, the software may fail to centroid correctly; in these cases you should manually complete the “Coordinates” field (above), supplying the best position in the XRT co-ordinate frame and disable centroiding. Note that the quality of the products is strongly dependent on the quality of the position.
If centroiding is enabled, there are several extra options:
Centroid method
How the centroiding should work. For moderate to bright sources the default Single pass method is suitable. This uses a simple sliding-cell method to detect the source, and then performs a PSF fit. For fainter sources, it may be necessary to use the (much slower) Iterative option. This employs the complex, iterative detection process developed for the 1SXPS catalogue.
Max attempts
By default the initial source-detection and centroiding is performed only on the first observation (to minimise runtime). If the source cannot be detected in that observation, the software will instead try the second observation, and then third etc. If the source cannot be detected in any of the individual observations, a stacked image of all requested datasets will be created, and source detection is performed on that image; this is a much slower process than centroiding on a single observation, which is why the software tries to find the object in a single dataset before reverting to a stacked image. The “Max attempts” option specifies how many individual observations the source detection should attempt to work on before reverting to the stacked image.
Search radius
The radius from the input position (in the “Coordinates” box) in which to search for the source. The brightest object detected in this circle will be assumed to be the object of interest.
Super-soft source?
For super-soft sources, where the majority of photons are below 1 keV, pile-up occurs at lower count-rates than for normal sources. Selecting this box identifies your object as a super-soft source and causes only grade 0-4 events to be used for PC mode, and only grade 0 for WT. Also, the count-rate at which the data is treated as piled-up is reduced. These choices both help to eliminate the pile-up. This only affects light curves and spectra.
Use 2SXPS source lists
When building light curves or spectra, the software has to compile a list of unrelated sources in the XRT field of view, so as to ensure that these are not included in the background sampling region. By default, this is done by creating an image comprised of all the requested data, and performing source detection on it. If the dataset(s) requested correspond exactly to an entry in the 2SXPS catalogue, the source list from the catalogue can be used instead, removing the need to perform the (time-consuming) search for background sources.
E-mail address
If a valid address is supplied, an e-mail will be dispatched when each of the requested products has been produced, or the process fails for some reason. We recommend that you use this facility, as jobs can take a long time to complete. The e-mail address will include the URL of your finished products.

Back to contents | Back to product generator

Light curve details form

The first option in the light curve form is the “Binning method” which specifies how the data are binned. Which options are then displayed depends on the method selected. After the method-specific options, there are some options which apply regardless of binning method. Note that PC and WT mode data are always binned separately.

There are 4 binning options available:

Binning by time

In this method, the bins are set to be of a fixed duration. If the observation is non-contiguous (it spans multiple snapshots or ObsIDs) and the bin size is smaller than the gap in observations, bins which lie entirely in times where Swift was not observing the source are not produced. There are several options on the web form which are only available when time binning is selected:

Bin length (s)
The duration of the bins. Can be different for WT and PC mode.
Hardness ratio bin length
The length of each bin in the hardness ratio. By selecting "Same as main curve" you can force this to follow the main light curve settings.
Min fractional exposure
You can select to only create bins where the fractional exposure (exposure time in the bin as a fraction of the bin duration) is above some threshold. This can be useful for eliminating apparently spurious bins which are caused by low fractional exposure.

Back to contents | Back to product generator

Binning by counts

This is the method used for binning GRBs and is described in detail in Evans et al. (2007). In summary: a bin is considered ‘full’ when the following criteria are met:

  1. There must be at least X counts in the source region.
  2. The bin must be at least Y seconds long.
  3. The bin must use all events from a given CCD frame.
  4. The source count rate must be at least Z-σ above the background.
  5. The signal-to-noise ratio must be at least Q.

The variables identified above as X, Y, Z, Q can be changed through the options on the form, as detailed below.

Counts per bin
The number of counts, X.
Min bin length
The shortest duration a bin can have, Y.
Dynamic binning
X does not have to be a fixed value, and indeed for objects like GRBs, which may vary by many orders of magnitude in flux, a fixed value is not sensible. Therefore the data can be dynamically binned: the criterion X becomes a function of count-rate, thus:
When the count-rate is 1 ct/sec, X counts are needed to fulfill criteron #1. When the count rate changes from 1 ct/sec by some factor (the rate factor), X changes by some other factor (the bin factor). The default values for these factors are 10 and 1.5 respectively, thus an order-of-magnitude change in count rate produces a factor of 1.5 change in bin size. This is done discretely rather than continuously, so if X=20 then where the count rate lies in the range 1-9.99 cps a bin must contain at least 20 counts. However, when the count rate is 10-99.99 cps, there must be 30 counts for a bin to be full. At lower rates of 0.1-0.99 cps, only 13 (=20/1.5) counts are needed to complete a bin.
Rate/Bin factor
The settings to control the dynamic binning (see above).
Minimum counts per bin
The absolute minimum counts-per-bin value. If the dynamic binning calculation reduces X below this level, X is set to this minimum level instead.
Minimum SNR per bin
The signal-to-noise ratio threshold, Q needed for a bin to be full. The SNR is defined as R/ΔR where R is the count-rate in the bin, and ΔR is its error.
Maximum orbital gap
At the end of an observation, the critera for a full bin may not have not been met. In this case, the software will either append those counts to the previous bin, or continue accumulating the counts in this bin in subsequent observations, whichever approach maximises the fractional exposure in the bin. The “Maximum orbital gap” option sets the longest single interval between observations which a bin can span. If the gap exceeds this, the bin is saved, even if it is not ‘full’. Depending on your settings (see the common binning options) this bin may be an upper limit, or binned using Bayesian statistics.

Back to contents | Back to product generator

Binning by snapshot

This option causes one bin to be created per snapshot (i.e. spacecraft orbit). There are no controls specific to this method.

Back to contents | Back to product generator

Binning by observation

This option causes one bin to be created per observation (i.e. data collected in a single ObsID). This method should not be used in conjunction with ObsIDs which overlap in time, for example where a slew-in-place has been requested. In these circumstances the light curve would be incorrect. For cases where two obsids are used in a single snapshot (usually because of a slew-in-place) the data will be combined into a single bin which is then labelled by only one of these obsids. There are no controls specific to this method.

Back to contents | Back to product generator

Options common to all binning methods

Minimum sigma
The significance of a bin required for the source to be considered as detected in a given bin. If the bin is frequentist (see below) then the significance, σ=R/ΔB; where R is the (background-subtracted) source count-rate, and ΔB is the uncertainty in the background count-rate. For Bayesian bins, the significance is defined as the probability enclosed in the integration at the point at which the lower confidence interval on the source count-rate goes to zero (see Kraft, Burrows & Nousek 1991).
The impact of the minimum sigma depends the other options specific for the light curve. For the time, snapshot or observation binning, if a bin is complete, but does not have the desired significance then an upper limit is produced, provided that such limits are permitted. If upper limits are not permitted then the minimum sigma option has no effect, and the bin is saved as normal.
When binning by counts is selected, this field corresponds to the parameter Z in the critera for a full bin. Therefore a bin will not be considered complete until the significance reaches the specified level; unless the bin is the last bin (i.e. there are no more data) or an orbital gap longer than permitted is encountered. In these cases, the situation is as for the other binning methods just described, i.e. an upper limit is produced, if permitted.
Allow upper limits
If this is set to Yes then any bins with significance below the specified “Minimum sigma” will be treated as non-detections, and instead an upper limit is produced. The confidence interval of the upper limit corresponds to the “Minimum sigma” value. i.e. if this is set to 3, then all bins must either correspond to 3-σ detections, or will be a 3-σ upper limits.
Allow Bayesian Bins
By default the source flux is determined by frequentist statistics, i.e. S=C-B, and ΔS=√(C+B), where S, C and B are the number of source counts, measured count and expected background counts respectively. This implicitly assumes that there are sufficient counts (C) for the errors to be treated as being Gaussian. At low count-rates this will not be true, so instead by default the software reverts to the Bayesian approach of Kraft, Burrows & Nousek (1991) to determine the rate and errors. This approach gives asymmetric errors, since the minimum source count rate permitted is 0. You can choose to disable this feature, requiring all bins to be frequentist. This can reduce the time taken to accumulate some light curves, but we caution that, for bins with fewer than fifteen counts, the frequentist count-rate errors are likely to be unreliable.
If Bayesian bins are enabled, there is an additional option:
Use Bayesian when below
The minimum number of counts and signal-to-noise in the bin necessary for a frequentist bin. If either of these thresholds are not met, a Bayesian bin is constructed.
Time axis unit
Whether the time should be plotted in MJD or seconds. If MJD is requested, the conversion from Swift mission elapsed time (MET) to MJD is not performed for each bin individually (this would be very slow for large light curves). Instead it is performed once per day for the days covered by the light curve, and then for bins within that day the MJD is calculated by adding (seconds since reference time)/8400 to the reference MJD calculated. Due to the drift in the spacecraft's internal clock this introduces a small error, typically of order 0.005 s. However if timing more accurate than this is required we do not recommend using this service as no barycentric corretions are applied.
Energy and grade selection
The default setting is to extract light curves using events of grade 0-12 (or 0-2 for WT mode), between 0.3 and 10 keV. For the hardness ratio, the soft band covers 0.3-1.5 keV and the hard band 1.5-10 keV. If this option is set to "User specified" these numbers can be changed. For grades there are three options: to use all valid grades (0-12 for PC and 0-2 for WT mode), which is normally recommended; the ‘restricted’ grade range (0-4 for PC, and 0 only for WT), or only grade 0 events. See here for more details. If unsure, accept the default (all valid grades). If you do not know what this means, use the default. If the “Super-soft source” option was set, the ‘restricted’ set is selected, and this cannot be changed.
Specify observations
This allows you to specify that only a subset of the available observations are used for the light curve. This is discussed in Choosing observations or time intervals, below.

Back to contents | Back to product generator

Spectrum details form

New options were added on 2022 August 5, these are marked with an * below.

*Fit spectrum?
By default any spectra created have a model automatically fitted to them using xspec; you can choose to disable this step if you wish. If you do disable fitting, the model-related fields below will be hidden.
*Galactic absorber
Whether to include an absorption component with a fixed column density representing the expected Galactic column.
Use redshift?
Whether the (non-Galactic) absorption component should be calculated at a specific redshift. If this is set to ‘Yes’ then a Galactic absorber is automatically included.
Redshift
If you said ‘Yes’ to the above you must supply the redshift to be used.
*Which models

You can fit up to three models to the created spectra. These all have a free-to-vary absorber (optionally with redshift), an optional Galactic absorber, and then a single emission component. You can select the following emitters:

  • Power-law
  • APEC
  • Blackbody

Note that selecting multiple emitters will mean multiple fits. i.e. if you select power-law and blackbody, you will get an absorbed power-law model fit and an absorbed blackbody model fit. You will not get an absorbed ‘power-law + backbody’ fit.

Use which observations
This allows you to specify which of the available observations are used to create the spectrum. This is discussed in Choosing observations or time intervals, below.
Grade range

Which event grades to include in the spectrum. There are three options: to use the default grades (0-12 for PC and 0-2 for WT mode), which is normally recommended; the ‘restricted’ grade range (0-4 for PC, and 0 only for WT), or only grade 0 events.

Radiation damage and the build up of deep charge traps within the XRT CCD pixels are responsible for an effect known as grade migration in PC mode, whereby a fraction of grade 0 (i.e. single pixel) events are converted to grade 1 (vertically up-split) events when the trapped charge is released into trailing pixels as the CCD is read out. This effect has evolved with time and causes a slight reduction in the measured grade 0 count rate. These events can still be recovered by selecting grade 0-4 (or 0-12) events. While grade 0 only event selection can be used to alleviate some of the spectral distortion caused by pile-up, we recommend using grade 0-4 events instead, to ensure the otherwise lost grade 0 events are accounted for.

If the “Super-soft source” option was set, the ‘restricted’ set is selected, and this cannot be changed. Note that the counts-to-flux conversion factor deduced from this spectrum is appropriate to the grade selection used, so if you intend to convert a count-rate light curve into flux, the light curve must be created with the same grade selection.

Time for spectrum
By default, all data contained within the selected observations are included in the spectrum. Options also exist to create one spectrum per snapshot (spacecraft orbit) or per observation. If you wish to define specific or multiple time ranges, select "User defined" from the drop-down menu. You can then enter up to four time regions. Each region must have a name and a time region. The latter is of the format start-stop (see accepted time formats) and can include multiple intervals separated by commas.

Back to contents | Back to product generator

Position form

There are up to three types of position which can be produced:

The first two options in the position form are applied to all types of position: the subsequent options control which positions are produced. For all positions, the errors reported include the systematic astrometric uncertainty.

Inclusion radius
All three position determination methods first attempt to detect the source (for the standard positions, this can be disabled). Only objects dected within this “inclusion radius” of the input coordinates are considered. If more than one source is found in that region, the brightest one is assumed to be the source of interest.
Use which observations
This allows you to specify which of the available observations are used to generate the position. This is discussed in Choosing observations or time intervals, below.
Standard position
A standard position is one where the astrometry is derived from the Swift star-trackers. The position is determined using the source detection and localisation methods employed in the the 1SXPS catalogue. The systematic astrometric uncertainty associated with standard positions is 3.5″ (90% confidence) and is included in the reported error. If you select to create a standard position, extra options are available:
Method
You can select Centroid only, to simply perform a PSF fit using as a starting point the position supplied in the “Coordinates” box; or Detect & Centroid if you wish to use the source detection system to find the closest source to your input position and then PSF fit on that. Obviously, you select Centroid only but your input position does not cover a source, the result will be meaningless.
Detection method
If you selected Detect & Centroid above then you should also specify whether the detection method should be a simple, single-pass cell-detect, or the iterative process developed for the 1SXPS catalogue. For moderate to bright sources, the single-pass method should be reliable and is much quicker than the iterative approach; for faint sources it is usually necessary to use the slower, iterative approach.
Enhanced position
Enhanced positions are those where the astrometry is derived using field stars in the UVOT images. In order to produce an enhanced position, the X-ray source must be bright enough for the object to be detected during times restricted to individual UVOT exposures. This technique does not require the source to be detected by the UVOT; that instrument is being used purely as a star tracking device. The systematic astrometric uncertainty associated with enhanced positions is 1.4″ (90% confidence) and is included in the reported error. For full details of the enhanced positions, see Goad et al. (2007) and Evans et al. (2009).
Astrometric position
These positions are derived by first detecting and localising all sources in the XRT image, and then matching them with sources in the 2MASS catalogue. Since the first step is the same as that used to create a standard position, requesting an astrometric position automatically selects a standard position. There is no systematic error associated with astrometric positions, however the size of the statistical error depends strongly on how many X-ray sources are available to align with the 2MASS catalogue. For full details of the astrometric positions, see Evans et al. (2014).
By default the astrometric position uses the data specified by the “Use which observations” option. However, the quality of an astrometric position depends on the number of X-ray sources detected and therefore the best astrometric position is usually obtained by using all of the available data covering the source. For standard and enhanced positions, it is usually not necessary to use all available data to achieve the optimal result (since those positions rapidly become dominated by the systematic error). Therefore when an astrometric position is requested an additional option is provided to “Use all observations for X-ray astrometry?” If this is selected then the astrometric position ignores the “Use which observations” field and instead uses all available data. This allows you to specify a limited dataset for the standard or enhanced position, but still use the full dataset for the astrometric one.

Back to contents | Back to product generator

Image form

If images are requested, they are produced both in FITS format and as gif images. Exposure maps with and without vignetting included are also produced. There are three options governing image creation:

Energy Bands
What energy band you want images to cover, provided as a comma separated list of lowen-highen values. Energies should be in keV. The default setting is to create 3 images, 0.3-10 keV, 0.3-1.5 keV and 1.5-10 keV.
Note: image creation is completely independent from position determination: restricting the energy bands of the images has no effect on the source positions determined.
Use which observations
This allows you to specify which of the available observations are used to generate the images. This is discussed in Choosing observations or time intervals, below.

Back to contents | Back to product generator

Source detection form

This option allows you to request a blind-search for sources be carried out on an observation, or set of observations of your choice. This detection system is almost identical to that used to build the 2SXPS catalogue, except that times with potentially bad astrometry are not filtered out (this may be added as a future improvement).

Please be aware that source detection can be very slow if many datasets are combined, and requests with many datasets may overrun the allowed time and be terminated. For this reason, the default form settings require you to specify which data will be used.

This is the only product available in which the coordinates entered in the global options are not used. But the targetID is still used, in conjunction with the entries described below, to decide which datasets are used for source detection.

Use which observations?
This allows you to specify which datasets are included in the source detection, and is discussed in Choosing observations or time intervals, below. In many cases we anticipate users will want to analyse a single obsid, in which case simply entering that obsid in this box (and the corresponding targetID in the global options target ID box) will achieve this.
Which energy bands?
By default source detection is performed only on the 0.3—10 keV energy band (this is referred to as the ‘total’ energy band, although the raw XRT data do contain some events below 0.3 keV, which are removed before source detection). You can also select to include the 3 energy sub-bands defined for the SXPS catalogues. These are:
  • Soft (0.3—1 keV)
  • Medium (1—2 keV)
  • Hard (2—10 keV)
We do not allow the arbitrary selection of energy bands and have no plans to do so.
Model stray light?

Stray light is caused by X-rays from sources a few tens of arcminutes outside the XRT field of view; these undergo a single reflection off the X-ray optic (instead of the double-reflection for in-field sources), and produce artifacts in the form of concentric rings on the detector. This in turn gives rise to large numbers of spurious detections.

For 2SXPS Evans et al. (2020) developed tools to predict when a source bright enough to produce visible stray light may be present, and to model the effect, including this in the background map. When successful, this can reduce or even eliminate the detection of spurious sources resulting from stray light. This system is not perfect! You can choose here whether or not to enable it.

Back to contents | Back to product generator

Choosing observations or time intervals

For each product you can choose which data are used to build the products. The options (not all present for all products) are:

All three of these are self-explanatory, but the format of the latter option requires some explanation. To specify manually which observations are included, you can supply a list of ObsIDs, a time range, or a mixture of the two. You can enter several time intervals, separated by commas. For example, if your object had been observed all year, but you did not want to include the summer observations, you could state 2008/01/01-2008/05/31, 2008/09/01-2008/12/31. Valid date/time formats are detailed below. If a time interval is specified as a single ObsID, only that observation will be included, however if you enter an ObsID as part of a time range, then the start/stop times of that observation will be parsed and used in the calculation. For example, the entry: 00282445000 will include only observation 00282445000; but an entry such as 00282445000-00282445003 would include all observations matching your target list, that were taken between the time at which obs 00282445000 started and obs 00282445003 ended. Similarly, 00282445000-2014/10/01 would identify all observations between the start of 00282445000 and the calendar date 2014 October 1.

Only observations which both start and finish within the specified time ranges are included.

Back to contents | Back to product generator

Data input formats

While efforts have been made to allow users to enter data in any format they desire, it is not possible to transparently handle any conceivable input. Details of the supported input formats are below.

Time formats

Although none of the time fields is mandatory, there are several places you may wish to enter a time. The same formats are acceptable in each box, although see the important caveat for calendar dates.

There are 3 general time formats permitted:

Note that dates before the Swift epoch of 2001 January 01 are not accepted.

Calendar dates

The general form for calendar dates is year month day, delimited with spaces or slashes (/) or hyphens (see caveat below). A time may also be appended as hours:minutes:seconds. This should be separated from the date either by a space, a T, @ or the word "at". The year must be a 4 digit number, month can be either the full month name in English, the first 3 digits of the month, or the month number (January=1). If no time is specified, 00:00:00 UT is used. Some examples of valid formats are given below.

Important caveat: The use of hyphens as delimiters is only possible in the "Start time" box. Any box accepting a time range uses hyphens to separate the start and end times, so, for example 2009-09 would be interpreted as "from 2009 until 9" which in turn would generate an error as these are not valid inputs.

Back to contents | Back to product generator

Julian Dates

Julian Dates or Modified Julian Dates can simply be entered as they are, optionally prefixed with JD or MJD. For example 2454950.5, or 54950 are acceptable Julian Dates.

Back to contents | Back to product generator

Mission Elapsed Time (MET)

MET is the time used internally by Swift; any times you enter are ultimately converted to MET. If you know the MET of the time in question, you can enter it directly. Any purely numeric (or exponential) number entered in a time box which cannot be parsed as a calendar date or Julian date will be assumed to be an MET value. If the “All input times relative to [start time]” option is ticked, the MET values will be interpreted as being relative not to the Swift Epoch, but to the start time. For time-resolved spectra, if the number is less than 108 it is interpreted as the time since the start time regardless of whether this box is ticked.

Back to contents | Back to product generator

Coordinate formats

Coordinates must be entered as RA followed by Dec, separated either by a comma or space. Each co-ordinate can be in decimal degrees or sexagesimal. In the latter case RA is interpreted as being in hours, not degrees. Coordinates are assumed to be in J2000.0 and will not be precessed.

Sexagesimal input must have at least minute accuracy, but apart from this any valid format should be correctly parsed. For RA, hours, minutes and seconds can be separated by spaces, colons or h, m or s. Sexagesimal declination entries can be separated by colons, spaces, d, m, ', s or ". Note that meaningless use of these delimiters will result in an error. For example legal values for RA include 12h34m12s, 12 34.2 or 188.55, but 12d34m would generate an error, d cannot be used to separate RA hours from RA minutes! Some examples of valid inputs are below. This is not exhaustive.

Back to contents | Back to product generator

Caveats

General

The software used to create XRT products has been designed to work for point sources. Source localisation, pile-up detection and correction, bad column correction etc. are directly affected by this assumption. These tools should not be used to create products for extended objects.

The time taken to create your products can take anything from a few minutes to a few hours, depending on the current number of jobs running, the number of observations included in your request, and the number of source events (for light curves). It is thus recommended that you bookmark the "working" page to which you are taken after submitting the form. We also suggest you supply your e-mail address, so that you are notified once your products are built, and given the link to them. In extreme cases, for very bright sources with many observations, we recommend that users submit multiple jobs (ideally sequentially), requesting only a few observations in each one.

Light curves

For normal, non-Bayesian bins errors are propagated according to Gaussian statistics. If you choose not to allow Bayesian bins, then any bins with fewer than approx. 15 count may well have incorrect error values. The onus is on the user to check for such cases.

The maximum number of bins permitted in a single light curve is 500,000. When a light curve is selected with constant-duration bins, the total exposure time in each mode is divided by the binsize. If either mode exceeds half a million bins, the light curve will not be built. In such cases users can either select larger time bins, or create several light curves, each using less than the full set of observations, and then combine these manually to give the complete light curve.

Back to contents | Back to product generator

Product-specific information and results pages

When you submit a job you will initially be directed to a top-level summary page for your request, which lists the status of each of the requested products. Clicking on the product name, or thumbnail image if it exists, will take you to the detailed results page. Information about each of the products can be found on the following pages:

Back to contents | Back to product generator

Troubleshooting

Sometimes the requested data products cannot be built. The most common reasons for such failures are discussed below. If your problem cannot be diagnosed from this list, please contact the UKSSDC help desk. If possible, please include the URL of your results page in the email as this helps us to diagnose the issue.

My light curve/spectrum cannot be produced
In almost all cases, this occurs because the requested source cannot be detected in the XRT data. This may be because there are no PC-mode data (which the error message will tell you). In that case, you must set the “Try to centroid?” option to No.
If there are valid PC mode data available, the first thing to check is that the source lies within the search radius of the coordinates you have supplied. Constructing an image through this website provides an easy way to check this. If the source is present in the image but is not detected, try changing the “Centroiding method” in the Global options section to Iterative. If the source can still not be found, try setting the “Try to centroid?” option to No. Note that it is essential in such cases that the best possible position in the XRT coordinate frame is supplied. We strongly recommend that, when turning off centroiding, you first construct an image and measure the position as accurately as possible, and then supply this position to the web form.
My job has been listed as queued for ages.
All jobs are submitted to a batch queue and remain here until scheduled. Normally, jobs are executed almost immediately, but in rare occasions of high use, jobs may have to wait some time before they are scheduled. If your job has been queued for more than a few hours, please contact the UKSSDC help desk and we will check for a problem with the scheduler.
My spectrum was created, but it says it can't be fitted
All spectra are automatically fitted in xspec with an absorbed power-law model. If this is a bad description of the model, xspec may fail to fit the data. You can still download the spectrum to fit yourself.
My enhanced position could not be produced
Unfortunately, not all positions can be enhanced. To generate an enhanced position the X-ray data are split up into times coincident with individual UVOT exposures; the source must be detected in at least one of these for an enhanced position to be produced; in practical terms this means that the source needs to be brighter than about 0.01-0.02 ct/sec for the enhanced position to be produced.
My astrometric position could not be produced
In order to produce an astrometric position, there must be at least 3 X-ray sources detected in the image which correspond to catalogued 2MASS objects. If this condition is not met, no astrometric correction can be determined. If you only used a subset of the data to create the astrometric position, try using all available data instead. However, it may not be possible to produce an astrometric position of your object.
My astrometric position has a larger error than the standard position
The uncertainty in the astrometric position depends on how many X-ray sources could be matched with 2MASS objects, and therefore how accurately the astrometric correction could be derived. If there are only a few XRT-2MASS matches then the astrometric solution may well be of lower quality than that from the star trackers on Swift. In this case, the standard position should be used instead of the astrometric one.
Why is my position taken from the 1SXPS catalogue?
If you selected to build a standard or astrometric position, the source you requested is in the 1SXPS catalogue and the observation set you used exactly corresponds to those used to generate the 1SXPS position, then you will be given the 1SXPS position. This is because the software used to generate your position is identical to that used for the 1SXPS, so the result would be identical. We therefore do not waste the processing power reproducing a result that already exists.
Why is my job taking so long to run?
The runtime of a job depends on many factors, such as how many observations there are, how bright the source is and whether the object is piled up. The centroiding method can also have a heavy impact on the job's runtime: the iterative method is slow, especially if a large number of datasets are used. For all products except the images, you can click the “Show progress” link to display details of the progress, this will show you, for example, if it is the centroiding which is taking a long time. It is also possible to estimate from this the expected runtime of the job, but this should be done with caution: the progress is non-linear. For GRBs, for example, where the source is usually bright (and piled up) early on, but much fainter at late times, the majority of the runtime can be spent on the first observation.
Ultimately though, the reason that the products take longer to build than simply running the extractor tool a few times, is that our products are high-fidelity products, fully corrected for pile-up, bad pixels and columns and field of view effects. For the spectra, we derive count-weighted ARF and RMF files (with the off-axis angle calculated and weighted correctly), to ensure the most accurate spectral fits. These steps take time.
My job has been aborted, why?
The job scheduling system allows a maximum runtime of 24 hours (not including queue time). Jobs that run longer than this will be terminated. This is rare: we have tested the system on objects with more than 700 observations and these completed within about 10 hours; however in the event that your job overran, it may be necessary to split the data into several chunks and submit them as separate jobs. If you think that your dataset is not abnormally large, please contact the UKSSDC help desk.

Back to contents | Back to product generator

Change log

Back to contents | Back to product generator