Skip to the navigation links
Last modified: 2 April 2024


Catalog Organization & Concepts

The page provides an overview of CSC catalog organization and concepts that should be understood in order to make the most effective use of the catalog.

Observation Stacking

To optimize the limiting sensitivity of the CSC in regions of the sky that have multiple overlapping observations, source detection is performed on stacked (co-added) observations. This brings some added complexity that is described in detail at various places in the documentation, but we summarize the key concepts here for convenience.

Observations taken with the same instrument (ACIS or HRC-I) and whose telescope pointing directions are co-aligned within 60 arcseconds are grouped into stacks. Formally, the observations are matched using a tree clustering algorithm with complete linkage. This means that the pointing direction of every observation in the stack is co-aligned with the pointing direction of every other observation in the stack within 60 arcseconds.

Source detection is performed on the co-added stacks (termed detect stacks) rather than on the individual observations. Once a source is detected, stacked observation detection and individual observation detection properties are evaluated using the subset of observations for which the source falls on the valid per-observation pixel mask—essentially, the pixels for which the 'ideal' (i.e., only including spacecraft dither motion) exposure is greater than ~90% of the peak exposure. The subset of observations for which this is true is termed the valid stack for the detection. See Figure 1.

Figure 1: Detect, Valid, and Likely Stacks of Three ObsIDs

[detect,valid, and likely stacks example]
[Print media version: detect,valid, and likely stacks example]

Figure 1: Detect, Valid, and Likely Stacks of Three ObsIDs

Example detect, valid, and likely stacks for 6 detections (A-F) detected in a stack of three observations (ObsIDs 1-3) shown in red, blue, and green. The edges of each observation's pixel mask are indicated by the dashed lines. Readout streaks are present in ObsIDs 1 and 2 in this example from detection D; the pixel masks for these ObsIDs exclude the readout streaks except for a small region surrounding the bright detection. The likely stack for a detection identifies the subset of observations that maximize the computed detection likelihood. For CSC Release 2, this will either be the valid stack for a detection or a single observation that is a member of the valid stack. The likely stacks listed are based on the light curves in this example.

Detections vs. Sources

Because the size of the Chandra PSF varies by roughly a factor of 50 between the center and edge of the field of view, in the CSC we differentiate between detections and sources. Detections are the blobs of photon counts that we see on the detector image, whereas sources are our interpretation of the detections as distinct X-ray sources on the sky. There is potentially a many-to-many relationship between detections and sources. A single source may correspond to multiple detections because the source is included in more than one observation that includes the same region of the sky. Similarly, a single detection may correspond to multiple sources; this typically occurs when a far off-axis detection (large PSF) is resolved into multiple sources by another observation where the same position on the sky is located closer to the telescope optical-axis (small PSF). See Figure 2.

Figure 2: Detection versus Sources

[detection vs. sources]
[Print media version: detection vs. sources]

Figure 2: Detection versus Sources

Example detections and sources in the field of ρ Oph. The panel at the top left shows a region of detect stack acisfJ1626350m242314_001 that is located close to the optical axis (small PSF) with three detections visible in the area of interest. The same location on the sky in the panel at lower left from detect stack acisfJ1627179m243424_001 that is located far from the optical axis (large PSF) only has a single detection. In the right panel, the highest spatial resolution information is used to conclude (based on the data we have) that there are three distinct sources on the sky, which are assigned 2CXO names. The sources are each linked uniquely (u) to one of the detections from stack acisfJ1626350m242314_001 and they are all linked ambiguously (a) to the single detection from stack acisfJ1627179m243424_001. Linkage is discussed in more detail below in the section Matching Detections to Sources.

Catalog Tables

Because of both observation stacking and the difference between detections and sources, the CSC is split into multiple tables. See Figure 3.

The three main tables are the Master Sources Table, the Stacked Observation Detections Table, and the Per-Observation Detections Table.

The Master Sources Table is the primary catalog table that records the best estimate properties for each distinct X-ray source on the sky, determined by combining data from (a subset of) the individual detections and observations that are associated with the source. For aperture photometry-derived quantities, these are typically determined by analyzing simultaneously the detections from the set of individual observations that comprise the flux-ordered Bayesian Block with the highest exposure time.

The Stacked Observation Detections Table records the best estimate properties for each stacked-observation detection, computed by combining data from the complete set of observations that comprise the observation stack in which the detection is identified. Because a source may be detected in multiple stacks, this table may contain multiple entries corresponding to a single entry in the Master Sources Table.

The Per-Observation Detections Table records the properties extracted separately from each observation included in the observation stack for each stacked-observation detection. Because a stack may include multiple observations, this table may contain multiple entries corresponding to a single entry in the Stacked Observation Detections Table.

The Column Descriptions pages describe how each master source, stacked observations detection, and per-observation detection property is determined.

The Stacked Observation Detections Table and Per-Observation Detections Table report several stack- and observation-specific properties, respectively, such as pointing and instrument information, that are common for all detections identified in that stack/observation.

In addition, here are two associations tables that link entries in the 3 main tables: the Master Source/Stacked Observation Detection Associations Table, and the Stacked Observation Detection/Per-Observation Detection Associations Table; and four ancillary tables: the Detect Stack Table, the Valid Stack Table, the Likely Stack Table, and the Limiting Sensitivity Table.

