YODA is an abbreviation for Yet another Online Data Analyzer, which is chosen in analogy to the name of the famous YACC program ( Yet Another Compiler Compiler).
YACC is a standard program in the UN*X programming environment, and generates compilers, interpreters and so-called parsers in general from a formal definition of the language to be used. YODA contains such an YACC-generated interpreter to give the users utmost flexibility in controlling their data analysis while retaining the comfortable features of an interactive program.
YODA enables the user to access experiment data coming from a tape, a disk file or directly from the running experiment, perform almost arbitrary processing on the data, and then create statistically accumulating objects like 1- or 2-dimensional histograms and define 1- or 2-dimensional cuts graphically during analysis.
Equipped with a programming language looking similar to C, and
with functionality and simplicity at about the level of BASIC,
users can realize their data processing in form of user tasks, which
are (typically small) files containing the appropriate analysis
procedures. Experimental data is accessed in form of simple arrays or scalar variables, with names freely chosen by the user to
reflect their proper meaning in the experiment's context.
These analysis tasks can be loaded and unloaded dynamically during the running data processing. This allows the user to add new tasks without having to stop the analysis. It also provides the possibility for rapid development of analysis routines.
The generated histograms and plots can be displayed by the YODA program itself, or alternatively by a separate tools for visualization. This makes it possible to monitor the progress of analysis while it is running. This suits the needs for ''online''-processing of data.
Apart from YODAs own display (named ZONI) PAW++ or pawX11 from the CERN program library ist used for histogram display. Data transfer between YODA and PAW can be accomplished via a shared memory area (not available for DIGITAL ALPHA architecture) or by files. See the discussion of PAW++ later in this manual. This is not a manual on PAW or PAW++, however.
The current version uses a data format as described in section 3, providing a comfortable means of structured data access. Especially rawdata coming from different subdetectors can be handled independently. Calculated or already pre-processed data e.g. from a simulation package can be integrated homogeneously and selected just as well as rawdata events. It is also possible to adapt the program to a different format of input data. People wishing to do so should read the appendix.
YODA's interpreter tries hard to weaken the major drawback of interpreters in general: the lack of speed in contrast to compiled programs. In fact, the user's analysis tasks are compiled into a pseudo-machine language, not interpreted line-by-line. This compilation process is normally invisible to the user (except for producing error messages for syntactically incorrect programs). For typical applications, a throughput of 100-1000 events per second on a cheap workstation was observed.
However, the YODA interpreter language has its limits. Track recognition in drift chambers, kinematic ``fits'' or high level trigger decisions involving a memory and/or cpu intensive treatment of the data is usually beyond the performance (and the abilities) of the interpreter language.
But for such applications, there exists a conventional programming
interface for people who are familiar with C++, giving full and
comfortable access to the incoming data as well as the histogramming
features of yoda. Furthermore, the results of such a lengthy
calculation can again be ``fed back'' into YODA, giving the user the
chance to operate on them indistinguishable from true rawdata in the
interpreter framework. For a closer look, see section 7.2
In this context, YODA can also be used to work as a filter program. Events can be analyzed and saved according to physical criteria for further analysis.
Sometimes it is sufficient to enhance the interpreter language by introducing new subroutines or functions, which are callable from the user's tasks and operate at full, compiled speed. Such an enhancement of the interpreter language is in fact very easily done (see section 7.1).
Even without such enhancements, the benefit of rapid changes to the analysis being possible often results in a significant gain in analysis speed, outweighing the speed-lack of interpreted code.