Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://xmm.vilspa.esa.es/sas/8.0.0/doc/ebadpixupdate/node8.html
Дата изменения: Wed Jul 2 04:59:02 2008 Дата индексирования: Fri Sep 5 22:53:19 2008 Кодировка: Поисковые слова: carl sagan |
In the calibrated events lists generated by the pipeline, the events found to be on a bad pixel have already been removed. That operation is of course irreversible.
But epchain and emchain allow to generate events lists in which all events flagged for rejection (including those on a bad pixel) are still present. In that case the bad pixel flagging is reversible. Note that this is not completely true for MOS, because emevents by default removes the bright pixels and reanalyses events, so that a double event including a bright pixel will be changed into a single plus the (flagged) bright pixel. That behaviour may be suppressed (analysepatterns=N) in which case entire events are flagged, as PN does.
The overwrite=Y option may be used to replace the existing bad pixels with the new ones instead of adding the new bad pixels to the old ones. This means the events will be unflagged and the bad pixel lists reset, for all CCDs declared in ccds or corresponding to the tables in badpixtables.
The bright pixels previously declared on-board (BADFLAG=1) will not be removed from the list of bad pixels by the overwrite=Y option (the list of on-board bright pixels will be incremented). The corresponding pixels were removed on-board, so they cannot be recovered. Nevertheless, if the list of on-board bright pixels written by the PPS or emchain was wrong, the replaceonboard=Y option allows to replace them and reset the CLOSE_TO_ONBOARD_BADPIX flag. The other bad pixels will be incremented, unless overwrite=Y as well.
Use those option with caution. The program will try to check that the events flagged previously were not already removed, but this is not fool proof. In a non-interactive context, the forcereplace=Y option should be used to prevent activating the checks.
XMM-Newton SOC/SSC -- 2008-07-02