... observation¹

MARX accepts only a single aspect file, not a ``stack'' of files. If your observation has multiple aspect files, you must concatenate them using dmmerge, as discussed in the CIAO Data Products Guide. The aspect files must be combined in time order; the string of numbers in the file name (e.g. ``pcadf111767021N001_asol1.fits'') refers to the start time of the period for which the aspect solution is valid.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... results²

Multiple fitting sessions can be applied to each source, e.g. thermal and power law spectral models. An interactive tool (ae_spectra_viewer) is available to help the observer designate the preferred fit for each source (§7.20).

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... currently³

Prior to version 3.167, AE modeled the HRMA using the mkpsf tool, which has a number of problems:

• The CXC has always warned users that the accuracy of mkpsf results is compromised by the coarse spatial sampling of the PSF Library.

• We have found (and reported) that the PSF Library contains errors which produce artifacts in some off-axis PSF images.

• When processing observations at the I-aimpoint, PSFs cannot be reliably constructed for sources on the S-array. The following warning message is produced by mkpsf:

  ``The requested X,Y coords were outside the PSF library file range. The closest coordinates in the PSF Library file were used instead.''

  This problem was reported to the CXC Helpdesk as ticket #5346. The root cause is thought to be that PSFs on some regions of S2 and S3 are missing from the CALDB. If mkpsf results are used it appears that such sources would be extracted using incorrect apertures and should be treated accordingly.

• When processing observations at the S-aimpoint (/S_AIMPOINT supplied to AE), sources on I2 or I3 cannot be processed by AE because the CALDB PSF library does not contain the appropriate PSFs.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... aperture⁴

For example, the ahelp page for mkarf says ``The ARF is computed assuming that the spectral extraction region is large enough to include the entire PSF (e.g. PSF fraction=1.0).''.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... infinity⁵

When MARX is used the total PSF power can be estimated only for the portion of the sky falling on ACIS since rays missing ACIS are discarded. In earlier versions of AE, when mkpsf was used, estimating the total PSF power was very difficult since that tool does not provide cropping information; AE did attempt however to estimate cropping in the f1 and f3 PSF libraries using the f2 library which uses larger PSF footprints; see What's New for February, 2004 (AE Version 3.19).

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

....⁶

I don't know a good astronomical reference for this practice, but see:

• Section 2.2 of "A Standardized Algorithm for the Determination of Position Errors by the Example of GPS with and without 'Selective Availability'", Ingo Harre, published in ``The International Hydrographic Review'', Vol. 2, No. 1 (New Series), June 2001, http://www.mar-it.de/NavGen/final_text3.pdf

• Section 4-10 of ``Hydrographic Surveying'' engineering manual, US Army Corps of Engineers, http://www.nap.usace.army.mil/channel/em/4.pdf

• Section 4.5 of http://www.usace.army.mil/usace-docs/eng-manuals/em1110-1-1003/c-4.pdf

• Section 2.4.3 of ``Principles and Practice of GPS Surveying'', http://www.gmat.unsw.edu.au/snap/gps/gps_survey/chap2/243.htm

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... required⁷

Multiple observers have reported that IDL version 6.0 produces mysterious NaN values in PSF images and PSF fractions that are NaN; I do not recommend using version 6.0. Other 6.x versions are probably ok.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... required⁸

Version 5.3 of HEASOFT did not include the em ftemplate tool which is used by our XSPEC scripts. You can obtain it at http://heasarc.gsfc.nasa.gov/docs/software/lheasoft/tools.html

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... preference⁹

The IDL manual describes several ways IDL preferences can be changed.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... analysis¹⁰

Theoretically, point sources could instead be eliminated by defining ``compound'' diffuse regions, say a polygon which includes a diffuse region and several small circles inside the polygon which exclude point sources.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... stage¹¹

• In each observation's sky extraction directory rename the files source.pi and source.arf to background.pi and background.arf.

• In the background spectra (background.pi) set the keywords ONTIME, LIVETIME, and EXPOSURE to zero. (This is part of AE's convention for representing the background scaling required.)

• For each observation of each diffuse source make symbolic links to the files background.pi and background.arf in the corresponding sky extraction directory.

• In the MERGE stage you must supply the energy at which the exposure map was made via the keyword parameter EMAP_ENERGY. AE uses the ratio of the source and background ARFs (normalized to 1 at EMAP_ENERGY) to adjust the background scaling (BACKSCAL vector) in the final background spectrum produced for fitting. See §7.16.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... results¹²

Our guess is that the root problem is that sky-to-detector coordinate conversions in these tools are incorrect for reprojected data. One may guess that very small reprojections, e.g. to fix astrometry in a single ObsId, would cause only very small errors in these tools.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... provided¹³

If the coordinates RA=0, DEC=0 are provided then AE looks for coordinates in an existing source.stats file.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... Y\_DATA.¹⁴

These ``standard errors'' of the means X_DATA, Y_DATA are estimated as

$$EX\_DATA = \frac{\sigma_{X,parent}}{\sqrt{N}}$$

$$EY\_DATA = \frac{\sigma_{Y,parent}}{\sqrt{N}}$$

where $\sigma_{X\vert Y,parent}$ is the standard deviation of the parent distribution for the in-band extracted events. That parent distribution is (ignoring background) assumed to be the source's PSF truncated by the extraction region and thus $\sigma_{X\vert Y,parent}$ can be calculated ``perfectly''.

This simple $\sigma/\sqrt(N)$ calculation for the position errors is correct if the parent distributions are Normal, and is asymptotically correct for any parent distribution as N gets large. For non-normal PSFs with few counts I do not know a better estimate for the position errors.

Note that an alternate approach (used in earlier AE versions) would be to estimate the variances of the parent distribution from the extracted count data themselves, then compute a confidence interval on our sample mean with the aid of the Student's T distribution (which accounts for the imperfect variance estimates for the parent distribution). This is a poor approach however because one often has very few extracted counts which can produce wildly inaccurate estimates for the variances of the parent distribution. We prefer to make use of the information on the parent distribution carried in the truncated PSF.

Note that the error estimation above is concerned only with uncertainty related to counting statistics. Even if you had a very large number of counts there are at least two sources of systematic position error:

• The parent distribution of the data in our extraction region is NOT simply our model PSF image truncated by the extraction region. Our model PSF image is by construction aligned to the extraction region, whereas the actual star's PSF is assumed to be somewhat misaligned to the extraction region--that's why we're trying to estimate a better position in AE. Thus iterative adjustment of the source position and re-construction of the extraction region is probably a good idea.

• Off-axis PSFs are asymmetric and the position of the celestial source does not correspond to the centroid of the PSF. This is why correlation of the data with the source's PSF (§7.17) is a useful technique for estimating source positions.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... arbitrary¹⁵

Note that CIAO 2.3 cannot parse region files with more than 1024 characters. To work around this limitation, the supplied background region file may be reduced in size in AE by reducing the number of vertexes in polygon components.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... Kolmogorov-Smirnov¹⁶

Refer to ``Numerical Recipes'' by Press et al., 2nd edition (1992), Chapter 14 for discussion of the 2-sided KS statistic.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... significance¹⁷

Significance is defined in §5.10

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... infinity)¹⁸

The mkpsf tool is currently unable to provide normalization information for the PSF images it generates

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... mistake¹⁹

The mistake was that, prior to version 3.2, AE was computing distances between the stair-step cumulative distribution of the data and the uniform distribution only at ONE end of each stair-step. The KS routine in the IDL Astro Lib, derived from Numerical Recipes, indicates that BOTH ends of each stair-step must be compared to the uniform distribution.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.