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
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
The hierarchy of the different parts of an observation is
characterized by three numbers:
- 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.
- 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
are always combined in a
single set of Level 2 products. Each ObsId
contains one or more Observation Intervals.
- An ObsId may be broken into more than one
(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
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
Each distribution comes with an Observation Index File,
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
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):
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:
- The level of processing that generated the product.
- A P in this columns indicates that this
product is considered proprietary for observations that are not yet
- Instrument of subsystem to which the product relates; included in the
- A brief description of the product.
- Value of the CONTENT keyword in the
product's header. This keyword identifies each data product uniquely.
- The part of the file name that immediately precedes the
.fits extension; this allows one to identify
the data products by file name.
|Sky Image (Center)
|Sky Image (Full Field)
|Field of View
|Moving Target Ephemeris
|V&V Report (PDF)
|Sky Image (Center; jpg)
|Sky Image (Full Field; jpg)
|Source Image (jpg)
|Good Time Intervals Filter
|OBC Aspect Solution
|V&V Reference (PDF)