Документ взят из кэша поисковой машины. Адрес оригинального документа : http://hea-www.harvard.edu/PROS/PUG/node208.html
Дата изменения: Unknown
Дата индексирования: Mon Oct 1 23:31:38 2012
Кодировка:

Поисковые слова: р п р п р п р п р п р п р п р п п р п п р п п р п п р п п п р п р п п р п р п п р п р п п р п р п п р п р п п р п р п п р п
Filtering ROSAT HRI data on the basis of background level next up previous contents
Next: AXAF Recipes Up: ROSAT HRI Recipes Previous: Quantum Efficiency Correction (a.k.a.

   
Filtering ROSAT HRI data on the basis of background level

For some observations, a significant amount of data may have been rejected during SASS processing because the background level was higher than the calculated threshold for rejection. It is also possible that for some requirements, an observer may wish to discard some data from the normally processed `accepted' event list in order to have only very low background data. Starting with SASS processing version (tbd) in late 1996, additional information on background rejection and cumulative exposure times during (rejected) high background intervals is presented on the field summary page (also contained in the rh...._output.lst file generated from the RDF fits files). The MAXIMUM HIGH BACKGROUND (the largest level which will be accepted) can also be read with `tprint' from the (RDF) generated table, rh..._stdqlm.tab. The units for MX_HIBACK (an integer) are E-7 counts/sec/pixel.


REJECTED EVENTS

Photons can be rejected for two reasons: either by time filters (e.g. high background intervals) or by their spatial coordinates. In the later case (e.g. the edges of the detector which are normally masked out, or in areas defined by the hotspot masks), the 'status' attribute of each photon is used to designate `accepted' (status=0), rejected because of hotspot (status=1), and rejected because it is in the edge masked area (status=2).


The following discussion and recipes are restricted to RDF formatted ROSAT data since Rev0 processing handled rejected events differently.


The recipe will allow the user to include rejected events in the generation of a new qpoe file and filter on the background level. If the SASS rejected events are not required, then skip steps 1 and 3, using conventional filenames and reasonable selection values in step 2.


1.
Run fits2qp on the rh*_bas.fits file to create two qpoe files.

(a)
Standard processed events (rh*_stnd.qp): with the parameter set as:

``which_e=standard"

(b)
Rejected events (rh*_rej.qp):

with the parameter set as:

``which_e=rejected"

``which_gti=all"

2.
Run the task `hkfilter' to create a time filter for the rejected events qpoe file.
	>hkfilter "rh*_rej.qp[hiback=(10:20)]"
	
	     - where the HIBACK values are your choice of minimum and maximum values.

	>qpcopy "rh*_rej.qp[@hk.flt,status=(0)]" qpoe=rh*_filt_rej.qp

	     -this produces the filtered (rejected) qpoe file

3.
Create the new standard and rejected qpoe file

	     - create an ascii file called merge.lst listing the 
	       two files to be appended (rh*_stnd.qp and rh*_filt_rej.qp).

	>qpappend @merge.lst

4.
Other options

It is possible to run ``rarc2pros" or ``rfits2pros" for the first step with the parameter `unscreened=yes'. This creates a qpoe file with standard + rejected events. Then all is needed is step 2 running the tasks hkfilter and qpcopy.


next up previous contents
Next: AXAF Recipes Up: ROSAT HRI Recipes Previous: Quantum Efficiency Correction (a.k.a.
rsdc@cfa.harvard.edu
1998-06-10