NSCLSpecTcl, or simply SpecTcl for short, is a flexible programmable data sorting program. This chapter will
Describe some of the features of SpecTcl and the type of objects it understands.
Write a customized version of SpecTcl that will analyze the data produced by the event source we wrote in the previous chapter
Learn a bit about using SpecTcl by testing it with our event source
Learn about Tree Parameter and Tree Variables. A scheme originally developed by Daniel Bazin to impose structure on the unpacked data, as well as to provide easy access to Tcl variables that can be used to steer computations.
This section assumes that you:
Have an understanding of C++ that extends to class inheritence and virtual functions.
You have a packetizing event source from the previous chapter and the electronic setup to allow it to run, and take data.
SpecTcl is composed of about 183,000 lines of C++ code. Fortunately, it is an application framework, and you really don't need to know much about most of the code in order to make it create a wide variety of histograms from you raw data.
SpecTcl is data acquisition system and experiment neutral. This means that SpecTcl should be able to analyze data from any data acqusition system (it is configured by default to analyze data from the NSCL data acquisition system). It should also be configurable to analyze data from any experiment regardless of the event structure.
It is beyond the scope of this chapter to describe how SpecTcl can be interfaced to non NSCL data acquisition systems. See the reference material later in this book for information about this.
From the standpoint of SpecTcl, the difference between a pair of experiments run on the NSCL data acquisition system is just the format of the events they produce. This difference is handled by building a version of SpecTcl that is customized to the experiment. Customization consists of supplying code that transforms the raw events produced by the experiment's data source to a set of parameters that are histogrammed by SpecTcl. Throughout, the term event refers to a raw event received from the data source, and parameters refers to a set of parameters unpacked from this event by user code.
SpecTcl supports a multi-stage transformation from event to parameters. This multistage transformation is called the Analysis Pipeline. The execution of this pipeline will be loosely called unpacking an event.
The analysis pipeline is shown schematically below:
This figure shows that each element of the analysis pipeline has read-only access to the raw event, and read/write access to the parameters. When the last pipeline element has finished producing parameters, they are passed to the histogrammer for analysis. This implies that:
Pipeline elements can independently unpack subsections of the experiment. For example the packet associated with a single detector subsystem.
The Parameters serve as an event format independent storage that can be used not only to histogram parameters, but for stages in the pipeline that execute after specific parameters have been unpacked. This means that some stages of the pipeline, operating after the raw data have been unpacked can operate completely on the parameters to produce new computed parameters that may involve correlating data from multiple detector systems without needing to know the format of the raw events from any of these detector subsystems. For example, an element of the analysis pipeline run after S800 and SeGA raw data are unpacked could use the parameters to produce computed parameter such as total energy that can only be produced using data from both the S800 and SeGA, without knowing the event format of either device.
It is tempting to thing of Parameters as just a bunch of numbers
extracted from the experiment. Parameters are more than that, however.
Parameters know when they've been assigned a value. This knowledge must
be used in some cases to know when it is safe to compute parameters that
depend on other parameters not present in all events. Each parameter is
an object an its isValid() member function returns
true if that parameter has been assigned a value for
the event being unpacked.
The end goal of analysis is to get a visual picture of the data. To this end, SpecTcl supports a rich variety of spectra. Spectra can be created at any time, and, while some displayers of spectra may impose limits on the number of bytes of spectrum storage that can be loaded into the displayer at any time, SpecTcl itself does not impose any limits on the number or total size of spectra. These are limited only by virtual memory limits of the computer.
The following types of spectra can be produced by SpecTcl.
Simple spectrum of a single parameter.
Simple spectrum of two parameters.
The parameter is assumed to be an integer. Channels are incremented for each bit that is set in that integer.
A diagnostic spectrum for large detector systems. This is a 2-d spectrum with each x axis bin a parameter, and the y-axis the 1-d spectrum of that parameter.
A spectrum of several parameters that is incremented once for each parameter. If each parameter is the gamma ray energy from a single detector in an array, this spectrum will accumulate the gamma energy spectrum. Note that folds can be defined on these spectra in one or two dimensions to isolate sequential decays.
A spectrum of several parameters that is incremented for each pair of parameters. If parameters are gamma spectra, the clumps in this spectrum will represent 2-step sequential decays.
A spectrum of 2 parameters. The first parameter is the channel, the second parameter, an increment added to that channel for any specific event in which it is defined. The idea is that the first parameter will dwell on one value for some specified time or event count, and then advance to the next channel.
In addition given sufficient knowledge of the framework it is possible to produce and display application specific spectrum types. The Strip chart spectrum, for example, started out life as an application specific spectrum.
In many cases, the most meaningful spectra are those that are not incremented every run. SpecTcl provides a way to place event by event conditions on the increment of spectra. A gate is a condition that is checked for each event. A gate can be applied to spectra. When a spectrum has a gate applied to it, it will only increment for events that make its gate true.
SpecTcl provides for a wide variety of gate types, however in general, gates fall into two classifications, primitive and compound. A primitive gate depends on raw or computed parameters. A compound gate is one that depends on other gates. Compound gates allow you to create a gate that is essentially any logical combination of existing gates. This allows the creation of arbitrarily complex gates that can be applied to spectra.