• HEASARC
• Swift Home
• Archive
• Data Analysis
• Proposals & Tools
• Education & Public Outreach

• About Swift
• Quicklook Data
• GCN
• Results
• Operations
• Related Sites
• Gallery

BAT Digest: Old Issues

Old issues regarding the analysis of BAT data, that have been resolved by new software releases.

BAT Old Science Analysis Issues

1. battblocks: duration uncertainties are unreliable (Fixed HEASoft 6.4)

2. CALDB: BAT imaging tools need new teldef files (Fixed CALDB 20070924)

3. Various BAT scripts fail to use Remote CALDB (Fixed HEASoft 6.3.2)

4. batgrbproduct: Fails to analyze short bursts (Fixed HEASoft 6.4)

5. batoccultgti: Fails when checking the field of view only (Fixed HEASoft 6.4)

6. batbinevt: ignores standard 4-channel energy bins (Fixed CALDB 30 Jul 2007)

7. batbinevt: DPH rows with fractional exposure are not accounted for properly (Fixed HEASoft 6.3)

8. batcelldetect: newly detected sources may be deleted (Fixed HEASoft 6.3)

9. batcelldetect: the correct point spread function is gaussian (Fixed HEASoft 6.3)

10. Analysis: Users must apply systematic error vector for spectral fitting (Corrective Procedure)

11. batmaskwtevt: Slewing Raytracing Keywords Potentially Incorrect (Corrective Procedure)

12. Analysis: filtering out non-gamma-ray events may improve sensitivity (Fixed HEASoft 6.1.2)

13. SDC: BAT data from SDC pipeline has incorrect DATE-OBS/END keywords (Workaround)

14. batoccultmap: incorrect exposure correction (Closed HEASoft 6.1)

15. batbinevt: light curves have slightly incorrect energy bins (Closed HEADAS 6.0.5)

16. Mask tagged light curve systematic flux errors (Closed HEASoft 6.0.3)

17. XSPEC crashes with segmentation fault with BAT spectra (Closed Swift 2.1)

18. baterebin: Possible extra rows in EBOUNDS extension of output DPH (Closed Swift 2.1)

19. batbinevt: Incorrect exposure for survey analysis (Closed Swift 2.1)

20. CALDB: Incorrect Spectral Response less than 20 keV (Closed Swift 2.0)

21. CALDB: Incorrect Alignment Matrix (Closed Swift 1.1)

22. batcelldetect: Incorrect Error Bars (Closed Swift 1.2)

23. batbinevt: Incorrect EXPOSURE Keyword (Closed Swift 1.2)

24. batbinevt: Incorrect Handling of float point DPHs (Closed Swift 1.2)

25. batmasktaglc: light curve error bars too small (Closed Swift 1.2)

26. batmaskwtevt/batmaskwtimg: High-Energy Background Contamination (Closed Swift 1.2)

battblocks: duration uncertainties are unreliable

NOTE: this problem has been fixed in HEASoft version 6.4 (released December 2007).

Users can estimate gamma-ray burst durations such as "T50" and "T90" using the software task 'battblocks'. The T50 and T90 values are stored in the output file in the keywords T50DUR and T90DUR.

The task also provides estimates of the uncertainties in T50 and T90. However, the BAT team currently believes that these estimated uncertainties are too small, and cannot be relied upon.

Throughout the mission, the BAT team has estimated the uncertainties by visual inspection.

CALDB: BAT imaging tools need new teldef files

BAT imaging tools use a "TELDEF" file to describe the misalignment between the spacecraft and instrument coordinate systems. In the process of recovering from the safe-hold episode of Aug 2007, the Swift spacecraft coordinate system was redefined. The nature of the change was primarily in spacecraft "roll" angle, and the magnitude of the change was about 10 arcminutes.

