2012 Jan 06


Two underlying drivers:
-----------------------
1) Uniformity of naming convention is highly desirable.  This will
   greatly facilitate archiving of data, especially since we have
   limited resources to do this.

2) Existing files will not be overwritten.  It is easier to discard
   later than to correct an accidental overwrite of precious data.
   This will be critical for nights where there are multiple programs
   and/or multiple instruments in use.

Details:
--------
3) Data will get stored in a hierarchical format by
   TelescopeID/InstrumentID/UTDate/ABBR.NNNN.fits

   (a) where TelescopeID is a unique id for the telescope, in this
       case dct

   (b) InstrumentID to be chosen by the instrument PI(s), with a
       preference to short, clear and unique.  Suggests have already
       been floated for:
       	    LMI   => lmi
	    NIHTS => nihts
	    LSES  => lses
       Some thought should be given to conventions for instruments
       with multiple detectors (like NIHTS, LSES, RIMAS).  Can be
       defined later by the PI.

   (c) UTDate - YYYYMMDD date format of the UT date.

   (d) ABBR.NNNN.fits - individual fits files
       ABBR - to be a pre-defined abbreviated name for the
        instrument.  I suggest it be the same as the above
        InstrumentIDs.
       NNNN - four digit sequence number, to be padded out with
        leading zeroes.  If the sequence number should exceed 9999, the
        software should add the necessary leading digit(s).

   Sample path for an LMI image taken on 2012 Jan 06 UT would be:
      dct/lmi/20120106/lmi.0001.fits

4) The observing system will provide default path names.  The user
   will be advised of the data path at start up.

5) The default UT date for naming purposes will be set to the UT date
   of (current MST + 5hrs), meaning that the default naming date will
   increment at noon MST to the UT of the upcoming midnight.

6) Every time an image is written, the system will check the image
   start time and determine the appropriate directory name.  If the
   named directory doesn't already exist (i.e., the start time has
   crossed the threshold), then the system will:

   (a) create a new data directory for the new date

   (b) re-set the image counter (NNNN) to 0001

   (c) write out the image with the new date in the new directory

   (d) inform the user in a non-modal manner that the UT date has
       incremented, and display the new data save path, and then
       continue operation (ie.  the system should display the data,
       but NOT require any response so that if a long script is
       running it will not be stopped).

   This will allow the system to operate continuously if desired
   without the user worrying about keeping track of the date

7) In the event that the observing system crashes, or goes down, upon
   restart, it will compute the current default data save path, and if
   that exists, it will sort through the data there and find the
   largest sequence number.  It will set its next image sequence
   number to be that largest number plus 1.

8) There should be an engineering option that can be set to permit
   someone doing work on an instrument to change where the data are
   stored, so as to avoid confusion with normal observing data.  This
   will be an option that is explicitly set by the user, and will NOT
   persist across shutdown of the observing system.

9) By default, the observing system will always come up in the normal
   observing mode.