Note on Orbit Ephemeris Files

Our goal is to distribute data products within a week of the observation. Since the definitive orbit ephemeris data (orbit*eph1.fits) are usually not available until a week after the period they pertain to, a predictive orbit ephemeris (orbit*eph0.fits) is shipped with all data. Use of predictive ephemerides is perfectly alright for most purposes, since the accuracy for the first week is certainly better than 300 km, or 1 ms. The exception is applying barycenter corrections to fast pulsars.

Users may pick up definitive ephemeris files from a depository at our https public access site.

Procedures and Policies

Proprietary data are distributed through ftp and on physical media, and can be downloaded through ChaSeR. Data products generated by Automated Processing first have to go through Verification and Validation. The Principal Investigator and the Designated Observer will then be notified that the data are available on our ftp site; at the same time a copy is made on physical medium that is mailed to the PI only. Products generated by Custom Processing also go through V&V but are only distributed through the ftp site. In both cases the tar file contains a Standard Data Distribution.

The Standard Data Distribution consists of a tar file containing the products listed in the tables below, organized in a simple directory tree. In addition to these products, the following files are included:

• The L2 Summary Products
• The logs of the L1, L1.5, and L2 ACIS, HRC, and aspect pipelines
• A file oif.fits which contains an index to the files and that is used by the QuickLook facility
• The V&V report
• A file listing the contents of the tar file

Multi-part Observations

The hierarchy of the different parts of an observation is characterized by three numbers:

SeqNum

The Sequence Number is the largest unit, defined by the proposal approval process. It is conceptually a single observation with a certain amount of approved time. At this level we do the bookkeeping on the amount of observing time used and the date when the data go public. The data distribution uses the SeqNum as the name of the top-level directory for the data. The actual observation may be done under one or more ObsIds.

ObsId

The Observation Id indicates an observation of a specified target, for a specific proposal, with a specific observational configuration (i.e., when different parts of a SeqNum are observed with different configurations - e.g., different ACIS chips - they will receive separate ObsIds). All data for a given ObsId are always combined in a single set of Level 2 products. Each ObsId contains one or more Observation Intervals.

OBI

An ObsId may be broken into more than one Observation Interval (OBI) for a variety of reasons (one of them being that the original observation did not get enough good time). The OBI numbering within an ObsId may not be contiguous and may not start at 0. An OBI is an uninterrupted observing interval exclusively dedicated to a single ObsId. Level 1 and Level 1.5 data products are processed by OBI. Data from different OBIs are combined by ObsId in Level 2 products.

The result is that one may get more than one data distribution tarfile for a single SeqNum. Since they will all use the same directory structure and the same top-level directory name, the important question is: can one untar the files on top of each other? The answer is yes, except for the oif.fits file (more about that below).

For example, assume an observation with SeqNum 100, ObsIds 1 (OBI 2) and 2 (OBIs 0 and 4). The user will first receive ObsId 1, in directory 100. Next, ObsId 2 OBI 0 will appear, also in directory 100. There are no conflicts here, since the ObsId is encoded in the filenames and hence they are all different. Finally, ObsId 2 will appear again, this time with both OBIs 0 and 4. The Level 1 OBI 0 files will overwrite those from the previous distribution, but since they are identical, no harm is done. The Level 1 OBI 4 files (since the OBI is also encoded in these file names) are distinct again. The Level 2 files now contain the data from both OBIs and supersede those distributed with OBI 0, but since the version is different and encoded in the filename as well, the previous set is preserved.

Each distribution comes with an Observation Index File, oif.fits, in the toplevel directory. This file has a standard name and is used by the Quick-Look facility. It would be overwritten and information would be lost when files are untarred on top of each other. We recommend that, before untarring the next file, the oif.fits file be renamed (say, to oif1.fits) to save it and to merge all available OIF files using dmmerge:

    > ls oif*.fits > stack.lis
    > dmmerge
      Input dataset/block specification (): @stack.lis
      Column list (): 
      Output dataset name (): oif.fits
      Output block name(1st blkname to be duplicated) (): 
      lookup table (dmmerge_header_lookup.txt): 

  

Detailed Contents

The two tables below list the Chandra data products that are included in Standard Data Distributions, as far as applicable (e.g., imaging observation will not include spectra; spectroscopic observations will not include images; ACIS observations will not include HRC data products; etc.). They also describe the contents of the packages available for retrieval through ChaSeR. The meaning of the columns is:

Level

The level of processing that generated the product.

Propr.

A P in this columns indicates that this product is considered proprietary for observations that are not yet public.

Instrument

Instrument of subsystem to which the product relates; included in the file name.

Description

A brief description of the product.

CONTENT

Value of the CONTENT keyword in the product's header. This keyword identifies each data product uniquely.

Type

The part of the file name that immediately precedes the .fits extension; this allows one to identify the data products by file name.

Primary Products

Secondary Products