As a result of this spacecraft-level redefinition, BAT data taken after August 28, 2007, will show systematic image shifts, especially in the outer parts of the field of view where the effect of a "roll" is greatest. (The shift should be approximately (10.6 arcmin)xsin(theta), where theta is the off-axis angle.)

New versions of the BAT TELDEF files are available which correct for the shift. They are available from the Swift CALDB area (BAT version 20070924 or later). Users of CALDB do not need to make any changes to their software or scripts, since the TELDEF files are indexed by observation time.

SPECIAL NOTE: The tool 'batmaskwtimg' may produce the wrong raytraced image after these CALDB changes. By default, this task does not require an input file (although the optional 'infile' parameter can be used). When no input is given, batmaskwtimg assumes the observation time is today. While this was not a problem up to August 2007, since the teldef file had not changed up to that point, it will obviously fail for old observations processed with new teldef files today. This failure is silent. The workaround is to supply an input file. The next release of batmaskwtimg will make 'infile' a required parameter. Since the batmaskwtimg task has never been required for GRB analysis, it is likely that this interface change would have a low impact, and obviously would help the results to be more correct.

Various BAT scripts fail to use Remote CALDB

NOTE: these bugs were fixed in HEASoft version 6.3.2. Remote CALDB should work as usual. Users who download CALDB locally should be unaffected.

The BAT scripts batdetmask, batglobalgti, batphasimerr, and batphasyserr were designed to access CALDB. However, because of a bug in the scripts prevents them from working with Remote CALDB (Remote CALDB allows users to access the database over the network rather than downloading the files to their local computer.)

batgrbproduct: Fails to analyze short bursts

NOTE: this problem was fixed in HEASoft version 6.4. The 'shortfix' parameter, which defaults to 'YES', causes batgrbproduct to accomodate problems with short triggers.

For short burst triggers (triggers shorter than or equal to 64 milliseconds), the BAT flight software reports the incorrect burst trigger time in the BAT TDRSS position message (the keyword containing the trigger start time is named TRIGTIME). The value in the telemetry is the start of a 320 millisecond interval which contains the end of the trigger interval. Thus, in principle, the end of a short burst trigger could have fallen anywhere within a 320 millisecond interval starting at TRIGTIME.

For short bursts this behavior can cause problems. First of all, the automatic burst-finding algorithm in battblocks cannot always find short, faint bursts, which causes the algorithm to fall back to the time intervals reported in the position message. Since these time intervals are incorrect, the result can appear to be a non-detection.

The workaround to this problem is to to examine the light curve and manually adjust the trigger start and stop time to cover the true interval of the burst (using the trigtime and trigstop parameters to this task). A future version of batgrbproduct will be more intelligent about picking the correct time interval.

batoccultgti: Fails when checking the field of view only

NOTE: This bug was fixed in HEASoft version 6.4. Supplying an explicit partial coding threshold is now advised, but not required.

The task batoccultgti can be used to select times when a particular source is both unocculted by the earth, and in the field of view. There are several field of view selection criteria, including both partial coding and instrument coordinates such as IMX, IMY, and theta.

However, if the user selects only instrument coordinate constraints, then batoccultgti will report the following error:

  ERROR: could not create '' at /path/name/...
  Task batoccultgti 2.3 terminating with status -1

This is a logic error within the batoccultgti script.

The workaround is to supply a minimal partial coding constraint. For example, use the command line parameter, "pcodethresh=0.011".

batbinevt: ignores standard 4-channel energy bins

NOTE: This issue was resolved with the Swift CALDB release on 30 Jul 2007. Users are advised to download this new CALDB release.

The BAT team maintains "standard" energy bins in the Calibration Database (CALDB). There are two sets: a 4-channel set, usually for light curves, and an 80-channel set, usually for spectra. These two sets of energy bins are selected on the command line with energybins=CALDB:4 or CALDB:80.

An error in a recent CALDB submission has caused this feature to stop working. The problem is an unrelated file that also has an EBOUNDS extension, which confuses the batbinevt CALDB access routines. The result is that if the user requests CALDB:4, i.e. standard 4-channel binning, batbinevt produces 80 energy bins instead.

