In this document, we will discuss a variety of details about the Elixir system. These include the 'photcode' concept for identifying the telescope, filter, detector combinarion; the use of configuration files thoughout Elixir; and the syntax for representing times at various locations.
Photcode
Every combination of a specific telescope, CCD and filter has a somewhat different response. It is important to be careful when combining measurements made with different detectors and filters to be sure they are calibrated correctly. In order to keep track of these effects, we have associated each measurement with a code that determines uniquely this combination of filter, CCD, telescope. We call this a 'PhotCode', and we have several mechanisms to handle the photcode issues.
Photcode types
there are four different types of photcodes in use in the elixir/ptolemy systems. The most obvious photcodes are those that refer to specific measurements. These are called "DEPENDENT" photcodes, and there should be one for each filter, ccd, telescope combination. The next type are measurements provided from the outside world and should be considered 'perfect'. Unlike measurements of the DEPENDENT type, these are measurements that do not need to be calibrated. They are of the REFERENCE type. Finally, there are the derived, average measurements in a given filter. Since our photometry database has a single filter defined as the primary average magnitude, and additional magnitudes are stored distinctly as secondary magnitudes, one of these average photcodes is defined as PRIMARY and the others as SECONDARY.
So, for example, imagine having many observations of the same star in R with a mosaic CCD camera. If the images are extensively dithered, there will be many measurements of the star with the different detectors. These are essentially the same filter, but not exactly. Therefore it is nice to have a way of distinguishing the individual measurements (DEP, ie CFH12K.R.00) from the best average R magnitude of the stars (PRI). This is also distinct from the (possible) observations obtained of this star by Landolt (REF - R_L92) or from the USNO catalog (REF - USNO_RED).
As images are analysed in the elixir system, particularly in the ptolemy elixir, they are associated with the appropriate photcode. This is normally done by the flat-field process, since the photcode is needed to identify the correct flatfield image. The flatten process writes a header keyword, PHOTCODE to the flattened image header for the later processes that need it. (Most of the downstream functions can also specify the photcode on the command line if needed or desired). The program 'addstar', which incorporates the resulting photometry in the RA & DEC ordered database, uses the photcode entry in the header to define the photcode for the measurements.
Configuration and Generalization
With the exception of dophot, all of the Ptolemy programs refer to a single configuration file to determine the large number of parameters necessary in the process. The default parameter file is hardwired into the programs, but an alternate configuration file may be specified with the environment variable PIPE_CONFIG. This option makes independent processing of multiple data sources trivial. For example, if the pipeline is to be used for both Loneos and SDSS image analysis and display, there could be two configuration files (eg, loneos.txt and sdss.txt), one for each data source. Several important parameters would be different between these two, for example, the initial plate scale guess for the astrometry routine, or the parameters which define the rough chip orientation. This scheme allows for analysis of different types of images, with a common destination photometry database, or for independent photometry databases.
Data from different sources can be processed by the pipeline and stored in the same photometry database, since all photometry is tagged with a source ID in the database (as are the images in the image database). This allows us to include, for example, the USNO catalog magnitude measurements (or a subset) in the photometry database for a quick comparion. Different sources may be considered different filters, so color-color and color-magnitude diagrams could be extracted by specifying choices for source catalog. Currently each object has a single primary photometric system, and individual observations may be combined to determine that average (eg, if they are different photometry sources with roughly the filter bandpass) or they may be ignored when calculating relative magnitudes (eg, the USNO magnitudes would be ignored). This may be expanded upon by defining multiple average magnitudes and allowing different measurements to contribute only to the appropriate average. The determination of the photometry code for a particular image is currently not well defined. There are several points in the analysis where the user (or the controlling program) may specify the photometry source. A table should be kept in the photometry catalog to define the various photometry codes.
file names: Notice that we use a consistent naming convention through the pipeline reductions. The image is called foo.fits, while the resulting dophot-produced photometry list is called foo.obj.
Time representations in Ptolemy
Every measurement in the Ptolemy database has a time stamp associated with it, as do all of the images. Throughout the software, the time is represented consistently using the standard UNIX representation of time, which consists of an unsigned integer representing the number of seconds since 1970 Jan 01, midnight. The time used roughly represents UT time, though there is some subtlety here. In reality, the time reported at LONEOS is reported by a GPS clock, and therefore uses the GPS zero point. There are small, well defined differences between UT, GPS, and WHAT IS THE THIRD ONE? GPS - UT is a constant NN seconds, while UT - OTHER is a function of time, as leap seconds are accumulated in one and not the other. While the programs all refer to this seconds representation of GPS time, the user of the programs usually has a few more choices. In status, all(?) functions which require a time argument expect to see one of three formats. If there is a number of the form NNNNNNNNNs, this is assumed to be the UNIX seconds form. If there is a number of the form NNNNNNj, this is assumed to be a Julian date. If there is a number of the form YY:MM:DD,hh:mm:ss, this is assumed to be a UT date string. Note that the difference is in the presence of either 's', 'j', or something else at the end of the string. In the case of a date, it is acceptable for the separators to be any non-numerical character, and there may even be a trailing separator, as long as it is neither 's' nor 'j'. Command arguments which expect a time range may provide one of the following units: 's' (seconds), 'm' (minutes), 'h' (hours), 'd' (days). Also, it is only necessary to provide as many significant places in the date as desired. So, if you are interested in the images taken on UT 1999 March 03, you could run images -im 99:03:03 1d.
The validity range of the UNIX seconds representation of time is 143 years, so this measurement representation will become ambiguous in the year 2113. Note that the Y2K problem is dealt in the date string by assuming any date with year smaller that 70 means 21st century, and others are 20th century. Of course, the user may explicitly type the full 4 digit year to ensure an unambiguous answer. Finally, the user may refer to the current time as NOW and the current date as TODAY.
| |
|