[Date Prev][Date Next][Thread Prev][Thread Next][Search]
[Main Index]
[Thread Index]
[HEASARC Archives]
As promised, following Nagase's latest short-term timeline, here is the
Dear ASCA PIs and archival researchers:
This rather long message contains important information about three ASCA
data reduction/analysis issues, namely:
I. A problem with the dark-frame error correction
II. Release of new GIS Crab Nebula spectra data
III. Warning about GIS background files in the Calibration Database
The same information is also available via the ASCA GOF WWW homepage,
the URL of which is:
http://heasarc.gsfc.nasa.gov/docs/asca/ascagof.html
Please look under News Updates for the items "GIS News" and "SIS News".
I. A PROBLEM WITH THE DARK-FRAME ERROR CORRECTION
Introduction
Recently, it was discovered that the FAINT FTOOL occasionally fails to
carry out the DFE (Dark Frame Error) correction. The origin of the
problem was located in the part of the source code which reads the DFE
filename.
This problem may impact data analysis for FAINT -> BRIGHT2 converted
data, i.e., those data for which both the Echo and DFE corrections are
carried out. It does not affect the analysis of BRIGHT mode data. Please
refer to Otani et al. 1994 in ASCA Newsletter vol.2 for details of Echo
and DFE corrections. For convenience, the following box contains a short
description of the three SIS imaging modes (FAINT, BRIGHT and BRIGHT2)
as well as DFE. You can skip over it if you're already familiar with the
material. A description of the problem - with solutions - is next.
------------------------------------------------------------------------
| FAINT: The energy of each event in a FAINT mode datafile, is |
| characterised by a 3 x 3 pixel grid centered on the brightest pixel |
| of the event. As such, FAINT mode data offer the most complete |
| description of events and the potential for realizing the maximum |
| spectral resolution. FAINT data have 4096 channels. |
| |
| BRIGHT: Data taken in FAINT mode occupy a lot of telemetry. In fact, |
| it is often the case that FAINT mode cannot be telemetered without |
| saturation. BRIGHT mode is derived from FAINT mode and is more |
| compact. Instead of using nine numbers to characterize each event, |
| BRIGHT mode uses two: a single PHA value and a grade to describe the |
| shape of the event. In addition, BRIGHT mode data have 2048 channels |
| rather than 4096. |
| |
| BRIGHT2: In a sense, all SIS imaging data start off as FAINT mode, |
| and whether they are telemetered as FAINT or BRIGHT depends on |
| telemetry constraints. However, in order to perform conventional |
| spectral analysis, each event must have a single PHA value. This |
| is already the case for BRIGHT mode data, but FAINT mode data have |
| to be converted somehow. Users have two options. They may either use |
| BRIGHT data which have been converted from FAINT data using the |
| identical algorithm as used on the spacecraft, or they may use |
| BRIGHT2 data which have been converted from FAINT data in a |
| different way. Both conversions are performed by the FAINT FTOOL, |
| and are part of the current version of standard processing. There |
| are advantages and disadvantages to both kinds. If FAINT data are |
| converted to BRIGHT, they can be combined with true BRIGHT mode data |
| (i.e., data originally telemetered in BRIGHT mode). For a typical |
| observation done in a mixture of FAINT and BRIGHT modes this |
| provides the largest homogeneous dataset to work with. The |
| conversion to BRIGHT2 mode, on the other hand, makes use of |
| information in the original FAINT data (and not present in BRIGHT |
| data) to perform two small corrections: the event-by-event echo |
| correction and the DFE correction. The resulting BRIGHT2 data have a |
| more accurate energy scale but cannot be combined with "true" BRIGHT |
| data because they require different responses. BRIGHT2 data have |
| 4096 channels. |
| |
| DFE: The Dark Frame is the "zero-level" of the energy scale with |
| respect to which PHA values are measured. The Dark Frame Error (DFE) |
| is the offset in this level. It is variable: during satellite night |
| it is typically ~3 ADU, corresponding to ~10 eV, but in daytime it |
| can rise to ~20 eV. For FAINT mode datafiles, the FTOOL FAINTDFE |
| calculates the DFE which is then used by the FAINT FTOOL in the |
| conversion from FAINT mode to BRIGHT2 mode. Typically, the DFE is |
| much smaller than the statistical uncertainties in the data. Users |
| can therefore perform their SIS analyses entirely on BRIGHT mode |
| data without loss of accuracy. However, once you have derived a |
| result by fitting a BRIGHT spectrum, it is prudent to make a |
| corresponding spectrum from BRIGHT2 data to test whether your result |
| is sensitive to DFE. |
| |
------------------------------------------------------------------------
The Problem
In the FAINT FTOOL, the parameter "dfefile" is used either for constant
DFE values or for the name of a dfefile. The program was supposed to
recognize the DFE values as being REAL variables and dfefile name as a
CHARACTER string, but it turned out that in some cases the dfefile name
is read, unexpectedly, as a REAL value (0.0 or -1.0, as far as we are
aware). Consequently, in some cases, constant DFE values (0.0 or -1.0)
are incorrectly used instead of reading in the dfefile. This behaviour
has been found to depend on the system architecture (i.e., the
compiler).
In fact, it appears that the only cases for which the dfefile name is
always correctly recognized by the FAINT FTOOL are:
SunOS is used and the first character of the dfefile name is not a
"/" (unfortunately not the case when FAINT is invoked from XSELECT)
VMS is used and FAINT is invoked from XSELECT.
The DFE file name is NOT recognized and the DFE correction fails ,
for Unix (SunOS, Ultrix, Alpha/OSF) when the first character is "/".
Unfortunately, the XSELECT "faint" command specifies the dfefile name
with the absolute path ("/" in the beginning). So DFE correction
carried out using the XSELECT "faint" command is incorrect.
The DFE file name may or may not be recognized for VMS, Ultrix and
Alpha/OSF. This is not simply predictable. For example, "a.dfe" is
recognized, but "ft930912_1638_1810S003701H.dfe" is not recognized.
Versions of FAINT up to 3.3b have this problem (the latest public
version is 2.8a, corresponding to the FTOOLS version 3.2). The problem
is fixed in the next version of FAINT (version 3.3e; FTOOLS version
3.3).
Impact of this problem
1) PV/archival data
The PV/archival data are all processed under SunOS and the dfefile is
specified without a "/". Consequently, the DFE correction in the
PV/archival data is correct.
2) GO data processed at GSFC
In the middle of AO2, DFE correction was applied to GO data processed at
GSFC. If you have *12[HM].fits files in your package, these are
FAINT --> BRIGHT2 converted data which were supposed to be DFE and echo
corrected. To determine whether you have incorrect BRIGHT2 data:
Please find the ad********.joblog file, located in the 'product'
directory (******** is the sequential number). In the beginning of
the log, you will see:
AO:A4.8.1:LO:Start at Thu Nov 3 11:05:04 EST 1994
AO:A4.8.1:LO:Hostname addev
AO:A4.8.1:LO:Processing directory /data16/ao/seq_proc/42010000.001
AO:A4.8.1:LO:Process num = 6126
AO:A4.8.1:LO:Process script = ao4.8.3.ksh
Please check the process script name ("ao4.8.3.ksh" above), and it
will tell you the script version (4.8.3 in this case). The FAINT -->
BRIGHT2 conversion is made in the script version 4.6 and later. If
your script version is earlier, you will not have the BRIGHT2 data.
The date of the processing is on the first line. The data processed
in 1994 are all done under ultrix, so the DFE correction will be
incorrect.
If your data were processed in 1995, please check the Hostname.
"addev" and "astrod" are both Ultrix machines. If your data is
processed on either of the Ultrix machines, then the DFE correction
will be incorrect.
3) GO data analysis
If you have used the 'faint' command in XSELECT, then your DFE
correction will probably be incorrect. If you ran the FAINT FTOOL by
itself under SunOS, then the DFE correction will be correct unless you
specified the absolute path of the dfefile. If you ran FAINT under VMS,
Ultrix or Alpha/OSF, then the DFE correction may or may not be correct.
However, please note that if the dfefile name started with "ft*" then
the DFE correction will certainly be wrong.
Solution
In order to re-do the DFE correction, please install the new FTOOLS
which will be released very soon. The easiest way is to apply the DFE
correction is to run "ascascreen", choosing to analyse the FAINT data.
Ascascreen is a Perl script which is included in the FTOOLS package, and
automatically creates a command macro to run XSELECT.
If you prefer to work by hand from within XSELECT itself, do:
xsel:ASCA > set datadir whatever
xsel:ASCA > set inst sis0
xsel:ASCA-SIS0 > set datamode faint
xsel:ASCA-SIS0-FAINT > make obscat
xsel:ASCA-SIS0-FAINT > choose 1-**
xsel:ASCA-SIS0-FAINT > faint bright=b2 dfefile=MAKE echo=-99
maxgrade=4 split=40
Then :
xsel:ASCA-SIS0-FAINT > save faint
to save all the files.
II. RELEASE OF NEW GIS CRAB NEBULA SPECTRAL DATA
Soon after the launch of ASCA, the GIS/XRT was calibrated by observing
the Crab Nebula with many different observational modes and pointings.
However, the exposure time for each mode/pointing was relatively short
(several hundreds of seconds). The GIS and XRT responses thus determined
are good enough in most cases. It was soon realized, however, that
bright source data with moderate exposure times (about a day) might have
much better statistics than the Crab calibration data. Further, longer
Crab observations were therefore deemed necessary.
The Crab Nebula was observed again on 1994 September 27 for about 60
ksec and on October 4 for 40 ksec, and energy spectra with very high
statistics were obtained. You can obtain the results of model
fitting (postscript files) with the current response functions via
anonymous FTP at olegacy.gsfc.nasa.gov in the files:
asca/gis_information/s2_0995_gsfc.ps for GIS2
asca/gis_information/s3_0989_gsfc.ps for GIS3
Alternatively, you can view/obtain the files through the ASCA GOF WWW
homepage, the URL of which is:
http://heasarc.gsfc.nasa.gov/docs/asca/ascagof.html
Look under News Updates for "GIS News".
The plots reveal a deviation from a power-law function above 5 keV,
indicating the current limit of the GIS/XRT response. You can verify
the fitting results yourself by obtaining the spectra (s2_0995.spec &
s3_0989.spec) and ARFs (s2r6_05.arf & s3r6_05.arf) from the same FTP
directory on olegacy. The appropriate RMFs are the standard ones in the
calibration database and can be found in their usual place: via
anonymous FTP at legacy.gsfc.nasa.gov in the directory:
caldb/data/asca/gis/cpf/94apr20
The response has not been updated yet, and the deviation is not solved
at the time of writing this document (January 1995). The GIS/XRT team is
diligently working to improve the response, and the new response
functions will be released soon.
III. WARNING ABOUT THE GIS BACKGROUND FILES
The ASCA GOF released GIS background files created by summing several
GIS blank sky observations taken during the ASCA performance
verification phase. These files are available from the
legacy.gsfc.nasa.gov anonymous FTP account in the directory:
caldb/data/asca/gis/bcf/bgd.
Recently, Y. Ueda and other GIS team members have pointed out the
effects of moderately bright point sources in the blank sky fields. They
found point sources in these blank fields which are not completely
averaged out by the summation of many fields.
The DET XY positions of the three most significant point sources are the
following :
GIS2 GIS3
(1) (113, 118) (120, 118)
(2) (122, 142) (128, 141)
(3) ( 98, 142) (104, 143)
We recommend that Guest Observers take extra care when using background
data near these positions. In particular, the sources (1) and (2) are
NGC6552, which has a very strong iron emission line (Fukazawa et al.
1994, PASJ 46, L141; Reynolds et al. MNRAS, 268, L55). Consequently,
background spectra made from these regions will show an iron emission
line, and this could affect background subtraction.
The ASCA GOF is planning to make new background files by removing
apparent point sources. These new files will be accompanied by a "mask
file" which will describe the regions excluded and be used to calculate
the correct exposure.
In addition, we have noticed that the background files BGD under
caldb/data/asca/gis/bcf/bgd/94may include data taken in March 1994, when
an onboard computer error caused the GIS3 PHA spectra to be quantized to
128 ch (5, 13, 21, ,, 1021ch) rather than the original 1024 channel
(0-1023ch).
These GIS3 data should not have been included. However, the effect of
the bad data on the actual background subtraction is not very
significant because:
a) the spectrum is "smoothed" using random numbers when converted to
*PI* from *PHA*, and
b) the bad data comprise just 7 per cent of the total.
The 1994 March bad data will be excluded when we make the new background
files.
Ken Ebisawa & Charles Day, ASCA GOF
Please send comments and questions:
in English to ascahelp@athena.gsfc.nasa.gov
in Japanese to ebisawa@bluejay.gsfc.nasa.gov