While the problem appears to be a problem in the software, the true problem is in the CALDB. A revised CALDB version (dated 30 Jul 2007) is available from HEASARC.

There are two workarounds if it is not possible to use the 30 Jul 2007 CALDB release:

1. Revert to a previous version of CALDB;

2. Specify the four-channel bins explicitly (the bins in keV are "energybins=15-25,25-50,50-100,100-350").

batbinevt: DPH rows with fractional exposure are not accounted for properly

NOTE: this bug was fixed in HEASoft version 6.3.

batbinevt can be used to "sum" many different detector plane histograms (DPHs) and produce a single output DPH. However, this DPH cannot normally be re-input to batbinevt, because the task makes a fundamental assumption that individual input DPHs are contiguous in time.

For example, consider a file with two DPH entries from two disjoint times.

csh> ftlist file.dph T columns=TIME,EXPOSURE

                       TIME                EXPOSURE
                          s                       s
  1        145293915.000000        360.000000000000
  2        145294995.000000        244.000000000000

This file has two exposures separated by about 700 seconds. It is possible to use batbinevt to combine these entries into a single DPH, like this,

csh> batbinevt file.dph summed.dph DPH 0 uniform INFILE chatter=5 clobber=YES
csh> ftlist summed.dph T columns=TIME,TIME_STOP,EXPOSURE
                       TIME               TIME_STOP                EXPOSURE
                          s                       s                       s
  1        125293915.000000        125295239.000000        604.000000000000

The "0 uniform" portion of the command line causes batbinevt to sum all input DPHs into a single output DPH. The new file, summed.dph, has the correct start and stop time, and the exposure is correct as well. A check of the good time interval (GTI) extension shows that it is also correct.

Everything looks fine. However, this file cannot be re-input to batbinevt, because batbinevt makes a fundamental assumption that DPHs are always contiguous in time.

csh> batbinevt summed.dph summed.dpi DPI 0 u 14-194.9 chatter=5 clobber=YES
csh> ftlist summed.dpi K | grep EXPOSURE
EXPOSURE=                1324. / [s] Accumulated on-time

The exposure has now increased incorrectly to 1324 from 604 seconds.

The work-around procedure is to not sum the input DPHs into a single output DPH. Instead, use the INFILE time binning option to merge but not sum the inputs. The result will be a single file with multiple DPHs which can be operated on normally.

csh> batbinevt file.dph merged.dph DPH 0 INFILE INFILE chatter=5 clobber=YES

While this example is rather meaningless for a single input file, it will permit multiple input files to be merged. The merged file can be input to batbinevt if desired.

batcelldetect: newly detected sources may be deleted

NOTE: This bug was fixed in HEASoft 6.3 (task version 1.56 and greater).

A bug in the CFITSIO library may cause newly detected sources to "disappear" from the output catalog. The problem occurs with the operation of the "keepbadsources" parameter, which was added in version 1.50, and was meant to remove from the output catalog sources with bad DETECT_STATUS values. However, new sources were also removed by the CFITSIO library routine when they shouldn't have been.

The workaround is to set "keepbadsources=YES" and filter the output catalog manually based on DETECT_STATUS.

batcelldetect: the correct point spread function is gaussian

NOTE: This problem was fixed in HEASoft 6.3 (task version 1.60 and greater).

Fluxes derived from batcelldetect are based on a fit of a point spread function (PSF) to the sky image intensities. In particular, the reported flux is the intensity at the center of the PSF. As one might expect, the flux depends on fitting the correct PSF model to the data.

Based on a number of incorrect assumptions, the BAT team reported that the PSF was a truncated pyramidal frustum. However, this is incorrect. In fact, the PSF is very nearly a gaussian function (with full-width half-maximum of 22 arcmin). This PSF can be selected by using the psfshape=GAUSSIAN option to batcelldetect (the default is psfshape=PYRAMID).

