Caveat: ACIS Continuous Clocking mode data
- CC mode "Why" topic
- CC mode section of the Proposers Guide
- Memo describing the Calibration Properties of CHANDRA HETG Spectra Observed in CC-Mode
- Reprocessing Data to Create a New Level=2 Event File
- Check Accuracy of Source Coordinates
In ACIS Continuous Clocking (CC) mode spatial information in the CHIPY direction is sacrificed in order to obtain a faster readout. This observing strategy can be used to lessen the effects of pileup; note though that for bright enough sources the effects of pileup may be significant even in this mode. The lack of spatial information in the CHIPY direction complicates the analysis of CC mode data since the data from the entire chip is collapsed into a single pixel width region on the sky.
This caveat applies to spectral analysis of ACIS data collected without the gratings inserted. There are additional things to consider when working with the dispersed spectra compared to the CCD spectra. Users working with grating data should consult the Calibration Properties of CHANDRA HETG Spectra Observed in CC-Mode memo.
The following topics are covered in this caveat:
- Why users should only use box shaped regions for extracting the source and background spectra.
- How to set the specextract parameter to ensure that the appropriate response files (ARF and RMF) are created.
- Why it is important to have an accurate target source location (RA_TARG and DEC_TARG), how it affects the calibrations, and how to update the values.
When displaying CC mode data in ds9, the image looks like several, single-pixel wide line segments, possibly at near-right angles to each other, as shown below. This is due to how the SKY coordinates are computed. The assumed target location, RA_TARG,DEC_TARG values (header keywords) are mapped through the aspect solution to determine where that location is on the detector as a function of time: CCD_ID, CHIPX, CHIPY. This CHIPY value is used for all events, detected at that time, when computing their sky location which is discussed in more detail below.
The result is a collection of line segments; one will pass through RA_TARG,DEC_TARG as shown here for ObsID 11233.
Despite being visualized as line segments, the data in CC mode are collected from the entire chip. Due to dither, this makes computing the absolute area of any extraction region impossible.
Luckily, the absolute area is not generally needed. All that is needed is to get the correct ratio of source region area to background region area. The easiest way to do this correctly is to use box shaped regions, rotated to match the data, and the source and background boxes must have equal heights. Trying to use circle shaped regions will result in the areas being incorrectly computed and will result in an incorrect estimate of the background. Technically, ellipses and polygons could be used however, they are more difficult to construct in such a way as to ensure the ratio of the areas is correct.
Two different extraction regions are shown below.
Technically other shapes can also be used for extraction regions. However, they need to be constructed very carefully. For example ellipses may be used but the center of the ellipse must be on the line of data and the rotation angle must be exactly correct to match the orientation of the line. With box regions the angle can be slightly off (just must be the same) and the box need not be centered exactly on the line.
The effect of the error in the area can be seen in the background subtracted spectrum. Below is the background subtracted spectrum computed from the circular region (red) and box region (blue):
In this example, the background from the circular regions — especially at high energies — has been underestimated.
It is important to remember that data from all 1024 rows of the CCD are collapsed into the single pixel line in sky coordinates. That means any source extraction region will contain ~1000 times the background counts, for each sky pixel , compared to a similar observation done in TIMED mode. That is, as the source region width increases, the source counts will only slightly increase but the background counts will increase significantly faster. This can be seen in the following plot where the extraction box width is increased from 4 to 9 pixels.
Given that CC mode is most often used for bright sources, the increased background may be negligible compared to the source flux, at least over some energy ranges. Users will need to judge for themselves how critical the background is for their specific analysis.
Given the way CC works, the specextract parameters need to be set as shown:
unix% pset specextract mskfile=NONE unix% pset specextract weight=no unix% pset specextract weight_rmf=no unix% pset specextract bkgresp=no unix% pset specextract correctpsf=no
Each is discussed below:
mskfile=NONE: The detector mask for CC mode contains a gap at CHIPY=511:512 which is an artifact of how the data are readout. However, how it is used by the ARF tools (mkarf) is not correct. The gap is actually temporal, not spatial. If the mask file is used, it may lead to an artificial decrease in the detector sensitivity. The effect varies with each source and each observation. It may be negligible or may be a significant fraction of the ARF (potentially up to about 50%).
weight=no and weight_rmf=no: The responses for a source in CC mode should be made assuming that the source is a point source. Therefore, the ARF and RMF should not be weighted as one would do for an extended source.
bkgresp=no: It is not currently possible to create response files that are applicable for the background region. The assumption users must make is that the source ARF and RMF are either the same as for the background or that the background is dominated by instrumental effects and can be subtracted.
correctpsf=no: The PSF correction requires a 2D spatial image that covers the source region to compute the PSF correction. Since no valid 2D image exists for CC mode, the PSF correction cannot be estimated. Users should assume 100% of the PSF is contained in the source region. Given that the entire CHIPY is included in the region this is an acceptable assumption, when the region is sufficiently wide.
The remaining parameters can be then set as desired.
Target (TARG) location
The location of the target source is used to estimate the CHIPY location as a function of time. Specifically, the RA_TARG and DEC_TARG header keywords values in the event file are folded through the aspect solution to estimate the chip coordinates for the target source location. The event data together with this estimate for CHIPY is then used for all other calibrations including: CTI corrections, TIME corrections, and spatial coordinate transforms (which as discussed above leads to the line-segments when the data are visualized in ds9).
The CHIPY value computed this way may in fact be off the detector (a value less than 0.5 or greater than 1024.5). There are observations where the TARG location was chosen to be very near the edge of the detector such that for some period of time it may dither off the edge and in extreme cases can even be entirely off the detector.
It is therefore important that the TARG keywords provide an accurate location. The TARG values in the event file header retrieved from the Chandra archive are the values entered by the observer when the proposal was submitted. There is no validation or verification that the values provided are accurate beyond the level to check for proposal conflicts. Failure to provide an accurate TARG location can result in significant systematic offsets in the calibrations.
In the figure below, the spectrum is plotted where the TARG location was modified to locate the target source location near the bottom of the chip (red histogram) and then again when the target source location near the top of the chip (blue histogram). The amount of CTI correction varies from the bottom of the chip to the top. This causes the spectrum to shift from, in this example, under CTI corrected to being over CTI corrected which can be interpreted as a gain shift.
This kind of shift in energy may then affect estimates of temperature or slope, or any other modeled parameters.
Difference in the TARG location will also affect the response files (ARF and RMF) as is shown in the next figure.
Inaccuracies in the TARG location will also affect the RMF. Beyond the apparent gain shift already seen above, CTI causes the spectral resolution to be worse the further away from the readout (so worse at the top of the chip). This may for example make spectral lines appear to be too wide or too narrow compared to the RMF.
Users should therefore make every effort to ensure that the TARG location is as accurate as possible.
Update TARG location
The easiest way to update the TARG location is to run acis_process_events on the level 1 event file using an obsfile with the updated source location. The obsfile is an ordinary parameter file that can be created and seeded with values from the existing event file header using dmmakepar:
unix% dmmakepar "acisf11233_000N002_evt1.fits[events]" hdr.par clob+ unix% pset hdr.par ra_targ=258.4420182380707 unix% pset hdr.par dec_targ=-38.22433256504579
After the parameter file is created, the ra_targ and dec_targ values are updated using pset. The values used in this example are purely for illustrative purposes. How a user determines the true source position is beyond the scope of this caveat.
Next the acis_process_events parameters are set. The level 1 event file must be used as the level 2 does not contain the information needed to recalibrate the dataset. Users unfamiliar with this tool and it's parameters should consult the step-by-step Reprocessing Data to Create a New Level=2 Event File thread. The main difference here is that the hdr.par file is input to the obsfile parameter.
unix% punlearn acis_process_events unix% pset acis_process_events infile=acisf11233_000N002_evt1.fits \ acaofffile=pcadf381242363N002_asol1.fits \ outfile=new_targ_evt1.fits \ obsfile=hdr.par \ badpix=acisf11233_000N002_bpix1.fits \ mtlfile=acisf11233_000N002_mtl1.fits \ pix_adj=NONE subpixfile=NONE \ eventdef=")cclev1" \ clobber=yes unix% acis_process_events Input event file or stack (acisf11233_000N002_evt1.fits): Output event file name (new_targ_evt1.fits): aspect offset file ( NONE | none | <filename>) (pcadf381242363N002_asol1.fits): # acis_process_events (CIAO): WARNING: The ra_targ, dec_targ, or roll_nom specified by hdr.par does not match the values in the event file- using the obs.par values. ...
The WARNING above is expected since this is exactly what was intended. The values in the hdr.par take precedence over the values in the event file header. Users may see several other warnings such as
# acis_process_events (CIAO): The following error occurred 5 times: dsAPEPULSEHEIGHTERR -- WARNING: pulse height is less than split threshold when performing serial CTI adjustment. # acis_process_events (CIAO): dsAPETSTARTERR -- WARNING: The input event times start at 381241248.260579 but the TSTART specified in hdr.par is 381241252.753240. # acis_process_events (CIAO): The following error occurred 5000 times: dsAPETARGERR -- WARNING: the RA_TARG and DEC_TARG coordinate fall off of the CCD during the observation. Times may be bad.
These are all acceptable messages. In particular the last message may occur when the TARG location is near the edge of, or even off of, the detector. If that occurs then the data are calibrated using the closest on-chip location.
Finally, to create the Level 2 event file, it must be filtered to accept only good status values, the standard ASCA grades, and to remove times outside the good time intervals. Again, the details of which can be found in the Reprocessing Data to Create a New Level=2 Event File thread.
unix% dmcopy "new_targ_evt1.fits[status=0,grade=0,2:4,6]" tmp.evt unix% dmcopy "tmp.evt[@acisf11233_000N002_flt1.fits]" new_targ_evt2.fits clob+
The file new_targ_evt2.fits can now be used for analysis.
It is important to keep in mind that all events are corrected to the TARG location's CHIPY value. Background events within the source region and events on all other CCDs use the same CHIPY value as a function of time. So while correcting the TARG location can improve the calibrations of the source events, all the other events whose true CHIPY value differs from the TARG's CHIPY will still have unknown systematic errors in their energies and times.
If, for example, there are multiple sources in the field, users should create separate Level 2 event files for each source using each sources' target location to get the best calibrations for each.