Chapter 1. Orientation
This chapter will provide you with an overview of the structure of the NSCL data acquisition system. This chapter assumes you have the following:
An understanding of how experiments in nuclear physics are done
An very basic knowledge of computer programming fundamentals independent of implementation language.
Motivation to make your life easier by using existing tools if they are suitable, rather than building everything from scratch
This chapter is divided in to the following sections:
Model for the NSCL system lays out a high level model that describes the structure and key assumptions of the NSCL data acquisition system.
What the NSCL DAQ System Provides describes the high level facilities the NSCL Data Acquisition and analysis system provides to an experiment.
What must be done to create an experiment Describes the tailoring that must and can be done to create a complete experiment using the NSCL Data acquisition and analysis software.
Resources provides a description of resources that may provide additional supporting information about this topic, as well as starting points for your work.
 | While you may be able to get some work done without understanding the material in this chapter, you'll be able to get far more work done if you do make the effort to understand this chapter. |
1.1. Model for the NSCL system
When we think of a data acquisition system, it is easy to confuse the components of the system with which you interact, with the system itself. In this sense, a data acquisition system is very much like an iceberg. You will interact with the minority of the system software that pokes up above the waterline, for the most part not noticing, the majority of the system, which operates, hopefully, invisibly and correctly.
In order to be able to understand how to troubleshoot a system which is not working correctly, it is useful to step back from the part of the data acquisition system iceberg that is above water and look at what a data acquisition system truly is.
The figrure above provides a simplified model of a generic data acquisition system for nuclear physics. The experiment generates events which the system captures in some event source. The system then distributes these events to sinks which operate on these events in various ways specific to each sink.
Viewed in this way, recording data for later analysis is just the function of a sink that accepts events and records them to disk or tape. Analyzing the online data is just the function of another sink that accepts events and histograms them. Other experiment specific, and experiment non-specific event sinks could, in theory be added as needed if this underlying data flow system supports this programmatically.
At the NSCL, this generic data acqusition system model is realized as shown in the figure below.
It is worth pointing out several features of the figure above:
The entire system is enclosed in a box labelled System integration components. This indicates that in many cases there will be a desire to wrap the finished system in a set of components that makes the parts seem like a unified whole rather than a set of cooperating components. This is convenient to the end users of the software, but can also hide critical debugging information when things go wrong.
The box labelled Readout is the event source for the system. It is usually wrapped in a component named ReadoutGui which provides a graphical user interface for controlling data taking. This graphical user interface is often mistaken by end users of the system for the actual readout program.
The box labelled spectrodaq provides an active fanout of the data to the event sinks. This fanout is a two-fold fanout: Any process within the same computer as the Readout software can be an event sink. Any process on any other system running Spectrodaq at the NSCL can be an event sink. An important part of experiment design is deciding how to distribute your processing amongst the computers that are available to your experiment. An important part of troubleshooting system hangs is to determine which systems have event sinks attached, and what those sinks are doing. Spectrodaq allows its clients to selectively take data. This selectivity can take the form of selective delivery of only some types of data, delivery of data sampled only at the rate the sink can handle, or a combination of these two selection criteria.
We show three stock sinks. These sinks have already been written and do not require any user programming to tailor them:
Eventlog - records event data to disk for later offline analysis.
spectcldaq - Accepts data from spectrodaq and transfers it to stdout. This makes it an adaptor to software that is not aware of the data acquisition system. Usually spectcldaq is used as a pipe data source to SpecTcl, however it could, in principle, be used to provide data to any program. Spectcldaq makes use of spectrodaq's selective data distribution. It requests that data containing physics events be sent only at the rate at which it can be relayed to stdout. This prevents the client program typically attached to stdout from being a rate bottleneck of the system. Note that non event data (e.g. run state change information) is sent without any sampling, so it is possible for a hung client to starve the data acquisition system of buffers.
sclclient - Accepts only scaler and state change data from the from spectrodaq and interacts with a tclserver to maintain a set of variables in that server that can be used to provide a run time display of scaler values. Usually, the ScalerDisplay program is connected to this program as shown.
Note that the bulk of the data flow shown in this system is down the figure from source to sink. Usually the bulk of the tailoring of the system for a particular experiment will be done at the 'edges' of the system, rather than in the middle. This is an important point to keep in mind. It allows you to fixate on the tip of the software iceberg, rather than getting enmeshed in the entire software structure. As we look at the system in more detail we'll see other mechanisms that allow you to further narrow your view of the system so that you can concentrate on the work you have to do without having to understand the larger structure of the system.