Using the incorrect frustum function will result in fluxes that are too high by 4.0% compared to the true flux. The signal to noise ratios are high by about 3.5%. For the most part, this effect is only significant for the brightest sources, where the statistical errors are smaller than 4%.

Note that this problem applies only to fluxes from batcelldetect. It doesn't affect mask-weighted light curves and spectra made from batbinevt.

Analysis: Users must apply systematic error vector for spectral fitting

NOTE: This corrective procedure is now fully documented in the BAT manual. Users must continue to apply the systematic error vector as documented.

The BAT detector response matrix has been significantly improved in the HEASoft 6.0.3 release. However, significant systematic residuals remain. Users should consult the BAT Calibration Status section for more discussion of this. To account for the residuals, the BAT team has prepared a systematic error vector which should be attached to all spectra before analysis in XSPEC.

The BAT team has released a task called batphasyserr which can apply the systematic error vector to BAT spectra. It works for both type I and type II spectral files, and works for any type of energy binning.

Most commonly, the task will be invoked in the following way:

batphasyserr spectrum.pha CALDB

where spectrum.pha is the spectrum to be modified (it is modified in place). After using this task, spectrum.pha should have a new column, SYS_ERR, which XSPEC uses during spectral fitting.

Normally, users should use the BAT-team estimated systematic error vector provided with calibration database (CALDB). The most up to date version of this file can be found by querying the CALDB with this command:

quzcif Swift BAT - - SYS_ERR yyyy-mm-dd 00:00:00 -

Where yyyy-mm-dd is the date of the observation (now can also be used). As of this writing, the systematic error vector is named swbsyserr20030101v002.fits.

NOTE: Because the systematic errors are significant, it is likely that for bright sources the reduced chi-squared value will be less than 1.0. When this occurs, at least a portion of the spectrum is systematics-dominated instead of statistics-dominated. The formal parameter errors of the XSPEC fit will be appropriately larger than the corresponding statistical errors.

Updated (15 Oct 2005) - to discuss the new batphasyserr task

batmaskwtevt: Slewing Raytracing Keywords Potentially Incorrect

NOTE: This corrective procedure is now fully documented in the BAT manual. Users must continue to apply the 'batupdatephakw' task to BAT spectra as documented.

Discussion: During slews, the source of interest (such as a GRB) moves in the BAT field of view. Users can still make light curves and spectra from moving sources by using the batmaskwtevt task. This task computes a ray-trace for each event, and dynamically updates the ray-trace as the spacecraft slews.

The response matrix generator, which is downstream from the event processing, relies on several keywords to construct a proper response matrix. These special keywords are written by batmaskwtevt. However, batmaskwtevt can only write a single set of keywords to cover the whole slew. It uses the final values, corresponding to the end of the slew. This is usually the wrong thing to do, since GRB transients are typically before the slew, not after.

Nominally, light curves and spectra are corrected crudely for off-axis effects by the mask weighting procedure (and the default correction settings). HOWEVER, this is not the whole story. The shape of the response is also a function of angle, and this shape change will alter the spectrum in subtle ways. As a source with the same intrinsic spectrum moves farther off-axis, the measured spectral index will appear to become flatter and flatter, unless the ray-tracing keywords are properly set. This also changes the measured flux as well, of course.

The solution is that users must rewrite the keywords for the time of interest. The software task batupdatephakw, released in Swift 2.0, makes it more easy to do this.

The steps to use this task are:

1. Users should run batmaskwtevt with the auxfile= parameter. This produces an auxiliary file that contains the raytracing values as columns, and as a function of time.

2. For each spectral file spectrum.pha, run this command:

batupdatephakw spectrum.pha raytrace.aux

where raytrace.aux is the auxiliary file created in step 1. The script will determine the center time of each spectrum in the input file, and transfer the raytracing values for the nearest time from the auxiliary file to the spectrum. The spectrum is modified in place.

