Converting between CHIP and SKY Coordinates with dmcoords
CIAO 4.2 Science Threads
Last Update: 5 Feb 2010 - reviewed for CIAO 4.2: no changes
dmcoords does not automatically take into account drifts in the Chandra geometry when calculating sky coordinates. These drifts were negligible near the beginning of the mission, but have grown to the order of 10 arcseconds and so cannot be neglected.
Read this thread if:
you are running dmcoords to convert from sky to chip coordinates or from chip to sky coordinates.
Sample ObsID used: 1838 (ACIS-S, G21.5-09)
File types needed: evt2; asol1
To connect sky and chip coordinates, we need to take into account not only the celestial pointing direction (RA and Dec) of the telescope optical axis, but also the position of the instrument bench in the frame of the telescope mirror.
- the motion of the SIM which puts ACIS or HRC in the focus at a particular location
- the time-variable bending of the telescope tube and other drifts in the Chandra geometry.
This latter correction is measured by the fiducial optical system and is contained in the aspect solution (asol1.fits) files as columns dy and dz, giving shifts in mm of the focal plane relative to the optical axis. These values change very slowly over the course of an observation (about one or two pixels); it is taken into account in the calculation of sky coordinates in the pipeline by acis_process_events.
Because the mean values of dy and dz were also small early in the mission, dmcoords does not by default take them into account. However, five years into the mission the mean value has now grown to the order of 10 arcseconds and so cannot be neglected.
To get an accurate chip to sky conversion with dmcoords, one must determine the mean offsets and supply them to the tool. You can do this very simply by providing the aspect solution files in the asolfile parameter.
In many cases, there will be more than one aspect solution file (pcad_asol1.fits) for an observation. All the files must be input, either as a list or as a stack. Here we use:
unix% cat pcad_asol1.lis pcadf084244404N001_asol1.fits unix% pset dmcoords asolfile=@pcad_asol1.lis
This allows dmcoords to pick up the correct conversion from the aspect solution.
You can check the results by finding a bright source (for good statistics) and using dmstat on the events in the event file. Then confirm that the results agree with those given by dmcoords. Since acis_process_events has always applied the full aspect solution correction, including the dy/dz correction, the chip and sky coordinates for individual photons in the event files are fine - the problem only arises in dmcoords when you are trying to predict positions.
unix% punlearn dmstat unix% dmstat "acisf01838N002_evt2.fits[sky=circle(4070,4249,14.024608)][cols chip]" chip(chipx, chipy)[pixel] min: ( 340 350 ) @: ( 2722 375 ) max: ( 400 410 ) @: ( 2360 2047 ) mean: ( 367.3435916 382.13359884 ) sigma: ( 12.667743873 12.784088222 ) sum: ( 2029206 2110906 ) good: ( 5524 5524 ) null: ( 0 0 ) unix% dmcoords acisf01838N002_evt2.fits asolfile=@pcad_asol1.lis x=4070 y=4249 option=sky mode=h unix% pget dmcoords chipx chipy 370.6864338870305 381.7202885466321
The discrepancy is small - about 3 pixels in chipx and half a pixel in chipy. Compare this to the results obtained from dmcoords without the aspect solution:
unix% punlearn dmcoords unix% dmcoords acisf01838N002_evt2.fits x=4070 y=4249 option=sky mode=h unix% pget dmcoords chipx chipy 374.6090337746003 391.6939153042483
The difference is greater than 10 pixels without the aspect solution applied.
|30 Nov 2004||updated for CIAO 3.2: new asolfile parameter in dmcoords|
|09 Dec 2005||reviewed for CIAO 3.3: no changes|
|01 Dec 2006||reviewed for CIAO 3.4: no changes|
|08 Jan 2008||updated for CIAO 4.0: filenames and screen output updated for reprocessed data (version N002 event file)|
|13 Jan 2009||reviewed for CIAO 4.1: no changes|
|05 Feb 2010||reviewed for CIAO 4.2: no changes|