skip to content
 
Swift Science Center Italian site Italian site U.K. site U.K. site

UVOT Digest

Things to know, or to look out for, when analyzing UVOT data.

Jump to:

  • UVOT Calibration Status (Updated July 23, 2007)
  • UVOT Science Analysis Issues (Updated March 13, 2008)


  • UVOT Calibration Status

  • UVOT Grisms: UV Grism, V Grism (Added December 7, 2006)
  • Photometric Calibration Issues (Updated July 23, 2007)
  • Zero Points (Updated July 23, 2007)
  • Distortion Map (Updated June 27, 2007)
  • Point Spread Function (Updated December 12, 2005)
  • UVOT Operational Constraints and Performance Issues


  • Photometric Calibration issues

    Updated July 18, 2008

    The 20070522 release of the Swift/UVOTA CALDB contains new photometric zero points for the UVOT. These zero points, and additional photometric calibrations, are described in detail in Poole, et al., 2008, MNRAS 383, 627). These new calibrations supersede all previous UVOT calibrations. The 20070522 CALDB contains revised:

    • photometric zero points
    • colour transformations
    • count-rate to flux density conversion factors
    • coincidence loss corrections
    • effective area curves for each filter
    • Galactic and zodiacal light data
    • quickmag data
    • point-spread functions

    The UVOT team strongly recommends that all users update to the most recent version of the CALDB. Details of the new calibration can be found on the Swift UVOT Calibration Documents page which is part of the Swift CALDB Web site.



    Zero Points

    Updated July 23, 2007

    The in-orbit photometric zero points are reported in the UVOT calibration document of 2007-05-22 are listed below. See the UVOT Calibration Documents Page, which is part of the Swift CALDB for detailed discussion of the photometric zero points. The current (as of 2007-05-22) photometric zero points for UVOT are

    
    Filter	Zero Point	Error	
    
    V	17.89		0.01
    B	19.11		0.02
    U	18.34		0.02
    UVW1	17.49		0.03
    UVM2	16.82		0.03
    UVW2	17.35		0.03
    White	20.29		0.04
    

    These zero point convert instrumental magnitudes measured in a circular aperture with a radius of 5 arcseconds into a UVOT system magnitude. To convert UVOT system ubv magnitudes to Johnson UBV magnitudes apply the color transformation equations described in the "Color Correction" document available at the Swift UVOT Calibration Documents page, which is part of the Swift CALDB Web site.



    Distortion Map

    The UVOT distortion between raw and detector coordinates in recorded in the "teldef" file in caldb. The current teldef file, based on the ground-measured distortion, is working well. For 583 stars in the calibration field referred to as "Sally's field" the median difference between the catalog position and the position measured on the sky image is 0.327" with only a modest deterioration as one moves from the image center.

    An interpolation scheme is used to convert from a grid of distortion offsets to any position on the detector. The current interpolation scheme is a "thin spline" approximation. This choice affects the photometry at the level of about 4 percent. The UVOT calibration team is currently studying alternative interpolation schemes to see if this can be improved upon.


    Left: 100-s UVOT V image. Right: Digitized Sky Survey of same region. compare uvot to DSS image

    At the start of the mission the plate scale for all the UVOT lenticular filters was assumed to be the same. In fact, the scale for UVW2 is significantly different than the rest. The result for this filter was larger position errors and more frequent failures of the automated aspect correction in the pipeline.

    On September 13, 2006, CALDB was changed to correct for this. There is now a separate teldef file per filter, each with its own plate scale.

    The first corrected CALDB version is u20060913. The CALDB version is stored in the data using the CALDBVER keyword, with a string that contains "_udate_" where date is an 8-digit value in yyyymmdd format.

    The first version of the processing pipeline to use this CALDB was 3.7. The keyword PROCVER, which appears in all Swift science files, records the version of the pipeline used in processing.



    Point Spread Function

    Calibration documentation describing the measured in-flight point spread function for the six UVOT broadband filters can be found in the Swift UVOT Calibration Documents page. Recent work suggests that the FWHM value in this document are underestimated. The best estimate of the FWHM (as of 2008 July 18) is approximates 2.5 arcsec for all filters. The curves of growth for the six filters that are found in that document are correct.

    The PSF is known to vary slightly possibly with orbital position and/or voltage. Further investigation is underway to fully characterize the variability of the PSF.



    UVOT Operational Constraints and Performance Issues

    Sun, Moon, Planet and Bright Star Constraints for UVOT

    Here we list the known bright objects that present a hazard for UVOT, and the angular distance limits at which constraints are imposed. We also list the angle which the Spacecraft avoids, and the angle used by the planning tool TAKO.

    Sun, Moon, Earth, Planets and the Brightest Stars

      44 deg for the Sun (Spacecraft avoids by 45, TAKO by 46)
      19 deg for the Moon (Spacecraft avoids by 21, TAKO by 23);
          may change to 14 deg (Spacecraft avoids by 16, TAKO by 18)
      92 deg for the Earth (Spacecraft avoids by 94, TAKO by 99)
          (subtract 66 to get avoidance from centre of disc)
      25' for Mercury, Venus, Mars, Jupiter, Saturn
          (no restrictions for Uranus, Neptune, and Pluto)
      25' for stars between -1.4 and 0.0 mag
    
    Other bright stars and field sources

    Stars in the field are checked in the onboard star catalogue for colour and brightness, from which a predicted theoretical count rate is calculated. If a star would produce 200,000 count/s or more, then the field is not observed. If the total predicted counts received for any star during this pointing (0-45 min) reaches 1,000,000,000, the exposure is terminated and the next filter tested.

    If the total count rate on the whole detector is greater than about 200,000 count/s, counts are lost in the electronics and a dark band appears in the image. At 200,000 count/s the following magnitude stars would be just observable (although coincidence loss would make measuring a reliable magnitude impossible):

      White filter  B1V 9.1 mag
      V filter      B1V 4.5 mag
      White filter  A1V 7.6 mag
      V filter      A1V 5.1 mag
      UVW2 filter   A1V 3.2 mag
      White filter  G2V 7.0 mag
      V filter      G2V 5.1 mag
      V filter      M2V 5.0 mag
      white filter  M2V 7.0 mag
    

    A star that is too bright to be observed on one filter may be observable in a different filter. The bright limit for observations is strongly dependent on the spectrum of the source, and the choice of filter. Users who are proposing UVOT observations are strongly encouraged to use the UVOT Bright Star Checker Tool to see if there are any bright objects in or near the UVOT field of view that may interfere with observing the field.

    To estimate if a particular source can be observed with UVOT please refer to the UVOT Point Source Simulation Tool. Users should use caution when attempting to observe a field that has a bright source within 20 arcmin since UVOT's onboard bright source algorithm is not identical to what is used in the simulation tool. This means that attempting to push UVOT observations to the edge of the bright source limit may not be successful.

    Safety Circuit Trip-Offs

    The UVOT detector has an autonomous onboard safety circuit that is designed to activate and turn off the detector when it senses an observation is dangerous. It is not unusual for the UVOT safety circuit to trip during GRB chasing operations. The safety circuit trips during verification were all due to slewing over bright (mag 2-4) blue (O and B type) stars except for:

    • 1 trip in a grism exposure with a slowly increasing background caused by the Earth approaching
    • 2 trips observing and preparing to observe the SMC which has many bright stars which appears too bright to the safety circuit because of overlap
    • 2 trips in the B filter for reasons yet to be determined.


    UVOT Science Analysis Issues


    General Issues (Updated December 12, 2005)

    An overview of the UVOT observing sequence can be seen in the sw*uir.html file in the /log directory of any observation. It is a good top-level description of the event and image files available in the uvot data directories. The UVOT exposure report lists the times of the exposures, which filter, mode, window, and binning were used, exposure time and overall count rate. Users can get a graphical version of the UVOT observing sequence, showing which filters where in place as a fuction of time, by running the FTOOL uvotsequence.

    The first UVOT image product available is a processed TDRSS message sent out via the GCN. We refer to this as the GeNI (GRB Neighborhood Image). Early GeNI images were binned onboard so that telemetered image pixel was 8x8 UVOT detector pixels. The current GeNI images are binned 2x2. The GeNI is 80 x 80 in image size. When the GRB afterglow is located within this sub-image, the product can be used to determine an accurate magnitude and position. If an XRT position for a GRB is not determined onboard Swift, the afterglow candidate may lie outside the GeNI image. It is then not possible to search for the afterglow in an image until the first Malindi pass data is processed by the SDC. A source list of stars found in the full-frame UVOT image is also sent trough TDRSS. Depending on how many sources are in the field, each star is sent down as either 1 pixel, a 3x3 or a 5x5 postage stamp. These source lists can also be searched for the afterglow but since they are not full images it is possible to sometimes get false positives and users should use caution in interpretting sources in this product.



    Aperture Corrections

    In order to apply the UVOT photometry calibrations the source count rate must be extracted in an aperture that matches the aperture used to calibrate the photometry. As of 2007-05-22 this is a circular aperture with a radius of 5 arcseconds. There are various situations where this aperture may not be appropriate. Small apertures make it easier to exclude contamination from nearby sources, an aperture with a radius that matches the full-width at half-maximum (FWHM) of the point-spread function (PSF) is optimal for detecting sources, and a small aperture results in a higher signal-to-noise (and thus a lower statistal error in the derived magnitude) for a source. If a smaller source aperture is used then an aperture correction must be applied to the count rates in order to correct for the missing counts. This process is discussed in detail in the UVOT Aperture Correction analysis thread. Users interested in the general details of aperture correction should consult Howell (1989, PASP, 101, 616) and Stetson (1990, PASP, 102, 932).

    Rigourous aperture corrections require a good deal of effort to compute. They depend on the shape of the PSF, and thus can vary with filter and count rate. In addition the FWHM of the UVOT PSF is dependent on the temperature of the UVOT focusing rods. Their temperature varies slightly with time because the voltage on the heaters changes through the spacecraft orbit. This can cause variations in the shape of the PSF. Currently this variation has not been well-characterized. As a result aperture corrections ideally need to be computed for each UVOT exposure as discussed in the UVOT Aperture Correction analysis thread. However this is time consuming, and not easy to automate. Because of this the UVOT analysis software implements an automated method of computing approximate aperture corrections.

    uvotapercorr

    The Swift software includes a task called uvotapercorr that takes a count rate, an aperture radius, and a file describing the PSF, and returns an estimated aperture correction. This correction is computed by comparing the volume under the PSF out to the standard photometry aperture radius to the volume under the PSF out to the user-specified aperture radius. The user must provide the appropriate PSF file, but mean PSFs for each UVOT filter are included in the Swift/UVOT CalDB distribution. Please see the fhelp file for uvotapercorr for details on using uvotapercorr. Details of this method of aperture correction are given in Poole et al. (2008, MNRAS, 383,627).

    The aperture corrections computed by uvotapercorr are approximate at the level of a few percent. The aperture corrections for several apertures are given in the following table. These numbers are intended for making approximate aperture corrections in cases where high-precision photometry is not necessary. Users who wish to do high-precision photometry need to consult the UVOT Aperture Correction analysis thread.

    Aperture (arcsec) 2.0 2.5 3.0 3.5 4.0 4.5
    v -0.276 -0.145 -0.091 -0.054 -0.032 -0.014
    b -0.327 -0.176 -0.111 -0.065 -0.037 -0.014
    u -0.329 -0.169 -0.103 -0.059 -0.034 -0.014
    uvw1 -0.405 -0.212 -0.126 -0.069 -0.037 -0.015
    uvm2 -0.342 -0.182 -0.109 -0.060 -0.033 -0.014
    uvw2 -0.417 -0.222 -0.133 -0.073 -0.039 -0.016
    white -0.327 -0.176 -0.111 -0.065 -0.037 -0.015

    Uvotapercorr characterizes the systematic uncertainty that is introduced into the aperture-corrected count rate by variations in the PSF in this way. The user provides an argument, "fwhmsig", which estimates the fractional rms variation of the FWHM of point sources, expressed as a percentage. The appropriate value for "fwhmsig" is under investigation. Preliminary recommendations are given in the fhelp file for uvotapercorr. Users may wish to set "fwhmsig" to zero and add their own estimate of the uncertainty in the shape of the PSF to the uncertainty in the aperture-corrected count rate. Users should be aware that the shape of the PSF may vary with time and filter, so using a single value "fwhmsig" may not be appropriate for all exposures.

    The aperture corrections computed by uvotapercorr are only valid for point sources and this algorithm can not be used to correct magnitudes derived in an aperture with a radius larger than 5 arcseconds.

    uvotsource

    Uvotsource is the standard software tool for doing photometry on a single source in a UVOT SKY image. This software has an option to use the uvotapercorr algorithm to do approximate aperture corrections. Please see the fhelp for uvotsource for details on doing this. One thing to be aware of is that the version of uvotsource released with HEADAS 6.4 does not allow the user to specify the systematic uncertainty in the width of the PSF (i.e., the "fwhmsig" parameter from uvotapercorr). This value is fixed at 5% since this was believed to be a reasonable number when the software was released. Future versions of uvotsource will allow the user to specify this number.

    uvotmaghist

    Uvotmaghist is a tool that calls uvotsource for every image extension in a FITS file. It performs aperture correction in exactly the same way that uvotsource does.

    uvotdetect

    Uvotdetect calls SExtractor to perform source detection and extract counts for each source. SExtractor's ISOCOR method to determine the counts for each source. This method does not require aperture correction.

    uvotevtlc

    Uvotevtlc currently (as of heasoft 6.5) does not perform aperture corrections.

    uvot2pha

    Uvot2pha currently (as of heasoft 6.5) does not perform aperture corrections.



    Understanding UVOT Exposure Time Keywords (Added November 13, 2006)

    UVOT science data files include a number of special keywords that are used to calculate the total exposure time. These keywords contain information about the CCD read-out time, as well as the amount of data lost due to several possible effects. The keywords, and their role in determining the total exposure time, are described below.

    
    This is how TIME keywords for UVOT raw images are defined
    as of the UVIT2FITS telemetry conversion software version V3.15+.
    
    
    TSTART = The actual start time (from the exposure report packet in the telemetry)
    
    TSTOP = The actual end time (from the exposure report packet in the telemetry)
    
    TELAPSE = TSTOP - TSTART
    
    FRAMTIME = The calculated frame exposure interval which is a function of the
               UVOT detector hardware window size. This is usually the full 2048
               by 2048 but can be smaller for exposures in the White filter, to
               reduce telemetry volume.
    
    BLOCLOSS = The time lost if the exposure began with the BLOCKED filter in place
               but was later commanded to a different filter during the exposure.
               Effectively a dead time. Could be in error by 0-10+ sec
               due to the timescale on which filter position is available in the
               housekeeping data. This keyword is present only if the value is nonzero,
               and should only rarely be present. It is nonzero for some grism observations
               of RS Oph.
    
    TOSSLOSS = Time lost when the onboard shift-and-add algorithm, which corrects image
               positions for satellite drift, tosses event data completely off the
               image. Effectively a dead time. Loss of Aspect Following packets
               in the housekeeping stream can cause this estimated value to be incorrect.
    
    
    STALLOSS = Time lost when the DPU stalls because the count rate is too high.
               Estimated from ((TELAPSE/FRAMTIME) - "EXP Report total frames")
               times FRAMTIME. Set to zero if less than 1 sec.
    
    ONTIME = TELAPSE
           - TOSSLOSS
           - STALLOSS
           - BLOCLOSS (As of UVOT2FITS V3.16)
    
    BLOCLOSS was accounted for in the DEADC value for UVOT2FITS v3.15. 
             It was removed from the DEADC calculation and treated like 
             all other time losses as of UVOT2FITS V3.16.
    
    LIVETIME = (ONTIME  * Calculated dead fraction) - BLOCLOSS for UVOT2FITS v3.15.
    LIVETIME = ONTIME * Calculated dead fraction as of UVOT2FITS V3.16.
    
    EXPOSURE = LIVETIME
    
    DEADC = EXPOSURE / ONTIME
    
    EXP_UNC = The uncertainty in the EXPOSURE keyword value. This attempts
              to account for uncertainty sources from the telemetry.
              The major source of uncertainty in the EXPOSURE keyword comes
              from lost telemetry during shift-and-add. When onboard shift-and-add
              is turned on and telemetry loss is indicated, EXP_UNC is
              1.0 - ("Found Shift&Add Intervals" / EXPOSURE).
    
    CNTEXP =(GIMAGE/NEVENTS)*NFRAMES*CalcFrame*CalcDEAD as of UVOT2FITS V3.16 when
        the image is 2048x2048. Parameters are defined by->
        In sw*uct.hk, take the columns NEVENTS, NFRAMES, GIMAGE. Get values of
        CalcFrame, and CalcDEAD for the standard window.
    
        NEVENTS = Number of events handled by DPU during exposure.
    
        NFRAMES = Number of exposure frames handled by DPU during exposure.
                  This figure automatically accounts for STALLLOSS since stalled
                  frames are not counted in this number (we hope).
    
        GIMAGE = Number of events found in the image on the ground.
                 This may be in error if there were lost rows in the telemetry.
                 This number SHOULD be identical to NEVENTS in 2048x2048 images
                 but often is smaller by fractions of a percent. The reason for
                 this is unknown and helps make CNTEXP a fuzzy value. One possible
                 source is fractions of images shifted off by S&T.
    
        CalcFrame = The time for 1 exposure frame based on the hardware window.
    
        CalcDEAD = The 1 frame DEADC fraction which actually is 1.0 - dead fraction
                   and thus is the live fraction (I didn't make this up, it is a
                   standard). This value can only be applied to actual exposed to
                   sky time. For example, TELAPSE*DEADC is meaningless unless TELAPSE
                   = ONTIME.
    


    UVOT Coincidence Loss Corrections

    The following table combines the coincidence loss relation with the quickmag calibration (for an A0V star) to give the co- I correction (in magnitudes) as a function of magnitude. It assumes the standard UVOT hardware read-out window and zero background.

    For example, from the table the white filter saturates at 15th mag, requires a large (0.62 mag) correction at 16th mag, and the co-I correction doesn't become negligible until 20th magnitude.

    A non-zero background (usually higher for the optical filters) will increase the size of the co-I correction.

    Mag U B V W1 M2 W2 White
    13 Sat Sat Sat 0.64 0.34 0.57 Sat
    14 0.51 Sat 0.30 0.18 0.11 0.17 Sat
    15 0.16 0.36 0.10 0.07 0.04 0.06 Sat
    16 0.06 0.12 0.04 0.03 0.02 0.02 0.62
    17 0.02 0.04 0.02 0.01 0.01 0.01 0.18
    18 0.01 0.02 0.01 0.00 0.00 0.00 0.07
    19 0.00 0.01 0.00 0.00 0.00 0.00 0.03
    20 0.00 0.01 0.00 0.00 0.00 0.00 0.01

    More information on the UVOT coincidence loss expression can be found in The Count Rate to Flux Ratio UVOT CALDB document (PDF).

    Incorrect Exposure Times in some Aspect-Corrected Images

    (Fixed in current pipeline as of December 1, 2005)

    The exposure time keywords were incorrect for about 2% of the UVOT image data taken in 2005 March through 2005 September. Some earlier exposures are also likely to have problems. In some (but not all) of the cases the problem is caused by an error in the shift-and-add software in the instrument. This text file provides a list of these exposures and the correction factor needed for the exposure length. This problem is corrected in the current version (December 2005) of the Swift pipeline processing software. Exposure time keywords for the affected images will be fixed once the data is reprocessed with the current pipeline software.

    For data processed with earlier versions of the pipeline, the reported exposures lengths may be incorrect. The problem can be corrected by following the recipe below.

    1. check for problems by comparing the start times (in mission elapsed seconds) in your data file with the start times in the list of affected images.
    2. make note of the ratio of measured/expected counts for any of your exposures that are in the list
    3. correct the exposure time keyword in only the extensions in question to reflect the equivalent livetime of the UVOT detector for the exposure in question. This can be done with the tools fv or fmodhead.

    Example:

    Let's fix the fourth extension in

    sw00131560001uvv_sk.img
    whose measured to expected count ratio is shown in the list of affected images as 0.0732:
    #  MET         File Name             Exposure   Expected    Actual  Ratio
    #                                                 Counts    Counts
    
    139512177 sw00131560001uvv_rw.img vv139512177I  36006149   2635110 0.0732


    The original EXPOSURE keyword in the image is 1500 seconds:
    EXPOSURE=     1500.44392000555 / Total exposure, with all known correction
    

    Create an ASCII file called newtime with the original exposure time corrected for the ratio of true counts in the image to expected counts:

    EXPOSURE=     109.832 / Total exposure, corrected for aspect error
    
    Run the tool fmodhead to insert the new value into the file in the appropriate extension:
    fmodhead sw00131560001uvv_sk.img+4 newtime
    

    Once the exposure time has been corrected in this way, standard tools that calculate magnitude based on measured counts over the elapsed exposure time (such as uvotmag) will return the correct answer.



    Wrong keywords in the UVOT GeNI Image (TDRSS product only)

    Occasionally, the UVOT Data Processing Unit (DPU) writes the wrong RA and DEC on the telemetry packets of the first UVOT image received on the ground, the so-called "GeNI" image. Users should check the GeNI RA, DEC keywords for consistency with the BAT and XRT position. If an XRT position is available, substitute these keywords into the GeNI FITS file before attempting to do any position refinement with the GeNI image.



    Tails in 100-s Finding Chart Exposure

    These occur because the satellite is still settling when the finding chart exposure begins. The tails can be removed by screening out early data from the event list. Alternatively, an elliptical region file can be created so all photons from the early afterglow can be used in determining early magnitudes. The finding chart image is taken in Image/Event mode, where the event window is typically the full 2048x2048 while the Image window is 960x960 pixels. For data taken after the final drift correction upload, the image data from the finding chart exposure does not generally show tails.

    For event data, detector positions are converted to sky positions based on the spacecraft attitude information. During a slew and just after settling, the source of attitude information switches from the gyroscopes to the locked star-trackers. This can introduce a slight jump in the resulting image such that there is a nearby ghost image for each real point source. The best way to look for this effect and decide how to proceed is for users to plot the spacecraft RA and Dec values during the time span of the finding chart exposure. If a jump in position information is observed, tools such as ximage can be used to extract two separate images from the event data: one from before the star trackers locked on, and the other from after.



    Tails in Image Mode Data

    Data taken in "Image" mode prior to March 29 had an erroneous drift correction applied in one or both detector directions. The result: in images where a significant drift is present, stars appear comet-like as opposed to point-sources. The error was corrected via a UVOT flight software code upload on March 29, 2005. Image data taken prior to this date may have comet-like artifacts around the stars if drift was present during the exposure.



    Residual Pointing Uncertainty of 5 arcsec and Combined Images

    (Fixed in current pipeline December 2005)

    The attitude information reported by the spacecraft (instantaneous RA, Dec and Roll) can be incorrect by up to 5 arcseconds. Earlier versions of the pipeline did not perform a fine aspect correction to remove this uncertainty. This means that when images from multiple pointings were combined, the sources do not fall exactly on top of each other in the combined image. The current Swift processing pipeline performs automatic UVOT aspect correction. However data from earlier versions of the pipeline will still show the effects of the pointing uncertainty. Until the data has been reprocessed, users can do their own aspect correction with tools provided as part of the Swift software package in Ximage. See our UVOT Aspect Correction Analysis Thread for a recipe on using Swift software to apply aspect correction to UVOT data.

    Automatic aspect correction was added to the UVOT processing pipeline in the SDC in December 2005.




    If you have a question about Swift, please contact us via the Feedback form.

    This page was last modified on Wednesday, 30-Jul-2008 17:18:37 EDT.

    Science Mission Directorate Universe Division
    Beyond Einstein | Origins

  • Questions/Comments/Feedback
  • Find helper applications like Adobe Acrobat
  • Learn about black holes, astronomy & more!
  • A service of the Astrophysics Science Division at NASA/ GSFC

    Swift PI: Neil Gehrels,
    Responsible NASA Official: Phil Newman
    Web Curator: J.D. Myers
    PAO Contact: Francis Reddy (301-286-4453)
    Privacy Policy and Important Notices.