The required column/keywords are: BAT_XOBJ, BAT_YOBJ, BAT_ZOBJ, PCODEFR, NGOODPIX, and MSKWTSQF.

Analysis: filtering out non-gamma-ray events may improve sensitivity

BAT count rates are typically background dominated. Any reduction in the background can improve the sensitivity to a source signal.

BAT event data includes many kinds of events, not just gamma-ray events. Of course many events are due to cosmic diffuse and particle backgrounds, but they cannot be easily identified as such on an event-by-event basis. On the other hand, there are other events which are known to be non-gamma-ray events based on their electronic signature. These events are flagged by the electronics and the flight software. In previous versions of the ground software, all events, including the flagged non-gamma-ray events, were assigned weights by batmaskwtevt. However, these events should be excluded, which will marginally reduce the background and improve sensitivity.

The new version of batmaskwtevt, version 1.16 (released with HEASoft 6.1.2), excludes non-gamma-ray events from further processing. The BAT team recommends that users re-run the batmaskwtevt with version 1.16 or better to incorporate these changes. Further information can be found in the recipe for running mask weighting for a given event file.

It is worth mentioning that the improvement in sensitivity may be so marginal that in some cases the significance of any one observation may actually decrease very slightly. On the other hand, the average of a large ensemble of observations should improve slightly.

SDC: BAT data from SDC pipeline has incorrect DATE-OBS/END keywords

Update: The SDC has now reprocessed all observations which were affected by this problem. Users should no longer have to apply this workaround. With Swift 2.1, more descriptive error messages are produced.

The BAT software tasks depend on the proper DATE-OBS and DATE-END keywords in order to access the CALDB system. If these keywords are incorrect, then the tasks will attempt to find the wrong files in CALDB.

Before the date of XXX the Swift Data Center (SDC) produced some files with the date 2001-01-01, which causes this CALDB problem. You can check for the problem by running most tasks with chatter=5. If you see "strtdate=2001-01-01" before the task quits, then you have this problem. Also, you can run fkeyprint filename DATE-OBS and check for '2001-01-01'.

A workaround is to correct the DATE-OBS and DATE-END keywords. You can do this with the following commands:

fthedit myfile.fits DATE-OBS add value="YYYY-MM-DD"
fthedit myfile.fits DATE-END add value="YYYY-MM-DD"

where YYYY-MM-DD is the proper date of the observation.

This bug was fixed on May 4, 2005 (pipeline processing version 2.1.6). However, the workaround will still be needed for old data before this date, until the SDC reprocesses it.

batoccultmap: incorrect exposure correction

batoccultmap is used to compute the exposure correction due to occultation by the earth or other celestial bodies. Typically earth occultation only affects the edges of the image. However, a bug was found in this task which incorrectly computes the exposure correction over the entire image.

The error does not always occur. The visible portion of the earth's limb must be entirely in the southern celestial hemisphere, the earth must be at the very edge of the image, and the CONTOUR algorithm must be used. Even then, the behavior is not always predictable.

The result is that the full image has a depressed fractional exposure level. Typically the loss is a few percent. Based on analysis of BAT data from 2005, 93% of results will be correct, 98% will be correct to within 2%, and 99.5% will be correct to within 5%. For comparison, relative BAT fluxes are calibrated to within a few percent at best.

Workarounds:

• Use the IMAGE algorithm of batoccultmap instead of the CONTOUR algorithm

• Take the exposure result, and divide the full image by the central pixel value

This bug was been fixed in HEASoft 6.1 (Swift Build 19).

batbinevt: light curves have slightly incorrect energy bins

The task batbinevt is used to make spectra and light curves from BAT data. A bug in the way that energy bin assignments are made will lead to slightly incorrect reported count rates.

The easiest way to explain it is by example: if you ask for a light curve from 15-25 keV, then you actually get a light curve from 15-25.1 keV (not the extra 0.1 keV). The upper bin edge will always be too large by 0.1 keV.