The catalog also includes a number of FITS format science-ready data products that can be accessed using several of the catalog user interfaces. These include full-field products at the stack and observation level, such as photon event lists, background maps, bad pixel files, and exposure maps, as well as detection and source-specific data products, including source region photon event lists, per-band PSF files, instrumental responses, low-resolution (PHA) spectra, light curves, and aperture photometry MPDFs, among others; see the Data Products section for the full list of CSC file-based data products.

Figure 3: Chandra Source Catalog Data Tables

[CSC data tables]
[Print media version: CSC data tables]

Figure 3: Chandra Source Catalog Data Tables

The set of CSC data tables.

Matching Detections to Sources

The linkages between a source, recorded in the Master Sources Table, and its associated detections, recorded in the Stacked Observations Detections Table, can be identified using the property match_type, which is recorded in the Master Source/Stacked Observation Detection Associations Table.

Each individual stack-level detection in the catalog is classified as either uniquely or ambiguously linked to a master source (match_type equals 'u' or 'a').

A detection that is uniquely linked to a master source is matched to that single master source. The detections properties contribute to the master source properties recorded in the Master Sources Table.

A detection that is ambiguously linked to a master source is matched to more than one master source. This typically occurs because the detection is located at a large off-axis angle and therefore has a large PSF that can be matched to multiple on-axis detections in another stack. Because the detection's photon events cannot be assigned unambiguously to a specific master source, they contribute to the properties of the linked master sources recorded in the Master Sources Table only in a very limited way. For example, they can provide a photometric upper limit for all of the linked master sources at the epoch(s) of the stacked observation(s) but cannot contribute to knowledge of the master source position.

Note that even in the case of uniquely linked per-stack detections, if an ACIS observation is piled-up (specifically, the estimated pile-up fraction exceeds ~10%), its per-observation detection properties will not contribute to the corresponding stacked observation detection or master source properties UNLESS all other ACIS observations of that source are also piled-up (in which case no other measurements are available).

If a master source position falls on a stacked observation for which there is no corresponding detection that can be linked either uniquely or ambiguously to the master source, then a nondetection region is created (with match_type = 'n') at the master source position for each of the observations that comprise that stacked observation. These nondetection regions are sized based on the local PSF (90% ECF) and are used to compute aperture photometry upper limits for the source brightness at the epochs of each of the observations.

Figure 4 demonstrates that all "master source/stacked observation detection/per-observation detection associations" in the catalog, whether ambiguous, unique, or non-detection, are transparent to the user. This feature allows a request of any combination of master source properties, stacked detection properties and per-observation detection properties in a single query to the database, so the user is not restricted to searching a single table at a given time, and can understand how all observations of a single source contribute to a master source entry.


By default, catalog searches that query the Master Sources Table and either of the Stacked Observation Detections Table or Per-Observation Detections Table do not place a constraint on match_type. Unless the user places a specific constraint on match_type, uniquely linked and ambiguously linked detections and nodetections will be returned.

Figure 4: Master Sources, Detections, and Linkage

[Thumbnail image: conceptual flow chart displaying how individual source detections are linked to a master source entry]

[Version: full-size]

[Print media version: conceptual flow chart displaying how individual source detections are linked to a master source entry]

Figure 4: Master Sources, Detections, and Linkage

Master Source I is linked uniquely to Stacked Observation Detection A and linked ambiguously to Stacked Observation Detection B. Per-Observation Detections 1 and 2 will contribute to Master Source I source properties, whereas Per-Observation Detection 3 will provide a photometric upper limit at the epoch of that observation. Master Source II is linked uniquely to Stacked Observation Detections C and D, linked ambiguously to Stacked Observation Detection B, and has a nondetection linkage to Stacked Observation Detection E. Per-Observation Detections 4, 5, 6, and 7 will contribute to Master Source II source properties, and Per-Observation Detection 3 will provide a photometric upper limit at the epoch of that observation. Since no source was detected at the location of Stacked Observation Detection E, Per-Observation Detection 8 is defined to be a local PSF-sized region that will be used to compute a photometric upper limit at the epoch of that observation.

Aperture Photometry & Bayesian Blocks

At the master source level, aperture photometry measures are computed using a Bayesian X-ray aperture photometry algorithm that computes the marginalized probability density functions (MPDFs) for each aperture photometry quantity (e.g., photon flux, energy flux) and individual detection (observation) of a source. The mode and 68% lower and upper confidence intervals of the MPDF are reported in the catalog tables, but the MPDF distributions are available in the phot3 FITS data products that can be downloaded (e.g., using CSCview) for the detections and master sources. Groups of detections whose source regions and/or associated background regions overlap are typically processed together as a set to ensure that a consistent set of properties is determined, for example, to ensure that photon counts in the overlap regions of multiple detections are accounted for correctly.

The MPDFs are evaluated using a Bayesian Blocks algorithm to group the observations into equivalence classes, called blocks, such that for all observations in a single block, the multi-band fluxes are consistent with no variation. There are two types of blocks, based on how the Bayesian Blocks algorithm groups the observations. The first is flux-ordered blocks, where only the multi-band aperture photometry fluxes are considered. In flux-ordered blocks, multiple consistent observations of a variable source will be combined to improve S/N, even if they are separated by observations of the source in another state. For time-ordered blocks, only consecutive observations can be grouped together, which is appropriate when computing temporal variability measures. In the Master Sources Table, we report aperture photometry measures (and derived measures such as hardness ratios) for the flux-ordered block with the highest exposure time (as well as global average fluxes). Additionally, properties for all flux-ordered and time-ordered blocks are reported in each source-specific blocks3 FITS data product that can be downloaded. See the discussion of the Source Properties pipeline and of relevant table columns and data products for more details.