Chandra X-Ray Observatory (CXC)
Skip to the navigation links
Last modified: 15 December 2011

URL: http://cxc.harvard.edu/ciao4.4/why/multiobi.html

Multi-OBI Observations


Introduction

An Observation Interval (OBI) is an uninterrupted observing interval for a single ObsId. An ObsId may be broken into more than one OBI for a variety of reasons, one of them being that the original observation did not get enough good time. The observation is then known as a multi-OBI observation.

Level 1 and level 1.5 data products are processed by OBI and have the OBI number in the filename. ObsID 433 (MCG-6-30-15, HETG/ACIS) has three OBIs:

acisf00433_001N003_evt1.fits
acisf00433_003N003_evt1.fits
acisf00433_004N002_evt1.fits

The OBIs are numbered 001, 003, and 004. As seen here, the OBI numbering within an ObsId does not have to be contiguous and might not start at zero (000).

Multi-OBI Observations and Standard Data Processing

The OBIs are processed individually to create the level 1 and level 1.5 data products in standard data processing (SDP). Data from different OBIs are combined by ObsId in level 2 products. The tool dmmerge is used to merge the level 1 (or 1.5) event files in SDP, creating a single level 2 event file for the ObsId.

If the values of certain header keywords - such as FP_TEMP, ROLL, and SIM_Z - vary by more than a set threshold, dmmerge omits them from the output file. This prevents a misleading value from being retained in the header of the merged file. Users who have obtained a multi-OBI observation from the archive should use the SDP-produced evt2.fits file with this information in mind.

Reprocessing Multi-OBI Data

To reprocess the data (i.e. to apply new calibration), begin with the individual level 1 event files and process them separately. If the OBIs are particularly far apart in time, e.g. one was done with a focal plane temperature of -100 C and the other at -120 C, there may have been calibration changes between the two datasets. Processing each file separately ensures that the correct calibration for that data is applied.

For most files, the OBI number is in the filename, making it easy to match up the event file with the related files (i.e. acisf00433_001N003_flt1.fits goes with acisf00433_001N003_evt1.fits). Many of the level=1 files do not include the OBI number, as the filename is a timestamp, e.g. the aspect solution (pcad_asol1.fits), the parameter block (pbk0.fits), and the bias files (bias0.fits).

For these files, it is possible to match the timestamp in the filename to the TSTART header keyword value for each of the level=1 event files:

unix% dmkeypar acisf00433_001N003_evt1.fits TSTART echo+
71322523.58974

unix% dmkeypar acisf00433_003N003_evt1.fits TSTART echo+
76841388.754921

unix% dmkeypar acisf00433_004N002_evt1.fits TSTART echo+
83241699.117097

The files for each OBI are then:

Note that the aspect solution files also have the OBI_NUM value recorded in a header keyword:

unix% dmkeypar pcadf071323369N002_asol1.fits OBI_NUM echo+
1

Combining the Level=2 Event Files

At the point where a new level 2 event file has been produced for each OBI in the observation, one of two things may be done:

  1. For imaging analysis:

    Use the merge_all script to combine the two event files, as illustrated in the Merging Data from Multiple Imaging Observations thread. As noted in the thread, the merged event list should not be used for spectral analysis, since it does not contain sufficient information to generate correct response files (RMFs and ARFs).

  2. For spectral analysis:

    Rather than merging them together, the files must be analyzed independently. First, create response files for each of the OBIs by running the appropriate response tools (see "ahelp response"); the fullgarf script can be used to create responses as well. The spectra may be fit either independently or simultaneously.

Using Bad Pixel Files in Analysis

There is a separate bad pixel file for each OBI. Merging bad pixel files is not trivial, since there can be multiple reasons a pixel is marked as bad and there can be time dependence for bad pixels (e.g. afterglows and bias parity errors).

If the event files are merged, then the user can make a crude approximation by picking one bad pixel file to be used in further analysis. It will be somewhat incorrect for the other OBIs, due to the observation-specific afterglows and bias parity errors mentioned.

Further Information

More information is available from the Multi-part Observations section of the Chandra Standard Data Distribution Contents page.


Last modified: 15 December 2011
CXC logo

The Chandra X-Ray Center (CXC) is operated for NASA by the Smithsonian Astrophysical Observatory. 60 Garden Street, Cambridge, MA 02138 USA.   Email: cxcweb@head.cfa.harvard.edu Smithsonian Institution, Copyright © 1998-2012. All rights reserved.