If you are making a vector light curve (multiple energy bands), or a spectrum, then only the last energy bin is affected.

Thus, this is typically a small effect: spectra are basically unaffected (since the top bin is usually ignored). Light curves made in individual bands are affected. However, for wide energy bins, the light curves will be off by only a small amount (<1% for the 15-25 keV case described above). The only place where it is a strong effect is when you make many individual light curves in narrow energy bands.

This bug has been fixed for HEADAS 6.0.5 (Swift Build 18).

Mask tagged light curve systematic flux errors

Discussion: BAT mask tagged light curves are generated on board by the BAT flight software. The on-board process involves generating a mask weight map via ray tracing (similar to the ground task batmaskwtimg). On the ground, the raw light curves require further processing before they are scientifically meaningful.

The "mask tagging" process requires that the source position be known in advance, in instrument coordinates. This transformation requires knowledge of the spacecraft attitude, the instrument-to-spacecraft alignment, and the source celestial coordinates. A bug has been found in the BAT flight software which makes the incorrect transformation. The ray-traced position used for generating the mask weight map is several arcminutes off of the true position.

The point spread function is thus sampled significantly off-peak; this irretrievably reduces the signal to noise of the mask weighted light curve fluxes. Also, the flux itself is underreported compared to its true value.

The task batmasktaglc now has a "fudge" parameter which corrects the light curve values to be comparable to mask weighted light curves derived from event data. The default value for the task reflects the BAT team's knowledge of the error introduced by teh flight software.

Updated (15 Oct 2005) - Closed by HEASoft 6.0.3 release.

XSPEC crashes with segmentation fault with BAT spectra

This problem has been solved in the Swift 2.l release.

It was recently discovered that XSPEC version 11.3.2 crashes when reading BAT data with a segmentation fault error. This bug occurs for any "Type II" spectral file, but only on certain platforms (e.g. Linux and Solaris). Version 11.3.2 is the version released in HEASOFT 6.0. XSPEC version 12 is not affected by this bug.

Currently the best solution is to obtain a software patch from http://heasarc.gsfc.nasa.gov/docs/xanadu/xspec/xspec11/bugs.html and recompile XSPEC.

Another workaround is to add the XFLTNNNN keywords where NNNN ranges from 1 to 10. This can be done with the following C-shell commands:

foreach num (01 02 03 04 05 06 07 08 09 10)
  fthedit myfile.pha XFLT00${num} add value=${num}
end

baterebin: Possible extra rows in EBOUNDS extension of output DPH

baterebin is used to reset the energy scale for survey histograms accumulated on-board. This can improve the survey performance since typically the ground knowledge of the energy scale is better than the flight system provides. baterebin can "rebin" the output survey DPH to into a smaller number of bins.

If the number of energy bins in the output DPH is less than the number of rows (time bins) in the input DPH, the EBOUNDS extension of the output DPH will have extra rows with spurious energy bounds (left over from a copy of the input DPH).

batbinevt will crash with erroneous energy bounds.

The workaround is to delete the extra rows in the EBOUNDS extension before running batbinevt or other processing.

batbinevt: Incorrect exposure for survey analysis

batbinevt can apply a user-specified good time interval (GTI) file, or by specifying tstart/tstop on the command line.

If either of these time selections cuts through the middle of a survey histogram (DPH), then what should happen is that DPH is excluded from analysis. What actually happens is somewhat complicated, and may result in an incorrect EXPOSURE keyword value being computed (the same is true for the GTI extension).

This bug has been fixed for Swift 2.1.

CALDB: Incorrect Spectral Response < 20 keV

The pre-launch BAT spectral response file has significant systematic errors below 20 keV. This are caused primarily by the model of passive absorbing material in the BAT field of view. The errors were 30-50% in the 15-20 keV band.

