XMM-Newton Science Analysis System


badpix (badpix-2.33) [xmmsas_20230412_1735-21.0.0]

Comments

• The task was originally designed to handle RGS data also. The BADPIX extension here contains the CHIPX/CHIPY chip-orientated co-ordinates of the bad pixels. Though this functionality still exists, it is recommended to use the task rgsbadpix.

• The task checks for duplicity between any badpixfind input and bad pixels contained within the CAL. Irrespective of whether CCF bad pixels are required to be input into the BADPIX extension or not, the task gives general information as to CCF/badpixfind double entries. If entries from the CCF and from badpixfind covering the same coordinates are required to be input into the BADPIX extension, then the badpixfind entries are split and purged such that no RAWX/RAWY coordinate has more than one entry (i.e. the CCF entries take precedent). Also the task checks whether the badpixfind entries themselves have any overlapping pixels. If so, the badpixfind data are purged, precedent being given to hot pixels over dead pixels (over flickering pixels).

• The task, via the parameter emptyextension=Y, produces an empty BADPIX extension. Also, via the parameter windowfilter=Y, the task filters the bad pixels for those within the input file WINDOW range (entries are adjusted if they lie across the WINDOW border). The default values for both parameters are `N'.

• Information from the hardware groups is required regarding how the bad pixels will be handled on board in timing and burst mode. The badpix task at the ground could, for example, use the same badpix sets (1 and 2), as for the imaging modes, and add them as an extension to the raw event file. Event flagging then has to be dealt with in the events tasks.