Swift

Swift extractions

Swift extraction scripts are written in perl. The help for each function can be called with functionname --help

XRT

Use wrapper script by L. Barragan and J. Wilms, can be found at $SWIFTTOOLS/xrtprepare and $SWIFTTOOLS/xrtextract.

It is possible to use a second wrapper which extracts multiple observations at once. Example: /userdata/data/krauss/tanami/xrt/allprep and allex This wrapper also automatically sets a source region and background region for extraction. Radius can be checked and adjusted and the script rerun.

UVOT

Use wrapper scripts by F. Krauss at $SWIFTTOOLS/uvotimage and $SWIFTTOOLS/uvotpha. It is possible to use a second wrapper which extracts multiple observations at once. Example: /userdata/data/krauss/tanami/uvot/allsum and allpha

Useful tips

simbad2ds9: If you want to check for other possible source in the FoV use the simbad2ds9 tool, e.g. "simbad2ds9 --name="Vela X-1" ": This will create a ds9 region file with all sources in the vicinity of the specified source. This can be helpful to avoid possible source confusion.

Known Swift problems

For e-mails concerning missing Swift observations in the Remeis archive: Only a plain text file or list of observation IDs in the email is sufficient to start the download. It is not necessary to include source name, observation dates or any other information.

When using xrtprepare execute the function in the same directory as the one chosen as prepid, otherwise the preparation might exit with an error.

XRT problems and what to do

Bug concerning observation target: "Source J0619-1140 not found in SIMBAD either.. please enter target coordinates manually via the tarra and tardec options" [It's a feature not a bug!] Swift observations always have a target, those are the coordinates the telescope was pointed at. These are not necessarily those of the source you're interested in. The Swift scripts check the target name and search for its coordinates in SIMBAD. The reason for this is a bug in the data generation pipeline that was only recently fixed and still affects observations. For some cryptic target names that are not found by SIMBAD the name or coordinates of the TARGET have to be given manually via --tarobj, OR via --tarra and --tardec If you are confident or if you have checked the target header coordinates you can disable this feature with --noco
Bug occurring in the XRT pipeline: Occassionally a bug with a cryptic error message appears:

pc: .... Stage I: Calibrating Level 1 Event File: /userdata/data/krauss/tanami/xrt/neutrinos100tev/ev39/CRATESJ061733.67-171522.8/00039134001/reprocessed/sw00039134001xpcw3po_uf.evt pc: .... Stage I: ERROR ============================================================================================= xrtpipeline_0.13.2: ERROR: Pipeline exit with errors - Tue Jul 19 14:52:04 CEST 2016 ============================================================================================= =============================================================================================

and before:

FITSIO status = 104: could not open the named file failed to find or open the following file: (ffopen) /userdata/data/krauss/tanami/xrt/neutrinos100tev/ev39/CRATESJ061733.67-171522.8/00039134001/reprocessed/sw00039134001xpcw3po_uf att_fatal: code=104 CFITSIO ERROR FILE_NOT_OPENED: could not open the named file Task coordinator 0.1 terminating with status 104 xrtpipeline_0.13.2: Error: running 'coordinator'

This error occurs when the full path of the file is too long (>48 characters). Choose a shorter path and rerun. If the long pathname is necessary, copy the final extraction into your subsubsubfolder or folderwithreallylongname.

"Target Object found: PHOTON" and "no products foreseen for 'SLEW' data":WARNING! This type of observation yields no errors! Check reprocessed folder, if it doesn't contain any file ending in "*po_uf*" only e.g. "*sl_uf" and "*st_uf*" this means that the satellite was only slewing during the observation. Skip this observation, it is not usable.

UVOT problems and what to do

"Checking ASPCORR ... ASPCORR set to NONE...performing correcting coordinates ..." If aspect correction has not been applied the system will launch "uvotskycorr" which attempts to do the aspect correction by comparing the FoV with known stars. This can fail. If does so with: "aspcorr: not applying correction to any HDUs" and "uvotskycorr: no correction for m2471780312I" No known fix at the moment. If coordinates look ok perform a manual extraction via the Swift Tools uvotimsum and uvot2pha