<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <!--Converted with LaTeX2HTML 98.1p1 release (March 2nd, 1998) originally by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds * revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan * with significant contributions from: Jens Lippmann, Marek Rouchal, Martin Wilck and others --> <HTML> <HEAD> <TITLE>Storage format</TITLE> <META NAME="description" CONTENT="Storage format"> <META NAME="keywords" CONTENT="vol2"> <META NAME="resource-type" CONTENT="document"> <META NAME="distribution" CONTENT="global"> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <LINK REL="STYLESHEET" HREF="vol2.css"> <LINK REL="next" HREF="node607.html"> <LINK REL="previous" HREF="node605.html"> <LINK REL="up" HREF="node605.html"> <LINK REL="next" HREF="node607.html"> </HEAD> <BODY > <!--Navigation Panel--> <A NAME="tex2html9101" HREF="node607.html"> <IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="icons.gif/next_motif.gif"></A> <A NAME="tex2html9098" HREF="node605.html"> <IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="icons.gif/up_motif.gif"></A> <A NAME="tex2html9092" HREF="node605.html"> <IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="icons.gif/previous_motif.gif"></A> <A NAME="tex2html9100" HREF="node1.html"> <IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="icons.gif/contents_motif.gif"></A> <BR> <B> Next:</B> <A NAME="tex2html9102" HREF="node607.html">General instrumental information</A> <B> Up:</B> <A NAME="tex2html9099" HREF="node605.html">Instrument configuration and run-specific</A> <B> Previous:</B> <A NAME="tex2html9093" HREF="node605.html">Instrument configuration and run-specific</A> <BR> <BR> <!--End of Navigation Panel--> <H2><A NAME="SECTION003251000000000000000"> Storage format</A> </H2> This diversity of possibilities does not lend itself readily to MIDAS table structures. If, as is usual, only a single detector is used, it would be wasteful and inconvenient to burden a table with several columns containing identical detector data in every row. Furthermore, information that should be the same for every filter, such as detector information for a single-channel instrument, could become inconsistent if presumably duplicate entries were stored in table format. To include code to test for the consistency of such constant-valued columns would impose overhead and maintenance problems for the programs that read the table. <P> A possible solution would be to use a table file with one row per filter, and to store information that remains the same for <I>all</I> filters in descriptors. This seems to be the policy that has been adopted for FITS tables. Then ordinary single-channel instruments could keep all the detector information in descriptors. But multi-channel instruments should store the detector information for each passband in the table itself, restoring the problem of duplicated data for all the bands that use the same detector. <P> On the other hand, some kind of array structure is needed to hold the information about detectors in multi-channel instruments. But the channels do not necessarily correspond to passbands in a one-to-one way; for example, an instrument might use a blue-sensitive photomultipler tube to measure U, B, and V, and a ``red'' tube to measure R and I (see the example in section <A HREF="node631.html#sect-2chan">I.5.7</A>). We could store the detector information as MIDAS ``descriptors''; then the problem is that instruments with multiple detectors would require multi-element descriptors, and a cross-reference table column to identify which detector goes with which filter combination. <P> A practical if not very elegant solution is to store everything in one <I>physical</I> table file, which contains two logical sub-tables - one for passbands, and one for detectors. Each sub-table contains an explicit index column, to allow explicit cross-references, despite any rearrangement of the actual table rows. This index column serves as the natural sequence number within each sub-table. This reduces the number of files the user has to keep track of. Invariant information for the whole instrument then goes in the table file's descriptors. <P> Most of the information in this table is stored as strings, rather than numerical values, thus keeping the entries easy for humans to read. Many of the items make sense (and will be looked for) only if others have particular values; see Tables <A HREF="node613.html#tbl:passband-instr-cols">I.10</A>, <A HREF="node618.html#tbl:instr-descriptors">I.11</A>, and <A HREF="node624.html#tbl:detector-instr-cols">I.12</A>. <P> <HR> <!--Navigation Panel--> <A NAME="tex2html9101" HREF="node607.html"> <IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="icons.gif/next_motif.gif"></A> <A NAME="tex2html9098" HREF="node605.html"> <IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="icons.gif/up_motif.gif"></A> <A NAME="tex2html9092" HREF="node605.html"> <IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="icons.gif/previous_motif.gif"></A> <A NAME="tex2html9100" HREF="node1.html"> <IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="icons.gif/contents_motif.gif"></A> <BR> <B> Next:</B> <A NAME="tex2html9102" HREF="node607.html">General instrumental information</A> <B> Up:</B> <A NAME="tex2html9099" HREF="node605.html">Instrument configuration and run-specific</A> <B> Previous:</B> <A NAME="tex2html9093" HREF="node605.html">Instrument configuration and run-specific</A> <!--End of Navigation Panel--> <ADDRESS> <I>Petra Nass</I> <BR><I>1999-06-15</I> </ADDRESS> </BODY> </HTML>
