Subsections

• 5.6.1 Source Spectrum
• 5.6.2 Background Spectrum
• 5.6.3 Background Scaling

5.6 Multi-ObsId Spectra

Most Chandra sources have been observed multiple times, either by design or as a result of scheduling constraints. Suppose a specific source was extracted from each of $N$ observations, and AE has constructed the following quantities:

• $N$ source spectra, $\{{\bf counts^{src}_i}, i=1..N\}$, each with a measure of the source aperture ``area'', $BACKSCAL^{src}_i$ (§5.4)

• $N$ background spectra, $\{{\bf counts^{bkg}_i}, i=1..N\}$, each with a measure of the background region ``area'', $BACKSCAL^{bkg}_i$ (§5.5)

(In this section variables that are functions of energy are shown in bold face. Such quantities are stored as columns in FITS files, rather than as keywords.)

Certainly, the most statistically rigorous approach to analyzing these extractions--performing photometry and modeling the spectrum of the source--would be to use a procedure that works with these $2 \times N$ spectra directly. For example, if each of the extractions had plenty of counts then one could subtract the backgrounds to form net spectra with error bars, and then simultaneously fit those $N$ spectra in XSPEC/Sherpa using the $\chi^2$ statistic. However, extractions with large numbers of counts are very rare among Chandra sources. Thus, if you're a fan of $\chi^2$ fitting then in many cases the single-ObsId extractions will have to be combined in some way.

The C-statistic offers an alternative spectral modeling approach that could, in principle, work with the $2 \times N$ spectra directly. We have not had the courage to implement the data structures and fitting scripts that would be required to do this. Even if this approach was implemented, there would be no obvious way to visually compare the data and model. Imagine a source in a Chandra deep field that has more than 20 extractions, each with 0, 1, maybe 2 counts, plus 20 background spectra; how could one ``see'' that the derived model ``fits'' the data?

Thus, AE has always taken the less rigorous approach of merging the extractions of a source to form a ``multi-ObsId'' source spectrum, background spectrum, ARF, and RMF.

5.6.1 Source Spectrum

The integer-valued multi-ObsId source spectrum is formed by summing all the events falling in all the source extraction regions:

$${\bf counts_{multi-ObsId}^{src} = counts^{src}_0 + counts^{src}_1 + ...}$$ (1)

The HEASARC/OGIP FITS keyword EXPOSURE in the multi-ObsId spectrum is set to the sum of the EXPOSURE keywords in the $N$ extractions.

5.6.2 Background Spectrum

Construction of a multi-ObsId background spectrum, and its scaling, is a more complex task that requires some discussion. We must somehow combine and scale $N$ background spectra into a multi-ObsId background spectrum that estimates the background that is polluting the multi-ObsId source spectrum.

When spectral analysis is performed on background-subtracted (net) spectra using $\chi^2$, then eventually, in someone's software, an estimate must be made for the number of background counts (in each spectral bin) expected to pollute the multi-ObsId source spectrum. The obvious method is to estimate separately the background polluting each source aperture (by scaling each background spectrum by its exposure ratio), and then sum those components:

$${\bf scaledCounts_{multi-ObsId}^{bkg}} = {\bf counts^{bkg}_0} (BACKSCAL^{src}_0/BACKSCAL^{bkg}_0) +$$

$${\bf counts^{bkg}_1} (BACKSCAL^{src}_1/BACKSCAL^{bkg}_1) + ...$$ (2)

However, $\chi^2$ methods also require an estimate of the uncertainty on the background in order to assign an uncertainty to the net counts observed in each spectral bin; this is where combining extractions gets difficult. One can imagine computing an uncertainty on ${\bf scaledCounts_{multi-ObsId}^{bkg}}$ by estimating the uncertainty on each term in eq. 2 and then propagating those errors. The multi-ObsId spectrum would then be stored as a real-valued RATE column in a HEASARC/OGIP FITS file, and the errors would be stored as a STAT_ERR column. However, reasonably-sized ACIS background regions will produce background spectra with mostly zero or one count per channel. Assigning errors to those low-count channels, and then propagating those errors would be very foolish. Such bogus non-Gaussian error estimates would then be additionally propagated within XSPEC/Sherpa when the source spectrum is grouped.

An attractive alternative approach is to simply sum all the background spectra to form one multi-ObsId background spectrum:

$${\bf counts_{multi-ObsId}^{bkg} = counts^{bkg}_0 + counts^{bkg}_1 + ... }$$ (3)

