Caveat: ACIS Continuous Clocking mode data

Related Links

• 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

Introduction

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.

Extraction Regions

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.

Sky image for ObsId 11233

[Version: full-size]

Sky image for ObsId 11233

In CC mode, the sky coordinates are collapsed into line segments, one for each CCD. This image shows ACIS-235678. On the -I array, I2 and I3 are rotated approximately 90 degress relative to the -S array. The two back side illuminated chips S1 and S3 (S3 highlighted in blue) are the two brighter line segments on the -S array. The arrow points to the bright point-like source on ACIS-S3.

The image has been smoothly slightly for display purposes with a 3x3 boxcar.

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.

Rotated Box Extraction Regions

[Version: full-size]

Rotated Box Extraction Regions

Same data as before zoomed in on the target location. Shown are two rectangular box regions: one each for the source (solid line) and background (dashed line). CIAO makes no special effort to recognize CC mode; the absolute values for the area it computes will be incorrect.

To get the correct area, specifically, the correct ratio of the source area to the background area, users should use a box regions. Both source and background must be rotated the same to match the data on the sky (will be approximately ROLL_PNT±90 degrees), and the source region and background boxes must have the same height. The area of the source and background individually are still incorrect; however, the ratio of the two, which is what is used for background normalization, is correct.

In this case dmextract will compute the area equal to w_srch_src and w_bkgh_bkg, where w is the width of box and h is the height for the source and background boxes, respectively.

h is not known; it will be at least 1024 pixels but then will be increased due to the motion of the telescope dither and SIM drift by some indeterminable amount. Even though h is not known, it is the ratio of source area to background area that is important. Since the source and background have the same h it cancels out in the ratio.

The background scaling factor then is just w_src/w_bkg, which is correct.

Circular Extraction Regions

[Version: full-size]

Circular Extraction Regions

Similar to before but now using cicular regions.

With circular regions, dmextract will compute the area of the source and background as πr²_src and πr²_bkg ; where r_src and r_bkg are the radii of the source and background circles, respectively. The true area is something like 2rh where r is the radius and h is the height of the entire CCD as before. When the ratio of the areas is compute it will be be r²_src/r²_bkg; which is incorrect. The ratio should just be the ratio of the radii: r_src/r_bkg.

Note: If the data did not pass through the center of the circle then the radius would not be useful. The correct area is the length of the line segment the region encloses.

In general the areas are difficult to manually correct for this type of error. Users should use box regions to avoid having to try to manually correct this kind of error.

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):

Background Subtraction with circle and box regions

[Version: full-size]

Background Subtraction with circle and box regions

This figure shows the background subtracted spectrum obtained from the circular (red curve) and the box (black curve) regions. It is clear that at high energies, above about 5.0keV, the background subtraction using the circular regions is underestimating the background. Similarly there is an underestimate at very low energies.

The spectrum above about 9keV is typically dominated by instrumental background as the effective area falls off rapidly at high energies. The error in the background normalization can be easily seen at these energies since there are few source counts. Note: there may be true source counts at these high energies as a result of pileup.

In this example, the background from the circular regions — especially at high energies — has been underestimated.

Increased background

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.

Source Spectrum vs. Extraction Width

[Version: full-size]

Source Spectrum vs. Extraction Width

Spectra in the source region (not background subtracted) using a box centered on the source, with different box widths; going from 4 pixel to 9 pixels. The spectra are grouped using the same grouping scheme: minimum of 50 counts per group in the 4-pixel wide region.

The spectrum for this source is dominated by background below 1keV and above 6keV. It is in these energy ranges where the effect of the different extraction region widths is easily visible. However, the effect can be seen at all energies when the full resolution plot of the spectra is displayed.

Of course, as the box width gets wider, it may also begin to include nearby sources (other point like sources in the field and/or any nearby extended emission). Since source events cannot be resolved spatially, the events for any nearby emission may start to contaminate the spectrum.

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.

Using specextract

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).

Note

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.

Spectrum vs. TARG location

[Version: full-size]

Spectrum vs. TARG location

The spectrum for the source in ObsID 11233 where the TARG keywords have been modified to locate the target source location near the bottom of the chip (red histogram) and near the top of the chip (blue histogram). The TARG location as specified in the event header places the target location near the center of chip.

The spectrum has been grouped so that each group is 4 channels wide. (One channel is 14.6 eV wide.)

The spectrum corrected for CHIPY locations near the bottom of the chip is systematically lower (shifted to the left) compared to the spectrum corrected for CHIPY locations near the top of the chip.

This is due to how the CTI correction depends on the CHIPY value. The CTI correction is less for events with small values of CHIPY leading to an under correction of the energies. High values of CHIPY have more CTI correction leading to a systematically higher, over corrected, spectrum.

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.

ARFs computed with different TARG locations

[Version: full-size]

ARFs computed with different TARG locations

This figure, top panel, shows the ARF for the source with the TARG location that is near the center of the chip (green curve) and near the bottom edge of the chip (blue curve). The effective area is maximized near the aim point, which for this observation is near the center of the chip.

The bottom panel is the relative difference in the ARF at the center of the chip compared to the bottom edge: (ARF_center-ARF_bottom)/ARF_center. This shows that the difference in the two ARFs is not just a constant scale factor but varies with energy.

Inaccuracies in the TARG location can then lead to errors in the ARF which may lead to errors when fitting. The integrated flux may be systematically higher or lower than the computed value (depending on the true TARG location); and since the difference in the ARFs is energy dependent, it can also affect things like the slope of a powerlaw model or temperature of a thermal model.

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.

Important

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.