MOSAIC MODE OBSERVATIONS

Mosaic mode observations have been handled by SAS and by ESAS in different ways at different times. This section describes the current situation, but the user should be aware that mosaic mode data processed in earlier epochs may require different handling.

The root of the issue is that, for a given instrument, all of the events from all of the pointings of a given observation are in a single event file with a single projection. Some SAS tasks, such as edetect_chain can handle multiple pointings within an event file. Most ESAS tasks, however, were built with the assumption of a single pointing, e.g., task_names. Thus, to run most ESAS tasks, the multi-pointing event files will need to be split into event files containing only a single pointing, and then changing the world coordinate system appropriately.

Figure 36: The R.A. as a function of time for a mosaic mode observation. The black points are each entry in the attitude information file. The colored points are show the time intervals of the individual pointings as identified by emosaic_prep

In the current regime, a mosaic mode observation will be stored in the archive in two ways. In the first form there is a single ODF and the obsid number for that ODF will, typically, end in 01, as in xxxxxxxx01. After processing with emchain/epchain (or, alternately emproc/epproc) the event file for each instrument will contain all of the events for all of the $n$ pointings. We refer to this as a “multi-pointing ODF”. In the second form, there is one ODF for each of the $n$ pointings, and the obsid numbers will have the same xxxxxxxx root, but will end in 31, 32, ... 31+n. We will refer to these as “individual pointing ODFs”. Both forms are needed for ESAS analysis. The xxxxxxxx01 version is required for the soft proton filtering, while the xxxxxxxx31 version is required for nearly everything else.

Note that processing each individual ODF through emchain/epchain requires as much time as processing the multi-pointing ODF.