Re: Mark IV Software

[Tom Droege <droege@FNAL.GOV>]

Chris Writes:

>A reasonable list but I think you have broken it up into to
>many parts to soon.
>
>Here want I'd do:  Break it up level by level into a hierarchical
>structure. The idea is you define one module "the system"
>next you decompose that into parts (from three to five parts)
>and think about how those parts interact.  Thinking about
>how 16 parts interact is far to complex for us mortals to
>attempt.  Likely three layers is enough
(snip)

OK, I will try again.  There are two main modules:

1) Data Collection
    a) Input:  Some Command Language
    b) Output: FITS Files

2) Data Processing
    a) Input:  FITS Files
    b) Output:  Technical Papers

At the moment I am mostly concerned with 1).  Note that we are
already doing 2).  What we do for 2) should not change much 
with the Mark IV.  The files just get bigger.  But by the time
we get there, computers will be faster and disks will be 
cheaper, and 2) might not be much harder than it is today.

To a certain extent I have already done 1) for the Mark IV.
For prototype tests, I wrote a menu program in QBasic.  It has
functions like "Home the RA Carriage", "Move n steps W", "Open 
Shutter", "Pause n seconds", etc..  I can then write a script
in these functions that does everything necessary to make an
exposure.

This gets me a raw binary file.  I then read this file into 
Mike Gutzwiller's "Deep Sky" which lets me do such things, and
then I have it write out a FITS file.  With very little work,
I can imagine writing QBasic code that runs the camera for a 
whole evening and fills the disk full of binary files.  I can
then imagine talking Mike into writing the necessary patch to
read all the binary files and convert them to FITS.  If I can
do it by hand, then it should not be too hard to automate the
process.

So 1) is almost done.  2) is being debugged as I write by Chris,
Michael, and Co.   

What I am really after is a careful definition of the pieces of
this process so that it can be improved a small bit at a time.
We already have a great start on this by defining that FITS 
format is the way we exchange data between 1) and 2).  

Possibly we need do little more for 1).  This is not supposed to
be a general purpose telescope where many people at arbitrary 
locations can send in an arbitrary programs for the telescope 
to process, scheduld and prioritize.  It is mostly only "who 
is going to run the standard program tonight and respond to 
error messages".  This does not sound too complicated to me.

OK, I know it is more complicated.  But the only way we can take
on such a big job it to delude ourselves that it is easy.  ;^)

Tom Droege