/ ciao / why / ccmode.html

Continuous Clocking Mode

Calibration | Data Caveats | Correcting Event Times | Reprocessing the Data

The ACIS continuous clocking (CC) mode is provided to allow 2.85 msec timing at the expense of one dimension of spatial resolution. This mode creates 1 pixel x 1024 pixel images, each with an integration time of 2.85 msec. Details of the spatial distribution in the columns are lost, other than the fact that the event originated in the sky along the line determined by the length of the column. For more details, see the Continuous Clocking Mode section of the POG.

Calibration

The computation of PHA, ENERGY and PI for CC mode observations is performed in the same way as these computations for timed exposure (TE) mode observations and using the TE mode gain, CTI and time-dependent gain calibration products. The pulse-height information may be somewhat inaccurate because

The gain for CC mode observations may be different than the gain for TE mode observations.
The CTI and time-dependent gain adjustments for CC mode observations may be different than the CTI and time-dependent gain adjustments for TE mode observations.
Since some assumption has to be made about the CHIPY coordinate of an event, the CTI and time-dependent gain adjustments may not be applied correctly.
Occasionally, the CC mode bias maps are corrupted by charge blooms produced by cosmic rays. The pulse heights of events in the affected columns will be systematically low.

However, it is still recommended that you apply the CTI and time-dependent gain adjustments to the data. There was a fix to acis_process_events in version DS 7.6.3 (12 August 2005) of the standard data processing pipeline, which enables the CTI adjustment to be applied to CC-mode data.

Data Caveats

Good time intervals (flt1.fits files)

After the times-of-arrival are calculated by acis_process_events, there is no easy way for users to adjust the GTIs to account for this shift in the source location.

When the flt1.fits file - produced by the pipeline - is applied in data analysis, those times are for the original source location. This means there will be some loss of events around any dropped exposures; how many events are lost depends on how much time is shifted, e.g. how large of an adjustment was applied to the RA_TARG and DEC_TARG header keywords. For most observations, this shift will be small.

Mask files

There is a known problem with CC-mode mask files that were produced with a software version lower than DS 7.3.0 (before about 24 June 2004). Be sure to read the Caveats about ACIS Pipeline-Processed Mask Files to see if this issue affects your data.

TIMEDEL keyword

The value of the keyword TIMEDEL in some very old ACIS continuous-clocking mode event data files is incorrectly set to 1.4592 s instead of 0.00285 s. While this does not represent a problem if the pipeline-produced files are used for timing analyses, it is a problem if an affected event data file is reprocessed using acis_process_events because the values of the TIMEs in the output file will be incorrect. The problem, which affects data processed with DS 7.6.0 (June 2005) to DS 7.6.7 was fixed in DS 7.6.8 (13 June 2006).

To see if your data file is affected, check the ASCDSVER (software version) and/or TIMEDEL header keywords in the evt1.fits file:

unix% dmkeypar acis_evt1.fits ASCDSVER echo+
7.6.2

unix% dmkeypar acis_evt1.fits TIMEDEL echo+
1.4592

This file has the incorrect TIMEDEL value, so we use dmhedit to update it:

unix% dmhedit infile=acis_evt1.fits filelist="" op=add key=TIMEDEL value=0.00285 unit=s

unix% dmkeypar acis_evt1.fits TIMEDEL echo+
0.00285

Accuracy of Source Coordinates

It is important to verify that the coordinates of the source are precise to less than 0.5 arcsec (i.e. one pixel). The source coordinates are used to determine the absolute times of arrival; if they are imprecise, the output times of arrival will also be inaccurate.

The coordinates that should be used are the best-known right ascension (RA_TARG) and declination (DEC_TARG) coordinates for the source:

unix% dmlist acisf00170_001N003_evt1.fits header | egrep '(RA|DEC)_TARG'
0057 RA_TARG                     83.6333330              Real8        Observer's specified target RA
0058 DEC_TARG                    22.0144720              Real8        Observer's specified target Dec

These coordinates in this file have the correct level of precision for the time-of-arrival correction.

If the accuracy of the coordinates in the header needs to be improved, here are some suggestions on how to determine the values:

use previously-published source coordinate values.
if the coordinates are not well known, try obtaining them from a Chandra observation of the source which was taken in TE mode.
if neither of the above methods are available, it may be possible to use two, separate continuous-clocking mode observations to find the source coordinates, provided that the observations did not have the same roll angle.

It is not possible to fix the coordinates in the dataset if the position is not known from some other dataset or publication (i.e. you cannot determine accurate source coordinates from the dataset you are attempting to correct).

For reference, the conversion between arcsec and degrees is:

0.5 arcsec -> 0.00014 deg (in declination)
              0.00014 / cos(DEC_TARG) deg (in right ascension)

Once the new source coordinates are determined, modify the file header with dmhedit:

unix% dmhedit infile=acisf00170_001N003_evt1.fits filelist="" operation=add key=RA_TARG value='newvalue'

Note that the uncertainties in the times of arrival include the uncertainties in the coordinates RA_TARG and DEC_TARG, the PSF, and the aspect reconstruction. If RA_TARG and DEC_TARG are accurate to much less than a pixel, then the times of arrival should be accurate to about 4 ms for most observations (i.e. those without any unusual aspect problems).

