As it was said in the introduction, the user should not be concerned with technical aspects of data processing. This is -- to a large extent - true for the current version of YODA. To be independent of the experimental setup, the user must, however, provide some ''technical'' information once for each experiment. This will be discussed below.
To access data inside the subevents, YODA uses a user-supplied ASCII file which connects data fields with symbolic names. This file is called the selector database, and must exist in your working directory.
It contains a one-line entry for each distinct data element. Each line
has the following form (lines beginning with # are comment lines
and are ignored):
NAME DATATYPE CONTAINERTYPE C.SUBTYPE SUBEVENTTYPE S.SUBTYPE BYTEOFFSET [DIM]
Each such line is called a selector. (The square brackets around
DIM denote an optional value.)
NAME is a symbolic name chosen by the user, which makes the
data accessible to the user tasks. The data described by the selector
is copied to a variable with the name NAME into the set of
variables for every user task, which has ''linked'' to this selector.
Then, the user task is called and can process the data. After that,
the next containerevent is processed. If another match occurs, the
variable is overwritten with the new value, the user task is called
again and so on.
Once a user task chooses to investigate a certain piece of the data
(defined by a single line entry in the selector database), the
incoming containerevents are scanned by the YODA program to match the
indicated combination of containerevent type and subtype and subevent
type and subtype. If one of these fields is not significant for the
selection, it can be chosen to be ignored by specifying a 0
(zero) for the corresponding type or subtype field.
To select e.g. each and every subevent from the incoming datastream, you
would specify a combination of four zeroes for the containerevent-
and subevent- type and -subtype fields. (You would then -- except in
rare cases -- have problems determining DATATYPE as well as
BYTEOFFSET and DIM, see below).
When a subevent with its enclosing containerevent matches the type and
subtype criteria, the data is regarded as DATATYPE, where
DATATYPE can be one of char, uchar, short,
ushort, long, ulong, float or
double. This set corresponds to the standard datatypes of the
''C'' language, with uchar, ushort and ulong
meaning unsigned char, short and long,
respectively.
The last but one field in the line specifies the offset in bytes from the beginning of the selected subevent's data, where the desired data is to be found. This provides a means for skipping unwanted data inside a subevent, or addressing heterogeneously structured data.
The last field (DIM) determines the number of elements (all of type
DATATYPE, see above), which is to be selected from the
subevent's data field. This implies, that NAME is to be used as
an array (a vector) inside the user tasks. This feature is used to
address homogeneously structured data, e.g. a set of ADC values
belonging to subsequent channels, which will all be processed in the
same way.
If the last field is (DIM) is omitted, NAME is used as a
''simple'' variable inside the user tasks.
Your front-end readout routine (or your simulation package, whoever produced the data) determines which types and subtypes actually occur in YODA's input datastream. Look at e.g. your readout routine to see which types and subtypes are employed to label the containerevents and build your selector database accordingly. (Probably, this is already done for you. Ask your local expert).
If you have no idea which types/subtypes are actually used, you can
use an event dumping program like e.g. the server program. This
program is used for the setup at the ISKP to swap the rawdata into the
correct byteorder. It can also be used to dump the events as they are
processed.
If the data is e.g. coming from a tape devnrmt0h/ in tar
format, you would enter:
server -t /dev/nrmt0h -v | more
This will provide you with a full dump of the rawdata events, listing all type and subtype information.
If you have no idea what the data means, you're in trouble anyway. You then have almost no chance to do suitable analysis with it. (This situation is about to be improved. Some efforts are going on to make the data format somehow ''self-documenting'', so the user does not even know about types and subtypes. Instead, they are chosen automatically by the front-end data producing program (e.g. the data acquisition) and hidden inside special ''info''-containerevent.)