/ ciao / merging / astrometry.html

Merging Central

Revising Astrometry for Imaging & Spatial Analysis

Introduction to Merging Chandra Data Spatial/Imaging Analysis Spectral Analysis Timing Analysis

This page is intended to provide a broader view of astrometric correction for Chandra data analysis and caveats specific to doing so with CIAO.

Where Does Astrometric Corrections Occur in the Workflow?

A common question from users regards when to apply astrometric updates to a data set since it appears at different points in the analysis/reprocessing shown in our documentation, which were written by different individuals over the decades. Typically, astrometric corrections are made either to the archived level 2 (L2) file before reprocessing the data –or– after the data has already been reprocessed.

Ultimately, the order does not matter.

We suggest running chandra_repro first because often the next step is to run wavdetect or some other source detection tool with an exposure map to get source lists to cross match. Running chandra_repro ensures that a consistent calibration is used between the observed events data and corresponding response files that will be generated downstream. But you can just as easily run source detection on the L2 files you get from the archive and perform the astrometric correction before reprocessing to a common CalDB.

In the case of reprocessing before applying astrometric corrections,

After both the event file and aspect solution file(s) have been updated by running wcs_update, there is no need to re-run chandra_repro, albeit there is also no harm in doing so. Nothing is "undone", so to speak, by running it after wcs_update. Some users may choose to only run wcs_update on the aspect solution file(s)—in which case then they would need to either run chandra_repro or reproject_events. The choice is yours.
If you update just the aspect solution file(s), then when you run chandra_repro you will get a new event file with new sky coordinates (i.e. the x,y values will be different). If you have regions stored in physical coordinates, based on the pre-astrometric-updated data, they will be wrong with respects to the updated astrometry.

By updating the aspect solution file(s) and the event file with wcs_update, then both the aimpoint and the tangent point so the sky (physical) coordinates are the same.

Doing the correction right off the bat on the level 2 files before reprocessing typically means you have less book keeping early on to track files, since the corrections subsequently are used in whatever downstream processing you're doing.

Caveats: Updating Astrometry with CIAO

The default wcs_match behavior has the parameter method=rst which determines scaling and rotation terms in addition to the x and y translations in the transform file. The rotation, translation, and scaling solution requires at least four matching sources, and ideally evenly spaced out to provide reliable results. When the sources are clustered together, the method can be a bit unreliable since while the determined transform solution may be mathematically correct, it will likely not reflect physical reality. The translation method (method=trans), from experience, generally gives more realistic results, even though the former method is more generalized.
There are instances where there should be an obviously matched source amongst a set of observations upon visual inspection; nonetheless, reproject_aspect/wcs_match fails to match, rejecting them as a "poor match" (even when the source is nearly on-axis across all the observations). wcs_match uses a rather crude minimization method which can contribute to the behavior. Expermenting with either the residlim or residtype/residfac parameters may help with avoiding the match failure.
wcs_match/wcs_update modifies the fine astrometry of the data; it shifts the RA & Dec but does not change the underlying physical sky coordinates (x,y). The output from the detect tools are a FITS region file. Even though the file contains RA & Dec values, the convention is that when used as a region file the x,y values are automatically used, which may account for the shift when compared to the originally generated source list. If you are using reprojected events files the tool(s) changes the x,y values so that all the reprojected files have a common x,y center while maintaining the RA & Dec values, which may enhance the offset even more.
With the rotation and scaling from method=rst, it may alter the platescale of the image with respects to each spatial axis which will cause a mismatch between the observed data and generated calibration products, subsequently breaking downstream processing. For example, exposure maps and PSF maps are calculated with square pixels, but the astrometric transform applied to the observed counts map can change the detector's pixel morphology, whereas the pixel's 'squareness' is retained by only using spatial translations from method=trans.

An extreme example of non-square pixels determined using the rotation-scale-translate method of source matching for the updated WCS (which also yields an erroneous tangent-plane determination) is by matching on mostly off-axis sources, which will also have large uncertainties on those RA & Dec positions, can have very large spatial shifts on the order of up to hundred(s) of pixels.
The tools will return a translation-only transform file if there are less than three matches while method=rst, but there is no way of guaranteeing a "good", realistic solution based on just the number of matched sources with method=rst. However, with method=trans, the more matched sources made the better a solution tends to be. A basic rule of thumb is that a minimum of three matches to be a reasonable case to consider doing the astrometric correction.

/ ciao / merging / astrometry.html