4.4. Directory structures.

4.4.1. Directories maintained by ReadoutGUI

Readout Gui maintains two directory trees. Prior to nscldaq-8.0, one of these trees was located in the user's home directory, while the other was located in the event area. With the introduction of nscldaq-8.0, both subdirectory trees are located in the event area, while the user's home directory contains a set of symbolic links that maintain the same appearance to the user as the system prior to 8.0.

The first directory tree maintains the bulk event data. It provides a view of the experiment that is based on the event files that have been taken during the run. When doing bulk analysis, it is usually best to work from this view as it allows you to operate on several event files. A map of this ditectory is shown in the example below:

----+
    +-------> current     
    +-------> complete    

                    

This directory tree is called the stagearea. It is located in the directory pointed to by the EVENTS environment variable or, if that is not defined, in the directory pointed to by the symbolic link ~/stagearea.

Each run will have one or more event files. Each of these event files (or event file segments as they are more properly called) will be at most 2 Gbytes. This segmenting allows event files to be manipulated through NFS and other file systems that limit the size of a file to 2 Gbytes.

The first event file of a run will always be named runnnn-buffersize.evt where nnn is the run number and buffersize is the number of words in each buffer of data written to file (typically 4096).

If additional event file segments are required (the run requires more than 2 Gbytes of data), the additiona files will have names like: runnnn_segnum-buffersize.evt nnn and buffersize are both defined as in the previous paragraph. segnum is the segment number. Segment numbers start at 0 (the first segment).

The second set of directories maintained by the ReadoutGUI provides a view of the experiment from the point of view of packaged run data. Packaged run data means the event file along with whatever other data the user has associated with the run. See the next section for a description of how to associate data with the event files of a run.

A schematic of this second set of directories is shown below:

----+
    +----> current  
    +----> run1
    +----> run2     
    +----> ...
    ...
                    

4.4.2. Associating data with event files

One of the purposes of the EXPDIR view of the experimental files is to allow you to associate data files with the event files for a specific run. This section describes how this works and what you should do.

At the end of a run, Readout GUI does several things to maintain the views we have described:

• Event files are moved from the current directory to the complete directory in the EVENTS view. The move (not copy). In Unix/Linux, file moves just require directory operations, rather than requiring a copy of the contents of a file.

• The contents of the current directory of he EXPDIR view are copied to a new runnnn directory for that run. Unless the file is a symbolic link to an event file segment, the file pointed to by that link is copied, rather than just copying the link. Links to event file segments are adjusted to point to the event file segment in the complete directory of the EVENTS view. This copy recurses through any subdirectories that have been defined in the current directory, including symbolic links to directories.

From a practical point of view, this means that each run directory in the EXPDIR view can be viewed as a snapshot of the contents of the files that were in the current directory at the time the run ended. Therefore, to associate data with a run, copy it, or link it into the current directory prior to ending the run.

Let's take a simple, but instructive example. Suppose we are runinng an experiment with a pair of detector systems. Call them sys1 and sys2.

Detector system sys1 has configuration files that must be modified for the specific experiment located in ~/daq/sys1/config. Similarly, sys2 has configuration files in ~/daq/sys2/config. Suppose these configuration files contain information that may vary from run to run. It would be good to associate these files with each run so that when you analyze your data, you are able to know the contents of the configuration files at the time of each run.

The commands below describe how to accomplish this, if EXPDIR either points to ~/experiment or is not defined:

mkdir ~/experiment
cd ~/experiment
mkdir config
cd config
ln -s ~/daq/sys1/config sys1
ln -s ~/daq/sys2/config sys2
                    

Now directory for run1234 in the EXPDIR view of the experiment will have the following structure.

-----+
     +----> run1234-4096.evt
     +----> config
              +-----> sys1
                        (config files for sys1).
              +-----> sys2
                        ( config files for sys2).
      (other associated files).
                    

Note that in this example, run1234-4096.evt is a symbolic link that points to the event file in the complete subdirectory of the EVENTS view of the experiment. The sys1 and sys2 directories contain the contents of the directories ~/daq/sys1/config and ~/daq/sys2/config respectively as of the time the run ended.