Release dates of UVOTPY versions

version date
uvotpy- 2012-Oct-19
uvotpy- 2013-Mar-08
uvotpy- 2013-Mar-18
uvotpy- 2013-Mar-29
uvotpy- 2013-Apr-11
uvotpy- 2013-Apr-12
uvotpy- 2013-Apr-15
uvotpy- 2013-Apr-25
uvotpy- 2013-Apr-26
uvotpy-1.0.pre 2013-Jun-21
uvotpy-1.0.1 2013-Nov-19
uvotpy-2.0.0 2014-May-11
uvotpy-2.0.1 2014-Jun-02
uvotpy-2.0.2 2014-Oct-16
uvotpy-2.0.3 2014-Oct-21

Differences between UVOTPY versions that matter

Differences have been examined between 1.0.1 and 2.0.3, and are discussed below.

Sensitivity correction

The definition of the correction used in both versions is based on a sensitivity loss of 1% per year since 2005-01-01:

1/[1 - sens_rate*(swifttime - 126230400.0)/31556952.0],

so that at 2005-01-01 this equals 1.0, increasing with about 0.01 each year, being 1.053 in 2010-01-01 amd 1.111 in 2015-01-01. This is the factor that the count rate needs to be multiplied with.

In function ‘rate2flux’ both in 1.0.1 and 2.0.3 the rate is being multiplied with the sensitivity correction.

In function ‘writeSpectrum’ there are differences:

In 1.0.1 senscorr=1/sensitivityCorrection(TSTART)
flux *= senscorr
In 2.0.3 senscorr=sensitivityCorrection(TSTART)
sprate *= senscorr flux *= sprate

So the sensitivity correction for the flux is wrong in the output of version 1.0.1. The flux in the CALSPEC file extension will be lower by ~ 2% per year since 2005-01-01, but can be corrected by calling the sensitivity function and multiplying twice.

The same error causes the error bars on the flux to be too small in version 1.0.1.

The sensitivity correction error increases for data taken later in the mission, so can amount to ~22% difference by 2015.

Coincidence loss computation

In version 1.0.1 the coincidence loss was calculated using an ad-hoc formalism, based on the assumption that the coi-area had an identical number of pixels as for the point source case (315 sub-pixels), while there was a second-order contribution from nearby pixels in the background modeled by a polynomial correction to the rates. The spectrum was averages over about 26 pixels to smooth out MOD8 variability and account for the observed depletion range of strong sources.

This formulation was able to provide a correction for the coincidence loss that was valid for count rates per frame per coi-area up to about 0.7, which is about 63 counts per second. It was not possible to determine how close that was to saturation of the coincidence loss.

To calculate the rates used for the coincidence loss in version 1.x.x, the same rates were used as for the spectrum. Thus the size of the area used varied with the width of the spectrum. In version 2.0.x the count rates used for calculation of the coincidence loss correction were derived from a coi-area in the shape of a rectangular box of fixed dimensions.

In version 2.0.3 the coincidence loss has been based on observing a comprehensive range of ever brighter calibration source spectra, which allowed to determine the saturation level for the coincidence loss. We also could determine the correct coi-area, and a constant factor to multiply the rates with and then could use the same theory for coincidence loss as was used for point source and flat background already. Hence the ad-hoc assumption that a second order contribution from nearby background pixels was needed was shown to be unnecessary. The larger coi-area proved to do the job.

The better calibration of the coincidence loss that was made possible in version 2.x.x also led to our ability to determine the validity range for the coincidence loss, to be up to 3.5 counts per frame per coi-area, which translates to 318 counts/second/coi-area.

The accuracy of the coincidence loss is better in version 2.0.3, though for small count rates per coi-area, version 1.0.1 and version 2.0.3 are comparable in accuracy.

Other differences

There were some enhancements.

  • In version 2.0.3 a background image can be supplied and override the computed background.
  • The ‘offsetlimit’ option in ‘uvotgetspec.getSpec’ was provided more control.
  • The boresight positions of the zeroth orders used in calculating the anchor position with ‘uvotgraspcorr’ were updated.
  • The output file was reorganised. Version 2.x.x includes all corrections to the count rate in the ‘SPECTRUM’ extension.
  • The aperture correction was made more robust.
  • A new quality flag was added for count rates that are too bright.