The response matrix has been improved significantly for builds 12 and 14. Users should retrieve the newest set of CALDB files at the same time as downloading new software (at least Swift 2.0 and the corresponding CALDB release).

Users should be aware that significant systematic errors remain even after these adjustments, so they should apply a systematic error vector to all spectra.

CALDB: Incorrect Alignment Matrix

The BAT alignment matrix components are composed of two files: the "TELDEF" file which describes the alignment of the BAT boresite with respect to the spacecraft, and the "aperture" file which describes the alignment of the mask with respect to the detector array.

These files were checked into CALDB with their pre-launch best guess values. They were further refined after launch according to the calibration plan, and using serendipitously detected sources with known positions.

Users of the pre-launch matrix will find the following problems:

1. Sources will appear to be at the wrong locations;

2. Mask weighted fluxes for known sources will be lower, or zero,

   • since the known celestial position will translate to the incorrect detector position. This causes the mask weighting function to sample the PSF off-center, and thus reduces the response.

Users with pre-launch files should download a revised set of CALDB files. (20041120 version 1 or later).

batbinevt: Incorrect EXPOSURE Keyword

The batbinevt task makes spectra. It writes "Type II" files which can have multiple spectra per file. It writes an EXPOSURE column to record the exposure for each spectrum.

However, the input event or survey file also has an EXPOSURE keyword, which was not being overwritten. Thus it was possible to have conflicting exposure values. Unfortunately, XPSEC uses the keyword (incorrect) value instead of the column (correct) value.

This bug is fixed in Swift 1.2.

Workaround. Remove the EXPOSURE keyword from the spectral file. Since the EXPOSURE column is still present, XSPEC will still work, and should report the correct fluxes and fluences.

Commands to remove the EXPOSURE keyword from myfile.pha:

fthedit myfile.pha EXPOSURE delete

batcelldetect: Incorrect Error Bars

Discussion: batcelldetect performs a PSF fit to detected sources in an input image. This fit is done with a least-squares routine. Errors are estimated by using the formal statistical error (i.e. covariance matrix). The problem is that the error bars were too small by a factor of ~4 compared to the "true" values based on population analysis. This turned out to be because the images were oversampled by a factor of 2 in each dimension, which affects the statistics. batcelldetect attempted to account for the oversampling, but did it incorrectly in versions 1.09 and earlier.

batbinevt: Incorrect Handling of float point DPHs

Discussion: batbinevt reads detector plane histograms (DPHs). DPHs are commonly stored as integer counts, but can be stored as floating point (fractional) counts. A floating point DPH can be created by downstream processing, such as by baterebin, which reassigns fractional counts to each energy bin.

batbinevt was reading all DPHs as integers. Floating point counts were truncated at the integer level, resulting in (sometimes severe) undercounts.

This has been fixed for build 12.

batmasktaglc: light curve error bars too small

Discussion: BAT mask tagged light curves are generated on board. These raw light curves require further processing before they are meaningful. More specifically, the raw light curves are generated using unbalanced mask weights. The task batmasktaglc accounts for this, and generates background-subtracted (balanced) light curves.

Versions 2.2 and earlier of the task incorrectly calculated the light curve error bars. This has been corrected for build 12.

batmaskwtevt/batmaskwtimg: High-Energy Background Contamination

The mask weighting approach to extracting flux requirees that the weights be balanced. That is, the sum of the weights must be zero. If they are not, then it is possible for the background to contaminate a weighted spectrum or light curve. This would be especially apparent at high energies where the intrinsic source flux is typically low.

Versions 1.5 of batmaskwtimg and batmaskwtevt did not have a perfectly balanced set of weights, which led to such contamination. This was a bug, and was fixed for Swift build 12.

In BAT Build 10 (Swift 1.0) the response matrix task, batdrmgen, also had problems at high energies. These problems were caused by the incident energy scale not extending to high enough energies. This problem was fixed in BAT build 11 (Swift 1.1).