The ICRED wrapper is simply an attempt to separate
the user from IDL. After issuing the startup command, it is the
intention that the user need to know nothing at all about a) the
structure of the data and b) how IDL operates.
Last updated: 6th Feb.
How to make it go:
start IDL and modify the path with:
then type: @icred
at the IDL
prompt to excecute
(This has @phil and @corinit inside it, so you
that compilation script separately).
lists the scans for a specific
- creates files for spectra,
cal for a dataset
Plots a previously saves
Averages Correlator data
- Accumlates a record into a
Baseline a correlator dataset
Interactively create a mask
At this stage, only a few processes have been
The wrapper operates by turning all inputs
values are parsed from the inputted info by strsplit, using '=' as a
delimiter. Consequently, anything without '=', that is not 'list',
'help', 'exit' or 'go' is not understood, and is passed straight
through to the operating system.
Parameter settings which expect a number of
values (e.g. setting a plot
range, selecting some task options) are comma separated (WITH NO
SPACES! - although this is simple to change), and strsplit is run again
on the parameter, using ',' as the delimiter.
Quotes are not expected (eg. using
understood. Using quotes will return an error message.
For tasks which generate an output file, other than plots, or text
outputs, data are generally saved using the IDL 'SAVE' command.
Similarly, data which is being recalled from a file use the 'RESTORE'
command. The name of the file is generally user-specified, however the
name of the varible being saved helps to indicate what kind of
data is actually saved. For example, variables holding data which
is known to be a spectrum (output from corposonoff for example), are
called 'DATA_SPECTRUM', although others exist e.g. data_cal, data_bon
etc. (see code for icred_corposonoff.pro for many other examples).
These names are HARDWIRED. They can be changed, but it will be an ugly
task to do so, since it will be important to make sure that the changes
are made consistent with other icred_<taskname>.pro programs.
Personally, I think this is a bit ugly, but I cant think of a better
The organisation of icred is split into three
1). the command interpreter:
This is the system which
recieves all command
inputs. it decodes inputs and selects tasks, parses parameter inputs
and also runs the 'go', 'list' and 'help' commands.
It does no error checking, for example to see
if the parameter inputs
are sensible (e.g. it does not check if an x-range has been
entered as 'chicken', rather than a more understandable range of say
2) the task decoders:
once 'go' is typed, the interpreter sends the
settings (via a structure called 'paramlist') to the task decoders.
These do error checking at some level, although this needs to be
improved. Apart from checking to see that a requested input file
exists, or that the requested options are understandable, no other
checking is done. Yet.
Once all the input parameters make sense, a
command is issued to run
the existing ICorr software.
3) ICorr software.
This is the stuff that already exists, they
also do error checking.
Other tasks or important commands:
GO: The general 'go' command sends the
parameter listing to
the decoders, which then initiate the execution of the ICorr software.
Help: This has a two-level
response. A generic listing of
existing implemented tasks and a brief description can be obtained with
along with some other general syntax info. More task-specific info can
be obtained by typing 'help=<taskname>', where the tasknames of
the existing ICorr software are preserved (e.g. using 'corlist' still
does what 'corlist' always did).
List: This lists the parameters for the
task, and the current settings.
Exit: This quits totally out of ICRED and IDL.
There are two small programs which are used
write, and recall
previous parameter settings. These are 'writerecall.pro' and
'readrecall.pro'. Every time a task parameter is modified, the entire
parameter list is sent to an archive file (called ICRED.arch). Every
time a new task is selected, the archive file is read to recall the
last parameter settings.