The HXD significantly extends the spectral range of Suzaku (to 600keV) and has the lowest background rate of any instrument ever operated in the 10-600keV energy range. Because the HXD is a non-imaging instrument, the analysis of HXD data follows a different path from that used in XIS data analysis. It is much closer to the analysis flow of other collimated instruments, such as Ginga LAC and RXTE PCA. Users familiar with the analysis techniques for either will find much in common in what we describe below.
Users should also refer to the outstanding issues in HXD data analysis (chapter5).
A peculiarity of the HXD that needs to be taken into account is that there are two independent detector systems. These are the Gadolinium Silicate (GSO) / Bismuth Germanate (BGO) phoswich counters and the PIN silicon diodes. The PIN diodes are sensitive below keV, while the GSO/BGO phoswich counters detect photons above keV. The energy resolution of the PIN diodes is keV, while the phoswich counters have a resolution of 7.6% (FWHM) where is the photon energy in MeV. There are a couple of things that users should know about the detectors, in order to understand better the HXD data and their organization:
The HXD sensor (HXD-S) is composed of 16 main detectors (well units) arranged as a 44 array (see top view in Fig. 7.1) and 20 surrounding crystal scintillators for active shielding. Each unit consists of four GSO/BGO phoswich counters, and four 2 mm-thick PIN silicon diodes located inside the well, but in front of the GSO scintillator. The configuration of the sensor units is shown in Fig. 7.2.
|
This means that the data (``well'' data) do not initially
differentiate between PIN and GSO. The distinction is made later on in
the pipeline. For more information about the HXD detector, please see
the Suzaku Technical Description at
http://heasarc.gsfc.nasa.gov/docs/suzaku/prop_tools/suzaku_td.
HXD data begin as part of the RPT telemetry downloaded from Suzaku, and are converted into a collection of FITS files by the mk1stfits routine at ISAS. mk1stfits does not reject any events or apply any calibration to the data but merely converts it to FITS files. Once the files have been processed through the pipeline, they are included in the standard data download in the directory hxd/event_uf.
The HXD mk2ndfits pipeline task is then run on the mk1stfits output to create filtered, calibrated output event files, which are placed in the event_cl subdirectory. The calibration steps are summarized in Table 7.1. If updates of any of these tools became available since the initial processing of a dataset; the user can reprocess the data, see section 7.3 and 7.4 for details.
In addition to the above calibration steps, the event files in the event_cl have been screened applying the criteria summarized in Table 7.2.
Reprocessing, especially the recalculation of the PI column of the unfiltered event file using the most up-to-date calibration, is required for all PIN data taken after 2007 July 28 and processed with pipeline Version 2.0.6.13 or earlier.
For GSO data users should check the GSOGPT_F and GSOGPT_V keywords in the FITS headers of the cleaned event (observed) and background (simulated) files. These keywords define which HXD GSO gain parameter table (GPT) was used in the processing. If the values match then there is no need to reprocess the GSO data (note: the files ae_hxd_gsogpt_20091225.fits and ae_hxd_gsogpt_20100323.fits are identical in content). If the values do not match the data have to be reprocessed. If these keywords are not present the data were processed with pipeline Version V2.4.12.27 or earlier corresponding to a different way of performing GSO calibration (using GHT [gain history table] instead of GPT type gain files) and should be reprocessed, preferentially using the new setup. For more details on the two different GSO setups see http://heasarc.gsfc.nasa.gov/docs/suzaku/analysis/gso_newgain.html.
Please note that in general it is not necessary to run hxdtime again to perform the arrival time correction. This is because the only calibration item necessary for this process is the clock correction (or TIM) file, which, once generated, is not updated. Starting from the unfiltered event file the Suzaku FTOOLS hxdpi and hxdgrade have to be run (see section 7.11 for details). It is strongly recommended to uncompress the event file(s) before reprocessing.
The reprocessed event files should then be screened with the desired
event selection criteria. For this the standard criteria used in
Version 2 processing (Table 7.2) are available for the
GSO ( http://heasarc.gsfc.nasa.gov/docs/suzaku/analysis/gso_mkf.sel)
and for the PIN ( http://heasarc.gsfc.nasa.gov/docs/suzaku/analysis/pin_mkf.sel).
Users
can edit these files to modify the criteria.
The FTOOL aepipeline described in the following section can be used to perform reprocessing (in this case including hxdtime) and rescreening.
The powerful tool aepipeline (available since Suzaku FTOOLS version 14, i.e., HEAsoft v.6.8) duplicates the Suzaku processing pipeline. It allows the user to run all or part of the pipeline for XIS (detector selection available) and/or HXD (detector selection available) and to vary the calibration files used. A number of other pipeline processing parameters can also be changed. Please refer to the help text available, e.g., by typing ``fhelp aepipeline''.
The pipeline performs calibration - for the HXD this includes running hxdgtigen, hxdtime, hxdpi, and hxdgrade - as well as data screening - with defaults as given in Table 7.2 for the HXD. The screening criteria can be modified by changing the parameters hxd_pin_expr or hxd_gso_expr from their default values, e.g., in order to extraxt night Earth data. If the screened pseudo event data are used, e.g., instead of the unfiltered events for deadtime correction, hxd_pse_expr has to be used to apply the selected screening to those events as well.
The GTI file for telemetry un-saturated times created by hxdgtigen (aeNNNNNNNNNhxd_0_tlm.gti) is applied by aepipeline.
The following is an example of a simple call of aepipeline, performing recalibration (stage 1) and rescreening (stage 2) of the PIN data for a given observation or sequence number (here: 403049010) applying the default calibration and the default screening criteria. An example for GSO data, with an explanation of issues to consider in that case, is given in section 7.6.3.
> aepipeline indir=/scratch/403049010 \ outdir=/scratch/reprocessed/hxd \ steminputs=ae403049010 entry_stage=1 \ exit_stage=2 clobber=yes instrument=PIN
Warning:
(1) The outdir directory may not be a subdirectory of the indir directory. If it is, wrong results can be produced (double counting of events), especially in the case of multiple reprocessing runs. While the reporting will soon be improved, this currently happens without warning or error messages.
(2) The header keyword in the event files indicating the version of the processing pipeline used for reprocessing ``PROCVER'' is not updated by aepipeline. Check the log file produced by aepipeline for pipeline version information.
Since PIN is a collimated instrument, it is not possible to obtain background data from the observation data themselves. Instead, the HXD team has developed and run a model of the time-variable particle background, and made the results available.
Before describing the usage of these files, we should note the following:
The HXD background is distributed in the form of simulated event
files tailored to each observation. Two different non X-ray background
(NXB) models for the HXD/PIN are available, the tuned
background (``bgd_d'', METHOD=LCFITDT)
from
ftp://heasarc.gsfc.nasa.gov/suzaku/data/background/pinnxb_ver2.0_tuned/
and the quick background (``bgd_a'',
METHOD=PINUDLCUNIT) from
ftp://heasarc.gsfc.nasa.gov/suzaku/data/background/pinnxb_ver2.0/
. Please note that both versions are dead time corrected. These files
should only be used with Version 2 processed data, and vice versa. One
important change from Version 1.x background files is that the new
background files contain events from all units of PIN, regardless of
whether the bias voltage for PIN is 500V or 400V.
These directories are divided into subdirectories by month. For
example, background files for observations carried out in 2006 August
can be found in the subdirectory 2006_08. Within these
monthly directories, individual background files are listed
alphabetically. Note these files are named using the sequence number,
e.g.,
ae100005010hxd_pinnxb_cl.evt.gz.
The tuned background is available for observations since 2005-08-17, except for the period 2006-05-24 to 2006-05-29, when one of 64 PIN diodes showed an unusually high event rate probably caused by radiation damage. For this period, users can use the quick background by applying the event selection criterion ``UNITID3''.
The tuned background files cannot be produced until 1-2 months after the processing of the data. Once produced, they have estimated systematic uncertainties of about 3%, about half of the quick model, so we recommend the use of tuned background for publication-quality analysis. In any case it is strongly recommended to verify the reliability of the background estimate, by comparing the model spectrum and light curve with the ``earth occulted data'' (ELV). Since the quick background files can be delivered a few weeks after processing, these can be used for quick-look purposes before the tuned background files become available.
Notes on using the PIN background files:
Finally, note that the Version 2 PIN background files for (i) the
initial operation phase of the HXD (launch through 2005 September 1)
and (ii) the period 2006 March 23 - 2006 May 13, during which some
GSO parameters were changed, show a systematic offset. The workaround
is to use the Version 1 background files available at:
http://www.astro.isas.jaxa.jp/suzaku/analysis/hxd/v1/pinnxb/pinnxb_ver1.2_d/.
> mgtime "ae100005010hxd_0_pinno_cl.evt+2 ae100005010hxd_pinnxb_cl.evt+2" \ common.gti AND
xsel> filter time file common.gti
A pseudo event file filtered with the same GTI as the cleaned event file can be found in the cleaned event file directory in data processed with version 2.x (event_cl/aeNNNNNNNNNhxd_0_pse_cl.evt.gz). This is the most convenient input to hxddtcor, if you are analyzing the cleaned event files. Otherwise, supply the unfiltered event file(s) to hxddtcor. The syntax is:
> hxddtcor ae100005010hxd_0_pse_cl.evt ae100005010pin.pha
Note that the EXPOSURE keyword value will be rewritten.
Dead time correction is not necessary for the PIN background files.
> cp ae101005040hxd_wel_pin_bgd.pha ae101005040hxd_wel_pin_bgd_expcor.pha > fkeyprint infile=ae101005040hxd_wel_pin_bgd_expcor.pha \ keynam=EXPOSURE # FILE: ae101005040hxd_wel_pin_bgd_expcor.pha # KEYNAME: EXPOSURE # EXTENSION: 0 EXPOSURE= 1.755875832736492E+03 / Exposure time # EXTENSION: 1 EXPOSURE= 1.755875832736492E+03 / Exposure time # EXTENSION: 2 EXPOSURE= 1.755875832736492E+03 / Exposure time > fparkey value=1.755875832736492E+04 \ fitsfile="ae101005040hxd_wel_pin_bgd_expcor.pha+0"\ keyword=EXPOSURE > fparkey value=1.755875832736492E+04 \ fitsfile="ae101005040hxd_wel_pin_bgd_expcor.pha+1" \ keyword=EXPOSURE > fparkey value=1.755875832736492E+04 \ fitsfile="ae101005040hxd_wel_pin_bgd_expcor.pha+2" \ keyword=EXPOSURE > fkeyprint infile=ae101005040hxd_wel_pin_bgd_expcor.pha\ keynam=EXPOSURE # FILE: ae101005040hxd_wel_pin_bgd_expcor.pha # KEYNAME: EXPOSURE # EXTENSION: 0 EXPOSURE= 1.755875832736492E+04 / Exposure time # EXTENSION: 1 EXPOSURE= 1.755875832736492E+04 / Exposure time # EXTENSION: 2 EXPOSURE= 1.755875832736492E+04 / Exposure time
Now that spectral files have been extracted and exposure times have been corrected for the data and the background model, users need to obtain the appropriate response files. Due to the changes in instrumental settings (bias voltages used on-board and low energy threshold used in processing on ground), users must choose PIN response matrices that are appropriate for the epoch of observation, as listed in Table 7.3.
In addition, the effective area of the PIN varies within the XIS FOV,
because of the passive fine collimator that restricts the HXD FOV (see
Figure 8.3 of the Technical Description at
http://heasarc.gsfc.nasa.gov/docs/suzaku/prop_tools/suzaku_td/node11.html).
Therefore,
users need to select a response appropriate for the source
location. For sources that are extended over 5arcmin or more,
differential vignetting within the source region must be
considered. The cosmic background can be considered to be flat over
many degrees (ignoring the cosmic variance for the moment), which has
to be accounted for using a special response that averages the fine
collimator transmission over a wide area of the sky.
The original PI selected either the XIS nominal pointing (the target at the center of the XIS field of view) or the HXD nominal pointing (the target about 5arcmin off-axis relative to the XIS, but at a point of maximum throughput of the HXD/PIN). The actual pointing can be determined by inspecting the NOM_PNT keyword in the FITS files. Responses are provided for point sources observed at these positions. In addition, we provide a ``flat'' response appropriate for large, extended sources such as the Cosmic X-ray background (CXB). Table 7.3 lists calibration epochs and corresponding response files. Refer to http://heasarc.gsfc.nasa.gov/docs/suzaku/analysis/pinepochs.html for the first announcement of new epochs.
|
These files are available from the Suzaku CALDB
http://heasarc.gsfc.nasa.gov/docs/heasarc/caldb/suzaku/.
Now users can begin spectral fitting of the HXD/PIN data. In addition to the usual tasks of selecting the appropriate model etc., there are two steps that are needed here and that are described in the following two sections.
The background event file does not include the cosmic X-ray background (CXB). Since the CXB flux is about 5% of the background for PIN, users need to take it into account after subtracting the non X-ray background. One method is to estimate the CXB level by using the PIN response for the flat emission distribution (see Table 7.3). It assumes uniform emission from a region of 2deg 2deg.
A ``typical'' CXB spectrum is reported as follows, based on the
HEAO1 results
(Boldt, 1987,
http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1987IAUS..124..611B):
erg cmsstrkeV
Since the flat PIN response files are for 4 square degree field of view, we need to multiply this result by the appropriate ratio (4deg/1sr). Since 1sr = 3283deg, this becomes
erg cmsFOVkeV
Converting this into values appropriate for xspec, which assumes the power-law is normalized at 1keV and is given in units of photons, not ergs, we obtain:
photons cmsFOVkeV
Then we can simulate the CXB contribution to the PIN background with xspec. We fix the cutoff energie at the lower limit of the model ( keV). The folding energy, , is 40keV.
Note 1
This is the model of the CXB to be convolved with
the ``flat'' response. To fit the observation with a model for the
source, the simulated NXB spectrum, and the model for the CXB, a
re-scaled version (using the ratio of XIS nominal or HXD nominal
response vs. the flat response) of the model must be used. Although
the effects of the CXB should be investigated independently for each
observation, one can reproduce the observed counts from the diffuse
CXB when using the HXD nominal position response matrix by using
810 as a normalization factor (instead of
9.41210) in the previous model.
Note 2
For the XIS nominal position, the amplitude of the
powerlaw component should be increased by 10% to
8.810, since the CXB is to first order
position-independent while the HXD response to a point source at the
XIS nominal position is reduced by 10%.
Note 3
The NXB background file and the simulated CXB
PHA file can be added using mathpha, making sure
that the resulting EXPOSURE keyword is the common value,
i.e., the original NXB file exposure multiplied by a factor of 10 (and
not the sum of both exposure times).
Note 4
The simulated CXB spectra generated by
hxdpinxbpi (section 7.5.6) are based on the
Boldt (1987) model and the parameters given here.
The xspec input for the flat response case thus looks like:
XSPEC12>model po*highecut Input parameter value, delta, min, bot, top, and max values for ... 1 0.01 -3 -2 9 10 1:powerlaw:PhoIndex>1.29 1 0.01 0 0 1e+24 1e+24 2:powerlaw:norm>9.412e-03 10 0.01 0.0001 0.01 1e+06 1e+06 3:highecut:cutoffE>0.0001 15 0.01 0.0001 0.01 1e+06 1e+06 4:highecut:foldE>40 ======================================================================== Model powerlaw<1>*highecut<2> Source No.: 1 Active/Off Model Model Component Parameter Unit Value par comp 1 1 powerlaw PhoIndex 1.29000 +/- 0.0 2 1 powerlaw norm 9.41200E-03 +/- 0.0 3 2 highecut cutoffE keV 1.00000E-04 +/- 0.0 4 2 highecut foldE keV 40.0000 +/- 0.0 ________________________________________________________________________ XSPEC12>
Once this has been set up, users can use the fakeit none command with the pinflat response matrix.
Please note that the level of the CXB and its point-to-point scatter are an active research topic. Other estimates of CXB spectrum can be converted to xspec models following the same steps as above.
The accuracy of the PIN background model typically reaches as good as or better than 3-5% of the average background. It is strongly recommended to verify the reliability of the background model, though:
The FTOOL hxdpinxbpi automatizes the extraction steps described above, i.e., it produces the dead time corrected PIN source spectrum as well as the PIN background (NXB + CXB) spectrum.
The tool performs the following steps:
The following duplicates some of the information given for the HXD in general in sections 7.2-7.4 above, but with special emphasis on the GSO.
This document refers to the GSO analysis setup available since
HEAsoft v6.9, Suzaku FTOOLS Version 16. This version
of the GSO analysis uses a new type of software and calibration files
that implements a revised gain calibration of the HXD/GSO data. It
extends the low energy limit of the usable GSO data from 70keV down
to 50keV. For more details, see:
Yamada et al., 2011, PASJ 63,
No. 5
http://heasarc.gsfc.nasa.gov/docs/suzaku/analysis/gso_newgain.html
http://heasarc.gsfc.nasa.gov/docs/suzaku/analysis/gso_newarf.html
To maintain backward compatibility of the new GSO analysis setup in Suzaku FTOOLS Version 16 with the earlier one, the following steps have been taken:
The user may be familiar with the HXD-PIN analysis. Although the analysis method of HXD-GSO is similar to that of HXD-PIN, there are some differences as listed below:
Reminder: This document refers to the GSO analysis setup available
since HEAsoft v6.9, Suzaku FTOOLS Version 16. This new
version of the GSO analysis uses a new type of software and
calibration files that implements a revised gain calibration of the
HXD/GSO data. It extends the low energy limit of the usable GSO data
from 70keV down to 50keV.
Please also see
http://heasarc.gsfc.nasa.gov/docs/suzaku/analysis/gso_newgain.html.
The gain of the GSO changes with time, which is corrected with the gain parameter table in the CALDB (ae_hxd_gsogpt_yyyymmdd.fits). GSO data need to be processed with the appropriate gain paramter table which has to be of the same version as that used for the GSO-NXB files. If the versions of the GSO cleaned event file and GSO-NXB file are inconsistent, a cleaned event file has to be created by reprocessing unscreened files (*hxd*uf.evt), using hxdpi and hxdgrade. There is no need to apply hxdtime again, which has been completed before publishing the data. hxdpi converts pulse height (PHA) into photon energy (or pulse height invariant - PI) data. The gain parameter table, ae_hxd_gsogpt_yyyymmdd.fits in the CALDB, is required by hxdpi. An orbit file, aeNNNNNNNNN.orb is also needed. Please make sure that the orbit file is set correctly. The current version of hxdpi creates output even without the orbit file, but the output file may not be correct.
After applying hxdpi and hxdgrade data screening is required, e.g., with the standard criteria (see Table 7.2).
For the GSO reprocessing and rescreening the aepipeline tool can be used, which allows the user to run all or part of the Suzaku pipeline processing and to vary the calibration files used. A number of other pipeline processing parameters can also be changed. The functionality of hxdgtigen, which generates a telemetry un-saturated GTI, is also included here.
Below is an example of a call of aepipeline. Please, read the help file carefully (``fhelp aepipeline'') and set the parameters accordingly:
> aepipeline indir=NNNNNNNNN \ outdir=OUTPUT_DIR \ steminputs=aeNNNNNNNNN \ entry_stage=1 \ exit_stage=2 \ instrument=GSO \ attitude=../auxil/aeNNNNNNNNN.att \ housekeeping=../auxil/aeNNNNNNNNN.hk \ extended_housekeeping=../auxil/aeNNNNNNNNN.ehk \ makefilter=../auxil/aeNNNNNNNNN.mkf \ orbit=../auxil/aeNNNNNNNNN.orb \ timfile=../auxil/aeNNNNNNNNN.tim \ hxd_gsogpt=$CALDB/data/suzaku/hxd/bcf/ae_hxd_gsogpt_yyyymmdd.fits
Warning:
(1) The outdir directory may not be a subdirectory of the indir directory. If it is, wrong results can be produced (double counting of events), especially in the case of multiple reprocessing runs. While the reporting will soon be improved, this currently happens without warning or error messages.
(2) The header keyword in the event files indicating the version of the processing pipeline used for reprocessing ``PROCVER'' is not updated by aepipeline. Check the log file produced by aepipeline for pipeline version information.
The procedure for creating a GSO spectrum is mostly the same as that for the HXD-PIN, but, please, see section 7.6.2, item 2-5, for important differences to keep in mind.
The GSO Non X-ray Background (NXB) files can be downloaded
from
ftp://heasarc.gsfc.nasa.gov/suzaku/data/background/gsonxb_ver2.5/
and
ftp://heasarc.gsfc.nasa.gov/suzaku/data/background/gsonxb_ver2.6/. The
last part of section 5.6.2 explains the difference between
these two versions of GSO background model events. The NXB files are
available around one month after the actual observation date.
The accuracy of the current background model is as good as 3% of the averaged background. It is strongly recommended to verify the reliability of background, though, by comparing the model spectrum and light curve with the ``earth occulted data'' (ELV).
The GSO background event files do not include the Cosmic X-ray Background. However, the CXB is less than 0.1% of the total background rate in the GSO, and thus it is negligible.
|
The FTOOL hxdgsoxbpi automatizes the GSO spectrum extraction steps, i.e., it produces the dead time corrected GSO source spectrum as well as the dead time corrected GSO background (NXB) spectrum.
The tool performs the following steps:
Below an example of the usage of hxdgsoxbpi is given. Please,
read the help file carefully (``fhelp hxdgsoxbpi'') and set
the parameters accordingly. The NXB files are delivered with a fixed
grouping scheme, following the specific procedure of creating the NXB
files.
Download http://heasarc.gsfc.nasa.gov/docs/suzaku/analysis/gsobgd64bins.dat
in order to allow hxdgsoxbpi to group the source spectrum
accordingly.
> hxdgsoxbpi input_fname=aeNNNNNNNNNhxd_0_gsono_cl.evt \ pse_event_fname=aeNNNNNNNNNhxd_0_pse_cl.evt \ bkg_event_fname=aeNNNNNNNNN_hxd_gsobgd.evt \ outstem=test \ gsonom_rsp=CALDB \ groupspec=yes \ groupfile=gsobgd64bins.dat
For the spectral analysis an additional GSO arffile (``correction
arf'') is also required. This file can be downloaded from
http://heasarc.gsfc.nasa.gov/docs/suzaku/analysis/gso_newarf.html,
selecting the one appropriate for the aimpoint of the observation
(i.e., hxnom or xinom).
Pre-calculated PIN and GSO response files, combining ARF and RMF effects, are provided through the Suzaku CALDB for observations at the HXD and XIS nominal positions and for large, extended sources, see e.g., Table 7.3 for PIN. In order to obtain ARFs for arbitrary offset pointings, the FTOOL hxdarfgen can be used.
Description: The task hxdarfgen calculates the incident angle for each detector using the teldef, pi/pha, and atti files. The transmission rates onto PIN and GSO for various incident angles are summarized in the CALDB files named ae_hxd_pinart_YYYYMMDD.fits and ae_hxd_gsoart_YYYYMMDD.fits, respectively. The task reads these ARF tables to generate ARF file(s) for this observation.
Note: The output ARF file(s) should be coupled with the responses for the ``hxdnominal'' pointing position in both, the PIN and the GSO case.
Example: Calculate ARF file for merged for 64 PINs for spectral file ae20050405_2000_2100_hxd.pha using the teldef file ae_hxd_teldef_20050908.fits and the arfdb file ae_hxd_pinart_20070611.fits for pointing position (RA,DEC) = (274.0554, 49.8675):
hxdarfgen hxd_arf_pinid=64 hxd_arf_gsoid=17 \ hxd_teldef="ae_hxd_teldef_20050908.fits" \ attitude="attitude.fits" \ hxd_arfdb_name="ae_hxd_pinart_20070611.fits" \ input_pi_name="ae20050405_2000_2100_hxd.pha" \ point_ra=274.0554 point_dec=49.8675
Note: Definition of input parameters hxd_arf_pinid and hxd_arf_gsoid:
hxd_arf_pinid PIN ID (0...63 64:merged >64:UNDEFINED). Default set to 65. hxd_arf_gsoid GSO ID (0...15 16:merged >16:UNDEFINED). Default set to 16.
Note: Currently only point source ARFs can be produced, as can be seen from the definition of the optional imput parameters hxdarf_point_yn and image_fname:
(hxdarf_point_yn = y) Input position is POINT or not. Default set to yes. ``n'' is not supported yet in this version. (image_fname = NONE) Input image file, required only when hxdarf_point_yn is no. Default set to be 'NONE'. Image input is not supported yet in this version.
Users can also generate background-subtracted PIN light curves using these background files. In this process, users need to take the dead time into account, using the pseudo event files. Since pseudo events are generated by the HXD analog electronics every 4 seconds for each of the 16 units, we expect 16counts/4s4.0counts/s in the absence of dead time. Therefore, the live time is given by the measured pseudo event rate during the time bin divided by 4.
The following method for correcting for bin-by-bin dead time is recommended only for bins longer than 128s, to ensure that the dead time estimate is statistically accurate enough.
> fselect infile=ae123456789hxd_0_pse_cl.evt+1 outfile=pseudo_pure.evt \ expr="GRADE_HITPAT<=1&&GRADE_QUALTY==0" histkw=yes
Extract a lightcurve from this ``pure'' pseudo event file, while applying the merged GTI file, and save it as pin_pseudo.lc, for example.
> fcalc pin_pseudo.lc+1 pin_pseudo_div4.lc DTCOR "RATE/4" > faddcol pin_event.lc+1 pin_pseudo_div4.lc+1 DTCOR > fcalc pin_event.lc+1 pin_event_dtcor.lc RATE "RATE/DTCOR" > fcalc pin_event_dtcor.lc+1 pin_event_dtcor.lc ERROR "ERROR/DTCOR" clobber=yes
The above steps were: calculate the live time in the DTCOR column of a temporary file, pin_pseudo_div4.lc; copy that column into the light curve file, pin_event.lc; create a new light curve file pin_event_dtcor.lc in which the RATE column is dead time corrected; dead time-correct the ERROR column in that file.
> fcalc pin_bgd.lc+1 pin_bgd_div10.lc RATE "RATE/10" > fcalc pin_bgd_div10.lc+1 pin_bgd_div10.lc ERROR "ERROR/10" clobber=yes
Note that, in addition to the contribution from this background light curve, the observed light curve contains the cosmic X-ray background component, which can be treated as a constant.
The FTOOL hxdpinxblc automatizes the extraction steps described above, i.e., it produces the dead time corrected PIN source with background light curve, as well as the PIN background (NXB + constant CXB) light curve, and the background subtracted light curve.
The tool performs the following steps:
The procedure for creating a GSO light curve is mostly the same as that for the HXD-PIN, but please see section 7.6.2, item 2 and 3, for important differences to keep in mind.
|
The FTOOL hxdgsoxblc automatizes the GSO light curve extraction steps, i.e., it produces the dead time corrected GSO source with background light curve, as well as the GSO background (NXB) light curve, and the background subtracted light curve.
The tool performs the following steps:
Below an example of the usage of hxdgsoxblc is given. Please, read the help file carefully (``fhelp hxdgsoxbc'') and set the parameters accordingly.
> hxdgsoxblc input_fname=aeNNNNNNNNNhxd_0_gsono_cl.evt \ pse_event_fname=aeNNNNNNNNNhxd_0_pse_cl.evt \ bkg_event_fname=aeNNNNNNNNN_hxd_pinbgd.evt \ outstem=test \ bkgsub=yes \ binlc=128.0
The remainder of this chapter describes the details of the initial processing for the HXD. These steps, already performed in the processing pipeline, can be repeated by users if necessary (section 7.3, section 7.4).
For the HXD, the standard pipeline processing starts with an unfiltered file which contains events from both the GSO and PIN detector. This file contains ``wel'' in its filename and the DETNAM keyword has the value ``WELL''. We describe the processing steps, in the recommended order, below. Please note that users who only want a quick look at their data should not have to run these routines again but could use the files provided in the products directory.
Users are also advised to create a second directory in which the newly processed files will be saved as some of the routines would otherwise overwrite the existing files:
unix% mkdir event_cl2/; cd event_cl2/ unix% ln -s ../event_uf/aeNNNNNNNNNhxd_M_wel_uf.evt.gz . unix% ln -s ../hk/aeNNNNNNNNNhxd_0.hk.gz . unix% ln -s ../../auxil/aeNNNNNNNNN.tim.gz .
The first step is to calculate the HXD event arrival-time correction. The arrival time of each true event time (TIME) is calculated from the HXD internal detector time value and other detector corrections. The computed time is then converted to Suzaku time coordinates using four separate methods (selected using the input parameter ``time_convert_mode''). In addition, the tool hxdtime measures the actual time resolution of ``TIME'' during the observation. The standard way to run the hxdtime tool is the following:
hxdtime input_name=aeNNNNNNNNNhxd_M_wel_uf.evt \ create_name=aeNNNNNNNNNhxd_M_wel_uf2.evt \ leapsec_name=leapsec.fits \ hklist_name=aeNNNNNNNNNhxd_0.hk \ tim_filename=aeNNNNNNNNN.timwhere
Users may wish to confirm the following hidden parameters:
read_iomode=create (a separate output file will be created)
time_change=yes (TIME column will be updated)
grade_change=n (no change of GRADE_XX)
pi_pmt_change=n (no change of PI_SLOW, PI_FAST)
pi_pin_change=n (no change of PI_PIN)
gtimode=y (read and apply GTI extension)
gti_time=S_TIME (meaning of TIME in GTI, row level information)
time_convert_mode=4 (aste_ti2time function is used)
use_pwh_mode=n (no use of HXD_WEL_PWH extension of HXD HK FITS)
num_event=-1 (control value for ANL routine; read all event if -1)
event_freq=10000 (control value for ANL routine; frequency of messages)
anl_verbose=-1 (control value for ANL routine; verbose level)
anl_profile=yes (control value for ANL routine; dump profile)
After filling in the corrected event times, the next step is to adjust the detector gain for both HXD detectors. In Version 2 processing, the gain history files are generated by the HXD team and provided to the CALDB. We have therefore discontinued the documentation regarding the generation of the HXD gain history.
Once the gain drift has been measured, the (time) invariant event pulse-height (PI) values can be determined. For the HXD, hxdpi calculates the HXD PI columns (PI_PIN[0,1,2,3], PI_SLOW, PI_FAST) based on the relevant PHA data, the gain history and other calibration data, such as non-linearity in the analog-to-digital conversion. The Gd edge effect is not included in SLOW/FAST_PI. The effect is included in the response matrix table for the GSO.
NOTE: This is the task that uses the gain history files to correct the PI values. Users should obtain/use the most up-to-date gain history file (GHF) for the PIN and the most up-to-date gain parameter table (GPT) for the GSO (GHF for the old GSO setup, i.e., with hxdpi_old) from the CALDB, where they are frequently updated by the calibration team.
The correct syntax to run the hxdpi tool is:
unix% cat > hk_file.list << EOF ../hk/aeNNNNNNNNNhxd_0.hk.gz ../../auxil/aeNNNNNNNNN.ehk.gz EOF unix% hxdpi input_name=aeNNNNNNNNNhxd_M_wel_uf2.evt\ create_name=hxd_picorr_evt.fits hklist_name=@hk_list.dat\ hxd_gsogpt_fname=CALDB hxd_gsolin_fname=CALDB \ hxd_pinghf_fname=CALDB hxd_pinlin_fname=CALDB
where
input_name is the HXD FITS file input name;
create_name is the output name (see below);
hklist_name should be used to pass the HXD HK file name and
the extended hk file name using the @list syntax;
hxd_gsogpt_fname is the GSO gain parameter table from the CALDB (use hxd_gsoghf_fname with hxdpi_old);
hxd_gsolin_fname is the name of the CALDB file containing the GSO integrated non-linearity of the ADC;
hxd_pinghf_fname is the PIN gain history file from the CALDB;
hxd_pinlin_fname is the name of the CALDB file containing the PIN integrated non-linearity of the ADC.
Warnings:
Typical command line input to hxdpi is:
hxdpi input_name=ae401100010hxd_1_wel_uf2.evt read_iomode=create \ create_name=ae401100010hxd_1_wel_uf2-hxdpi.evt hklist_name=@hk_file.list \ hxd_gsogpt_fname=CALDB hxd_gsolin_fname=CALDB \ hxd_pinghf_fhame=CALDB hxd_pinlin_fname=CALDB \ event_freq=500000
HXD event files have 5 grade columns filled by the hxdgrade routine. The first column is called GRADE_QUALTY and stores the data quality. All events with a GRADE_QUALTY flag not equal to 0 should be ignored. The next two columns indicate the origin of the event. The column GRADE_PMTTRG is set to 1 for any PMT triggered event while the column GRADE_PINTRG is set for 1 for any PIN triggered event. Column GRADE_PSDSEL gives the GSO likelihood in the Slow/Fast diagram while the fifth column GRADE_HITPAT gives the hit pattern grade.
hxdgrade input_name=aeNNNNNNNNNhxd_M_wel_uf2.evt \ hxdgrade_psdsel_fname=CALDB \ hxdgrade_pinthres_fname=CALDBwhere
Warning:
Just as for hxdpi, hxdgrade has the hidden parameter
read_iomode set to overwrite by default, so the relevant
columns of the input file are modified. Users may want to set
read_iomode=create and specify an output file name using the
create_name option.
Up until this step the files contain both GSO and PIN (``WELL'') data. As described in the next section, a series of further screening procedures can be performed before separating the PIN and GSO data.
Before extracting data products like spectra and lightcurves one can select events for given criteria, either directly from the FITS file using the FTOOL fselect, or within xselect. Here we show how to proceed within xselect. The default parameters used for data screening can be found in the filter file. The ``select mkf'' command applies filter file based data screening. This translates the selection criteria into a boolean expression and calculates the corresponding Good Time Intervals (GTI). Additional selections, e.g., for user-defined times or particular event flags, can be applied. Within xselect the filtered events can then be used to create a (binned) spectrum (as well as responses) or a lightcurve.
The current cuts applied within the standard processing of the data read:
SAA_HXD==0 && T_SAA_HXD>500 && ELV>5 && ANG_DIST<1.5 && HXD_DTRATE<3 && AOCU_HK_CNT3_NML_P==1 && COR>6 && HXD_HV_W0_CAL>700 && HXD_HV_W1_CAL>700 && HXD_HV_W2_CAL>700 && HXD_HV_W3_CAL>700 && HXD_HV_T0_CAL>700 && HXD_HV_T1_CAL>700 && HXD_HV_T2_CAL>700 && HXD_HV_T3_CAL>700where
In particular, it is possible to create your own Night Earth HXD data by replacing ELV5 with appropriate expressions involving ELV, DYE_ELV (elevation above the sunlit limb of the Earth), and NTE_ELV (elevation above the night Earth).
Within xselect screening is performed as follows:
hakatan-91-event_cl2: xselect ** XSELECT V2.4 ** > Enter session name >[xsel] abc-guide Setting plot device to /NULL abc-guide:SUZAKU > read events > Enter the Event file dir >[./] > Enter Event file list >[] ae401100010hxd_1_wel_uf2-hxdgrade.evt Notes: XSELECT set up for SUZAKU Time keyword is TIME in units of s Default timing binsize = 16.000 Setting... Image keywords = UNITID UNITID with binning = 1 WMAP keywords = UNITID PIN_ID with binning = 1 Energy keyword = PI_PIN with binning = 1 Getting Min and Max for Energy Column... Got min and max for PI_PIN: 0 255 could not get minimum time resolution of the data read MJDREF = 5.1544000742870E+04 with TIMESYS = TT Number of files read in: 1 ******************** Observation Catalogue ******************** Data Directory is: /Volumes/Maison/Directories/Suzaku/MySuz/1E1841-045/v1.2.2.3/401100010/hxd/event_cl2/ HK Directory is: /Volumes/Maison/Directories/Suzaku/MySuz/1E1841-045/v1.2.2.3/401100010/hxd/event_cl2/ OBJECT DETNAM DATE-OBS DATE-END 1 1E 1841-045 WELL 2006-04-19T 2006-04-22T abc-guide:SUZAKU-HXD-WELL_PIN > abc-guide:SUZAKU-HXD-WELL_PIN > filter mkf > Boolean expression for filter file selection >[ ] SAA_HXD==0 && T_SAA_HXD>500 && ELV>5 && ANG_DIST<1.5 && HXD_DTRATE<3 && AOCU_HK_CNT3_NML_P==1 && COR>6 && HXD_HV_W0_CAL>700 && HXD_HV_W1_CAL>700 && HXD_HV_W2_CAL>700 && HXD_HV_W3_CAL>700 && HXD_HV_T0_CAL>700 && HXD_HV_T1_CAL>700 && HXD_HV_T2_CAL>700 && HXD_HV_T3_CAL>700 > Enter the filter file directory >[./] ../../auxil PREFR keyword found in header, using prefr = 0.0 POSTFR keyword found in header, using postfr = 1.0 abc-guide:SUZAKU-HXD-WELL_PIN >
At this point, both GSO and PIN events are still taken into account. Users can now select events from either one of these detectors by selecting on the column called DET_TYPE. DET_TYPE==1 selects PIN events and DET_TYPE==0 selects GSO events; e.g., for PIN:
abc-guide:SUZAKU-HXD-WELL_PIN > filter column > Enter filter on column(s) in the event file >[] DET_TYPE==1 abc-guide:SUZAKU-HXD-WELL_PIN > extract events
The WAM is the lateral BGO (= BiGeO crystal) anti-coincidence shield of the Hard X-ray Detector (HXD). It consists of 4 identical walls (referred as WAM 0, 1, 2 and 3), which are further composed of 5 anti-counter units for each wall. The primary role of the WAM is the background rejection for the HXD-PIN and GSO, but the WAM can observe bright gamma-ray transients such as gamma-ray bursts (GRBs) and soft gamma repeaters (SGRs) in the range of keV.
The WAM data consist of two types: Gamma burst (BST) and Transient (TRN) data (Table 7.4). The BST data are available only when the onboard GRB trigger occurs. They have time history (TH) data with a fine time resolution (1/32 or 1/64s) in four energy ranges and the 55 channel pulse height (PH) histogram data with coarse time resolution (1/2 or 1s) during finite time intervals (64 or 128s). On the other hand, the TRN data cover the whole time with 1s time resolution for monitoring the background. They have 55 channel pulse-height histogram data.
Details of the WAM instrumentation are described in Yamaoka et al., 2009, PASJ 61, S35. The spectral cross-calibration with Swift/BAT and Konus/Wind is described in Sakamoto et al., 2011, PASJ 63, 215.
Data | Energy | Epoch | Time resolution | Time coverage |
BST | 4 channels | 2005 Aug. 22 - 2006 Mar. 20 | 1/32s (TH) | 128s (16s before and |
55 channels | 1s (PH) | 112s after the trigger) | ||
4 channels | 2006 Mar. 20 - present | 1/64s (TH) | 64s (8s before and | |
55 channels | 0.5s (PH) | 56s after the trigger) | ||
TRN | 55 channels | 2005 Aug. 22 - present | 1s (PH) | Always transferred to the |
telemetry every 1s |
Cleaned event files are not provided for the WAM data because the PHA to PI conversions and the event grade selection are not performed for the raw data. Therefore the WAM data extraction starts with the second FITS files in the hxd/event_uf directory. This directory contains three types of WAM FITS files: the BST event files (aeNNNNNNNNNhxd_y_bstzz_uf.evt.gz), the TRN event files (aeNNNNNNNNNhxd_y_wam_uf.evt.gz), and BSTID table files (aeNNNNNNNNNhxd_y_bstidt.fits.gz) where NNNNNNNNN is the Suzaku observation ID, y is the RPT file number which ranges from 0 to 9, and zz is the sequential number of the BST data.
For example:
ae903005010hxd_1_bst01_uf.evt.gz ae903005010hxd_1_bstidt.fits.gz ae903005010hxd_1_wam_uf.evt.gz ae903005010hxd_2_bstidt.fits.gz ae903005010hxd_2_wam_uf.evt.gz
The BSTID table files are temporal files for the time assignment in the standard pipeline processing, they are not used for the data analysis. The BST data have to be reprocessed because wrong times are sometimes assigned for the BST data in the standard pipeline process (about 10% of all BST data). In order to check whether the time assignment is correct or not the following command can be used:
fkeyprint infile=ae903005010hxd_1_bst01_uf.evt.gz keynam=TIMECORR
The TIMECORR keyword can have the value F or T. F means that the time assignment has failed, so reprocessing is required. The way to reprocess the BST data is explained in section 7.13.6. After reprocessing the BST data it should be checked that the TIMECORR keyword has changed from F into T.
There are currently (HEAsoft v6.10) seven tools available for the WAM data analysis (Table 7.5). Versions earlier than HEAsoft v6.9 should not be used for the WAM analysis.
Please note that the deadtime correction for TH light curves and TH spectra is not yet supported in hxdmkbstlc and hxdmkbstspec (Table 7.6). Correction tools are being developped by the WAM team.
Tool Name | Role |
hxdbsttime | Time assignment for the BST data |
hxdmkbstlc | Creation of a light curve (PH and TH data) from BST data |
hxdmkbstspec | Creation of an energy spectrum (PH and TH data) from BST data |
hxdwambstid | Creation of a BSTID table from the TRN data |
hxdwamtime | Time assignment for the TRN data |
hxdmkwamlc | Creation of a light curve (PH data) from TRN data |
hxdmkwamspec | Creation of an energy spectrum (PH data) from TRN data |
hxdbstjudge | Search for a burst in the light curve FITS |
WAM light curve FITS files can be produced with hxdmkbstlc for the BST PH and TH data and with hxdmkwamlc for the TRN data. After producing these files (.lc) you can proceed with the timing analysis using, e.g., the XRONOS package.
The TIME column in the FITS file is usually given in ASTETIME, i.e., time in seconds since 2000-01-01 00:00:00 (UTC). You can convert ASTETIME into UTC using the FTOOL aetimecalc, e.g.:
aetimecalc input=mission mission=1.8e8or with the date converter on the HEASARC web site
For the TRN (PH) data, the energy channels (min_channel and max_channel) have to be specified. The WAM energy channels range from 0 to 54, and are compressed from the original flash ADC channels (0 to 63 plus one overflow bit).
The approximate energy channels are calculated by:
Energy (keV) = ADC Channel x 511/15
Note that this equation depends on the gain of the detector, which varies with time and operation.
The PH light curves have to be deadtime corrected using the dt_cor option (dt_cor=yes). To create a light curve for the full WAM energy band select min_channel=2 and max_channel=54 (channels 0 and 1 [50keV] are affected by the low energy threshold and provide noisy light curves).
hxdmkwamlc input_name=ae903005010hxd_1_wam_uf.evt.gz \ outroot=ae903005010hxd_1 \ leapfile=CALDB min_channel=2 max_channel=54 dt_cor=yes
In order to obtain the BST TH light curve set the th_mode option to 1. Deadtime correction is not currently supported (dt_cor=no):
hxdmkbstlc input_name=ae903005010hxd_1_bst01_uf.evt.gz \ outroot=ae903005010hxd_1_bst01 \ tpu_board=-1 th_mode=1 dt_cor=no energy_mode=-1
In order to obtain the BST PH light curve set the th_mode option to 0 and specify the energy range with min_channel and max_channel:
hxdmkbstlc input_name=ae903005010hxd_1_bst01_uf.evt.gz \ outroot=ae903005010hxd_1_bst01 tpu_board=-1 th_mode=0 energy_mode=1 min_channel=2 max_channel=54 dt_cor=yes
In order to produce spectral FITS files (.pha) use hxdmkbstspec for the BST data and hxdmkwamspec for the TRN data, correct for detector deadtime using the dt_cor option (dt_cor=yes), and give the start time (time_min) and end time (time_max) for spectral integration in ASTETIME:
hxdmkbstspec input_name=ae903005010hxd_1_bst01_uf.evt.gz \ outroot=ae903005010hxd_1_bst01 tpu_board=-1 th_mode=0 \ time_min=276787164 time_max=276869264 dt_cor=yes
hxdmkwamspec input_name=ae903005010hxd_1_wam_uf.evt.gz \ outroot=ae903005010hxd_1 tpu_board=-1\ time_min=276787164 time_max=276869264 dt_cor=yes
Background spectra can be derived by 1) integrating a few 10-100 seconds before and after the bursts if the background level is almost constant or, in principle, 2) modeling of the background (not supported yet).
The response generator, wamrspgen, will not be made publicly available due to its complex structure. The WAM team will make response matrices for certain GRBs publicly available on the web site. If you want response matrices for other GRBs, please contact the WAM team via their e-mail adress (suzaku-wam@astro.isas.jaxa.jp).
You can then proceed with spectral fitting using, e.g., XSPEC:
XSPEC12>data 1:1 wam0_grb.pha (GRB spectrum) XSPEC12>backgrnd 1 wam0_bg.pha (Background spectrum) XSPEC12>response 1 wam0_grb.rsp (Response file)
Many GRBs are detected by more than one WAM detector. To constrain the spectral parameters more tightly, you can perform joint fitting of several WAM detectors, e.g., for two:
XSPEC12>data 2:2 wam1_grb.pha XSPEC12>backgrnd 2 wam1_bg.pha XSPEC12>response 2 wam1_grb.rsp
The current responses have systematic uncertainties at low energies (below 150keV). It is recommended to ignore channels in spectral fitting:
XSPEC12> ignore **-4
The upper energy channel limit depends on photon statistics. Note that there are typically calibration uncertainties of 20% in the absolute flux. For the calibration status please see Yamaoka et al., 2009, PASJ 61, S35 and Sakamoto et al., 2011, PASJ 63, 215.
Please note that the WAM data in the current data archive are not screened according to criteria such as SAA times and performance of calibration tasks. Figure 7.5 shows a typical one-day light curve in the keV range.
The high voltages are shut down during the SAA passage (about 10 times per day), so the light curve shows a zero value at these times. Also a gain check operation for each unit is performed during 10 minutes every day and the light curve shows about one quarter of the original count rate during this operation (at s in Figure 7.5). If the burst occured during and near the SAA and the gain operation, please be careful not to use data during these periods.
First list the HXD HK files in ASCII format in a file, hk.list. For example, hk.list may contain:
ae903005010_0.hxd.hk ae903005010_1.hxd.hk
If there is only one HK file in the data archive it can be provided directly with hklist_name=ae903005010_0.hxd.hk.
For the TRN data:
hxdwamtime read_iomode=overwrite \ input_name=ae903005010hxd_1_wam_uf.evt \ leapfile=CALDB hklist_name=@hk.list \ tim_filename=ae903005010.tim
For the BST data:
hxdbsttime read_iomode=overwrite \ input_name=ae903005010hxd_1_bst01_uf.evt \ hklist_name=@hk.list leapfile=CALDB \ tim_filename=ae903005010.tim bstidt_fname=CALDB
0) The primary WAM web page:
http://www.astro.isas.jaxa.jp/suzaku/HXD-WAM/WAM-GRB
1) The WAM GRB (Gamma-Ray Burst) table:
Triggered events
http://www.astro.isas.jaxa.jp/suzaku/HXD-WAM/WAM-GRB/grb/trig/grb_table.html
Un-triggered events
http://www.astro.isas.jaxa.jp/suzaku/HXD-WAM/WAM-GRB/grb/untrig/grb_table.html
2) The WAM SGR (Soft Gamma Repeater) table:
Triggered events
http://www.astro.isas.jaxa.jp/suzaku/HXD-WAM/WAM-GRB/sgr/trig/sgr_table.html
Un-triggered events
http://www.astro.isas.jaxa.jp/suzaku/HXD-WAM/WAM-GRB/sgr/untrig/sgr_table.html
3) The WAM solar flare table:
Triggered events
http://www.astro.isas.jaxa.jp/suzaku/HXD-WAM/WAM-GRB/solar/trig/solar_table.html
Un-triggered events
http://www.astro.isas.jaxa.jp/suzaku/HXD-WAM/WAM-GRB/solar/untrig/solar_table.html
4) The WAM event candidate list:
http://www.astro.isas.jaxa.jp/suzaku/HXD-WAM/WAM-GRB/list/wam_eventlist.html
If you have any questions and comments about the WAM data analysis and software, please don't hesitate to send an e-mail to:
suzaku-wam@astro.isas.jaxa.jp