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_004N003_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

As mentioned above, 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.

Analyzing Multi-OBI Data

To reprocess the data (i.e. to apply new calibration), begin with the individual level 1 event files from SDP 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.

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:

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).
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 in Sherpa, as shown in the Sherpa threads.

A note on creating responses: 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). This is not the case with the aspect solution (pcad_asol1.fits) files.

To make sure that the correct aspect solution file is used for each OBI when creating responses, check the OBI_NUM header keyword. Using this observation as an example:
```
unix% dmkeypar pcadf071323369N002_asol1.fits OBI_NUM echo+
1

unix% dmkeypar pcadf076842067N003_asol1.fits OBI_NUM echo+
3
```
So pcadf071323369N002_asol1.fits goes with acisf00433_001N003_evt1.fits (OBI 1), pcadf076842067N003_asol1.fits goes with acisf00433_003N003_evt1.fits (OBI 3), and so forth. Remember that there may be more than one pcad_asol1.fits file for an OBI.

Further Information

There have been several Helpdesk tickets on how to analyze multi-OBI observations. Search the database with "OBI" in the "Resolution" field to see the problems that others have encountered, along with the solutions; begin at the end of the results list, as the recent responses are likely to be more relevant to this topic.

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