Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.naic.edu/~emuller/icred
Дата изменения: Thu Oct 21 21:30:18 2004
Дата индексирования: Mon Oct 1 20:03:31 2012
Кодировка:

Поисковые слова: южная атлантическая аномалия

Some Documentation for the IDL ICRED
Interim correlator data reduction Wrapper:

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.

How to make it go:
To begin ICRED start IDL and modify the path with:
!path='/home/emuller/IDLSCRIPTS/ICRED:/home/emuller/IDLSCRIPTS/MARKWARDT:'+!path
then type:
@icred
at the IDL prompt to excecute
(This has @phil and @corinit inside it, so you dont need to activate that compilation script separately).


At this stage, only a few processes have been ICRED-ised (type 'help'):

  • CorList - lists the scans for a specific project, or date
  • CorPosOnOff - creates files for spectra, temps and/or cal for a dataset
  • CorPlot - Plots a previously saves dataset
  • CorAvg - Averages Correlator data
  • CorAccum - Accumlates a record into a summary data
  • CorBL - Baseline a correlator dataset
  • CorMask - Interactively create a mask for each correlator board

  • Documentation:

    The wrapper operates by turning all inputs into strings. Parameter 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 in='mydatafile.icor'), or 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 way.

    The organisation of icred is split into three levels:
    1). the command interpreter: icred_interpreter.pro
        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 10,20).

    2) the task decoders: icred_<taskname>.pro
    once 'go' is typed, the interpreter sends the current parameter 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 existing 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 simply 'help', 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 current task, and the current settings.

    Exit: This quits totally out of ICRED and IDL.

    Other functions:
    There are two small programs which are used to 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.


    Last updated: 6th Feb.
    email me: emuller (at) naic . edu