Correcting Event Times

Since 15 June 2005 (standard data processing version DS 7.6), the TIMEs in ACIS CC mode event data files are the times of arrival at the detector. For observations processed using an earlier version of the software, the event TIMEs are the read-out times, which include the effects of (1) the dither, (2) the motion of the science instrument module and (3) a systematic offset associated with the read-out time. Depending on the location of the source on the detector, the read-out time is in the range from 3-6 s. Data processed with an older version of the software should be reprocessed before performing timing analyses; this may be done by running the chandra_repro script or by following the Reprocessing Data to Create a New Level=2 Event File thread.

Before beginning any timing analysis, also complete the Apply Barycenter Correction thread to correct for the difference in photon arrival times as the Earth and Chandra move around the Sun.

Reprocessing the Data

The first "good" version of the processing software for CC-mode observations is DS 7.6.3 (12 August 2005). To see which version of the software was used to process your data:

unix% dmkeypar acis_evt2.fits ASCDSVER echo+
R4CU5UPD11.1

Note that the version naming convention changed after version R4CU5UPD14 to the "DS" system, starting with DS 6.0.0. Therefore, this data was processed with a version of the software older than DS 7.6.3 and should be reprocessed in CIAO before being analyzed.

If your file was processed with DS 7.6.0 or higher, be sure to read the data caveat about the TIMEDEL keyword.

Because CC mode is a special case, there are some data analysis caveats to keep in mind during the reprocessing.

Using TGCat, the Chandra Gratings Catalog and Archive

If you are analyzing archival grating data, the following steps can be avoided by using the gratings catalog, TGCat, and downloading the pre-computed spectral products (i.e., spectra and response files).

To easily find CC-mode observations in TGCat:

Query → Arbitrary Extraction Column
<drop-down menu> → datamode like CC%
("%" is the wildcard character)
or <drop-down menu> → readmode = CONTINUOUS

Then add "readmode" and "datamode" columns to the resulting table using the "View" menu.

acis_process_events

The eventdef parameter, which specifies the names and data types of the columns in the output event data file, needs to be set to one of the predefined strings for CC mode: cclev1 (faint CC mode) or ccgrdlev1 (graded CC mode).

If you are unsure of the event mode of your observation, the information can be found in the READMODE and DATAMODE values stored in the file header:
```
unix% dmkeypar acis_evt1.fits READMODE echo+
CONTINUOUS

unix% dmkeypar acis_evt1.fits DATAMODE echo+
CC33_FAINT
```
This is a faint CC mode observation, so the proper eventdef parameter is "cclev1".
Apply the time-dependent gain and CTI corrections:
```
unix% pset acis_process_events apply_tgain=yes
unix% pset acis_process_events apply_cti=yes    
```
The ACIS calibration team has advised that it is useful to apply these corrections, even though the calibration is derived from TE-mode observations.

destreak

destreak should be run on CC-mode data taken on ACIS-S4, regardless of whether the source is bright and continuum dominated.

Since all CHIPY information is lost, the streaks off the spectral trace will contaminate the spectrum. Therefore, there is contribution from a much larger area. In CC-mode data, streaks have been known to cause heavy corruption. Running destreak with the default parameters significantly improves the data.

Further details are available in the Destreaking ACIS Data why topic.

tg_create_mask

The output of tg_create_mask is a FITS region file which enumerates the grating parts and specifies the region shape, size, and orientation in sky pixel-plane coordinates. ACIS/HETG CC-mode data is processed with the grating_obs parameter set to MEG, but a rotation angle of zero. Since there is no spatial resolution across the dispersion, the HEG and MEG arms are merged together; they are resolved later by tg_resolve_events, if possible.

tg_resolve_events

The OSIP file defines the order-sorting region based on the CCD calibrations of gain, CTI correction, and spectral redistribution. There are two options in tg_resolve_events for determining the order sorting: osipfile=CALDB (the default) or setting osipfile=none and using the osort_lo/ osort_hi parameters instead.

If CC-mode gain/CTI corrections are poor, then orders can be clipped and the flux will be low with osipfile=CALDB. For a "flat" osip (osipfile=none), we can enlarge the pulse-height (or ENERGY) region, but at the expense of increased inter-order background, which is more severe at short wavelengths (<~1.8A in HEG, <~3A in MEG) due to the zeroth order scattering.

Which option you take depends upon the analysis. The general recommendation is to use the OSIP file (i.e. osipfile=CALDB), but then to compare the plus and minus HEG and MEG spectra to ensure the fluxes are consistent. For an ideal extraction and calibration, flux from positive and negative orders and from HEG and MEG should all agree. When they don't, it requires some careful diagnosis to determine whether you have clipped counts during order-sorting and reduced one spectrum's apparent flux, or if you instead have excess background in the other spectrum.

For example, for nominal pointing, the neon edge near 14.2A may be good for MEG order -1 (back-illuminated CCD), but in the positive side, it will fall on a front-illuminated CCD with half the sensitivity, and become background dominated for short exposures and/or high absorption; apparent flux will rise here, but due to background, not source counts (and for this case, neither osip on nor off will help). If there are discontinuities in flux, then you might try osip=none to see if it is due to gain inaccuracies across CCD boundaries.

/ ciao / why / ccmode.html