rgsevents adds the EVENTS and REJPIXn tables to the intermediate event list for a single RGS CCD exposure, which has been processed by rgsbadpix. These tables are sorted in increasing order of frame number. The EVENTS table is also cross-referenced with the existing PIXELS table so that the correspondence between the reconstructed events and the raw telemetered pixels is not lost. Throughout this document a marks items that do not apply to High Time Resolution (HTR) mode data and a marks items that apply only to HTR mode data.
The event reconstruction algorithm defines an event as a maximal set of adjacent pixels. That is, any two pixels which share an edge are contained within the same event. The user has the option to disable event reconstruction, which only means that each qualifying telemetered pixel is treated as a separate event regardless of its proximity to other pixels. To cross-reference the reconstructed events with their comprising telemetered pixels a column named EVENT is added to the PIXELS table, in which is recorded for each pixel the EVENTS table row number of the event in which it is included, or null if it is not associated with an event. From the raw pixel data the following properties are computed for each event and stored in the EVENTS table. Also stored for each event are three properties copied from the EXPOSURE table: frame number, flags and timestamp.
Total energy, both calibrated and raw.
Total number of pixels, or area of the event.
Chip-oriented DPP shape code for any event confined within a two-by-two pixel region; otherwise null. The shapes are shown below, with the numeral indicating both the code number for each pattern and the relative position of the reference pixel. Note that in the PIXELS table the telemetered coordinates mark the location of the reference pixel, but in the EVENTS table the centroid coordinates may lie anywhere within the bounding rectangle of the event.
** * * * ** ** 0 1* 2 3* 4* 5* 6 7
Coordinates of the event centroid in various units:
These flags indicate conditions which cast serious doubt upon the quality of the event as an x-ray detection:
At least one pixel included in the event is found in the bad pixel tables.
The pixel under the event centroid shares an edge with a pixel from the bad pixel tables.
The pixel under the event centroid lies in the first or last row or column of the telemetered window.
The pixel under the event centroid shares an edge with the opposing node.
The calibrated energy of every pixel included in the event lies below the acceptance threshold.
The event does not lie entirely within a two-by-two pixel region.
These flags provide information about the composition of the event:
At least one pixel included in the event lies in node zero.
At least one pixel included in the event lies in node one.
At least one pixel included in the event represents an on-board reconstruction.
Included also are any flags set by rgsframes in the EXPOSURE table. For each flag present in the output table a Sparse message declares the total number of events so flagged.
For each node the CCF provides PI thresholds for acceptance and rejection—not to be confused with similarly named thresholds used on-board by the Data Preprocessor (DPP). Since these thresholds are directly applicable only to single-pixel energies, the average highest single-pixel energy is computed for pixels with on-board split-event reconstruction (SER) using an empirical charge-splitting ratio provided for each grade (no SER correction is applied in HTR mode). Any pixel with PI less than the rejection threshold is ignored, just as if it had not been telemetered. Further, any event that does not include at least one pixel with PI at or above the acceptance threshold is flagged with BELOW_ACCEPTANCE. The floating-point pixel PI values are summed over the pixels comprising each event and “pixelized” by rounding to the nearest integer. The pixelization of the event PI values, as well as the minimum and maximum (pixelized) values present in the data, are described by standard FITS attributes on the PI column of the EVENTS table. It may be unwise to assume that the minimum value is nonnegative.
A null shape code implies nothing about the shape of the event. In particular, it does not imply that the event is not confined within a two-by-two pixel region. A previous version of the DPP does not provide enough information about pixels of grade two and three for the ground software to determine the shape. Use the BAD_SHAPE event flag to test whether an event is two-by-two confined. The event centroid is computed as a PI weighted sum over randomized sub-pixel coordinates (to avoid aliasing effects). For pixels with on-board SER the combined energy is treated as if spread uniformly over the telemetered shape. If the shape is not available for a pixel, its energy is placed at a random offset from its upper right corner. HTR mode y-coordinates are randomly distributed over the full 384 row height of the chip (disabling randomization produces the nominal readout row used in the energy corrections). Randomization may be disabled via the CAL state. This program does not attempt to identify cosmic-rays by pulse-height analysis. If an event falls within a two-by-two pixel region it is considered to be an x-ray; otherwise it is something with a bad shape—possibly a cosmic-ray. Note that if any of the pixels in a two-by-two region have no shape information, BAD_SHAPE is not set as long as all pixels are under grade three. This should not be an issue with the current DPP, and in any case should pertain only to events straddling the node boundary.
While determining the flags for each event, special note is taken of pixels with certain flags, when these flags have not been set identically in the bad pixel map. These are additional rejectable pixels and may be needed when constructing the exposure map. The flags in question are: BAD_SHAPE, ON_BADPIX, NEXT_TO_BADPIX, ON_WINDOW_BORDER and ON_NODE_INTERFACE. The chip coordinates of each such pixel are added to the REJPIXn table for its node, along with its frame number and any of these flags that were set on its associated event. The REJPIXn tables augment the BADPIXn tables for the purpose of mapping exposure.
XMM-Newton SOC -- 2021-11-30