Search https://cxc.harvard.edu/ciao/
Contact the CXC HelpDesk
Last modified: 24 October 2023

URL: https://cxc.cfa.harvard.edu/ciao/why/multiobi.html
/ ciao / 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. The splitobs script automates the separation of the files in the primary and secondary directories into different directories.

To manually separate the files into different per-observation directories, 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

For observations performed with the gratings, the REGION extension attached to the Level 2 event file also needs to be extracted for the correct OBI_NUM.

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_obs 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.

/ ciao / why / multiobi.html