Документ взят из кэша поисковой машины. Адрес оригинального документа : http://xmm.vilspa.esa.es/sas/5.4.1/doc/epatplot/node3.html
Дата изменения: Fri Jan 10 22:18:56 2003
Дата индексирования: Sat Dec 22 09:04:30 2007
Кодировка:

XMM-Newton Science Analysis System


epatplot (epatplot-1.1.8) [xmmsas_20030110_1802-5.4.1]

Meta Index / Home Page

Description

The task reads the event pattern information of an input EPIC pn or EPIC MOS events file and determines the pattern distribution and pattern fraction of valid patterns of type single, double, triple, and quadruple. It creates a plot with these distributions and fractions as function of PI channel. The fraction plot for EPIC pn also contains model curves for single and double fraction for all modes (FF, eFF, SW, LW, TI, BU). For EPIC MOS only a common model is available for MOS1 and MOS2 and for all modes.

The models for single and double event fractions were derived to correct for corresponding event selections which were applied in accumulating an EPIC pn spectrum. The EPIC pn event fractions are included in the detector response matrices. To use the standard response matrix one needs to make sure that the pattern fractions of the events in the area selected for the spectrum follow the model. The EPIC MOS model curves were provided by the hardware group at LUX.

The single and double pattern fractions are highly sensitive to pile-up effectsin bright sources and in case of deviations from the model curves (at energies of about double the peak energy) wrong spectral fit results are expected. To produce pile-up free spectra the central part of the PSF for bright point sources should be excluded, e.g. select a ring instead of a circle via evselect. epatplot can then be used to verify the event pattern fractions in the remaining area used for the spectrum.

There is a slight indication that at very large offaxis-angles (well, close to the readout-nodes = CAMEX) singles are reduced and doubles increased as the noise is much higher there. If the target source is at the nominal position - close to the center of the FOV - this does not matter, for serendipitous (weak) off-axis sources the intensity may be too low anyway for significant effects on the pattern distribution. Differences may be visible if you have a bright source close to the CAMEX. For EPIC pn the task takes into account the spatial dependence of the pattern fractions.

The default behaviour is to select only events with FLAG, this can be changed via setting withflag=N (default: Y). Invalid EPIC pn patterns are also shown to indicate how much energy is lost by pattern pile-up.

If one is interested in the spatial distribution of events with intrinsic FLAG=0 then set withoutputmask=Y: This reads the bad pixel extension(s) and the offset column extension(s) and creates a CCD map where all regions are set to 0 that have an intrinsic value of FLAG$>0$, i.e. events on bad (hot, dead, etc.) pixels, next to bad pixels, out of the FOV, close to the read-out window, on and next to offset columns. If the task finds an extension BADPIX then it assumes that this is an intermediate single chip event file as created during the pn chain processing, it tries to determine the relevant CCD number from the FITS header to set the FOV accordingly. If it finds extensions of the form BADPIXnn it takes nn as the CCD number. If no bad pixel extension is found at all the setting withoutputmask=Y is completely ignored as then the task cannot reliably determine the bad pixel contents of the file. Similarly for intermediate single chip files OFFSETCO and OFFSETS are accepted, for final event lists and products derived from those OFFSETnn and OFFSETS are read (the latter is then searched for the CCD number column). If no offset extension is found these flags are not used for the output map as this information cannot be reliably retrieved from the events file in general. An event file (final or intermediate) produced with epchain should have all the relevant information incluced (if not explicitly switched off, of course). The parameter outmaskname is parsed for a CCD number placeholder (##), if not found then the corresponding CCD number is appended to this parameter value (it cannot be predicted a priori how many output maps have to be created).