just as we did with the source spectra (eq. 1). This multi-ObsId spectrum is stored as an integer-valued COUNTS column in a HEASARC/OGIP FITS file, and XSPEC/Sherpa are responsible for assigning uncertainties to each spectral bin (after grouping).

When the C-statistic is used for spectral modeling, the background spectrum must be represented as a set of detected counts, rather than a set of count rate estimates. Thus, for both fit statistics it appears that we must form the multi-ObsId background spectrum via eq. 3.

5.6.3 Background Scaling

An appropriate scaling must be assigned to the multi-ObsId background COUNTS spectrum (eq. 3) so that the background subtraction ($\chi^2$ approach) or background modeling (C-stat approach) performed in the spectral analysis package corresponds to the background rate shown in eq. 2. Prior to February, 2009 AE calculated such a scaling independently on each channel of the background spectrum, resulting in an energy-dependent scaling:

$${\bf AREASCAL_{bkg}} = \frac{{\bf counts_{multi-ObsId}^{bkg}}} {{\bf scaledCounts_{multi-ObsId}^{bkg}}}$$ (4)

(The background scaling is represented in the multi-ObsId FITS spectra under the standard name AREASCAL, rather than the more common name BACKSCAL, so that observers have the choice of modeling the background spectrum rather than subtracting it.)

This energy-dependent scaling was merely an algebraic artifact to deal with the fact that the extractions being merged could have wildly different background scaling. For example, if the observer designed background regions to enclose a certain number of counts, then an off-axis background might be scaled by a factor of 4 and an on-axis background might be scaled by a factor of 40. In the multi-ObsId spectrum, a channel that (by chance) had counts only from the former would have an AREASCAL value of 4 and a channel that had counts only from the later would have an AREASCAL value of 40.

In the Fall of 2008 we realized that this design can lead to poor spectral fits when C-stat is used to model the background spectrum because the background scaling seems to be applied to the background model from which C-stat is calculated. When each channel has its own background scaling (via the AREASCAL column in AE spectra prior to February, 2009), then channels with large scaling values induce large spikes in the background model; apparently corrupting the fit. Such spikes occur when a channel of the multi-ObsId background has (by chance) data only from an extraction with a scaling much larger than the other extractions.

Even if one puts aside the phenomenon of these spikes, the revelation that every element of the AREASCAL vector (FITS column) in eq. 4 directly affects the background model in XSPEC raises an obvious theoretical issue, namely that eq. 4 is not defined for channels with zero counts!

In retrospect, it seems clear that there are theoretical objections to the very notion of combining background spectra that have different scalings (BACKSCAL values). In such a multi-ObsId spectrum, some extractions are over-represented and others are under-represented. Although one can contrive a scaling of the multi-ObsId spectrum (e.g. AE's historical AREASCAL column) that produces the correct background rate in each channel, information on the uncertainty in those rates has been lost. For example, imagine a channel in which ObsId #1 produced 25 counts with a scaling of 25 and ObsId #2 produced 10,000 counts with a scaling of 10,000, producing a scaled background of $1+1=2$. The Poisson uncertainty estimated (by XSPEC/Sherpa) for that value of 2 would be far too small, since it is based on the notion of a single observation with 10,025 counts. In fact, the 25 count extraction totally dominates the uncertainty on the scaled background.

From the perspective of the C-statistic, uncertainty information has similarly been corrupted in the example above. C-stat sees 10,025 indistinguishable background counts, equally contributing to the value of the C-statistic. The background model will be driven to closely follow the second ObsId's 10,000-count spectrum, mostly ignoring the 25-count ObsId, even though in reality the two ObsIds contribute equal background to the multi-ObsId source.

Thus, we have concluded that the only apparent way to fairly combine background spectra is to design the background extraction process so that all extractions of a given source require similar background scalings (BACKSCAL). AE's recipes have been modified to do this, and AE's extraction merging code (§7.8) now warns if the range of background scaling among the extractions is large. AE now defines the multi-ObsId background scaling to be the single value (independent of energy) that produces the correctly scaled background over a broad energy band:

$$AREASCAL_{bkg} = \frac{\sum_{0.5:8 keV} {\bf counts_{multi-O... ... {\sum_{0.5:8 keV} {\bf scaledCounts_{multi-ObsId}^{bkg}}(i)}$$ (5)

(The background scaling is represented in the multi-ObsId FITS spectra under the standard name AREASCAL, rather than the more common name BACKSCAL, so that observers have the choice of modeling the background spectrum rather than subtracting it.)