73
edits
Changes
Jump to navigation
Jump to search
Line 47:
Line 47: − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Aaron Carta Undergraduate Research Progress, Fall 2013 (view source)
Revision as of 21:23, 23 December 2013
, 21:23, 23 December 2013→ROOT
Halldtrg5 is equipped with CODA 2.6.1, which is written entirely in C, C++, and the Tcl scripting language. It also incorporates MSQL databases, which are used to configure particular run control setups. This is described in detail [[Creating/Editing mSQL Databases for CODA|here]].
Halldtrg5 is equipped with CODA 2.6.1, which is written entirely in C, C++, and the Tcl scripting language. It also incorporates MSQL databases, which are used to configure particular run control setups. This is described in detail [[Creating/Editing mSQL Databases for CODA|here]].
The central component of CODA is RunControl. RunControl consists of two components: a GUI called runcontrol, written in C++, which is activated with the command "rcgui", and a server called rcServer. The procedure for preparing an executing a data run is described in detail [[Procedure for Operation of CODA Run Control|here]].
The central component of CODA is RunControl. RunControl consists of two components: a GUI called runcontrol, written in C++, which is activated with the command "rcgui", and a server called rcServer. The procedure for preparing and executing a data run is described in detail [[Procedure for Operation of CODA Run Control|here]].
My work with CODA primarily consisted of familiarizing myself with its construction/operation, which necessitated learning a lot about C++. I had little programming experience at the start of the semester (other than working a lot with Mathematica, and some tinkering in Python), so this took up a lot of time. The lack of documentation about this version of CODA also led to several setbacks (the latest version for which I was able to locate a User's Manual was 1.4).
My work with CODA primarily consisted of familiarizing myself with its construction/operation, which necessitated learning a lot about C++. I had little programming experience at the start of the semester (other than working a lot with Mathematica, and some tinkering in Python), so this took up a lot of time. The lack of documentation about this version of CODA also led to several setbacks (the latest version for which I was able to locate a User's Manual was 1.4).
The basic setup for which halldtrg5 was configured included a read-out controller (ROC) and an event builder (EB). I wrote short scripts to activate both of these components before starting the RunControl GUI. It was also necessary to start the AFECS platform and the mSQL daemon before starting the RC GUI. The first is the basic framework on which CODA operates, the second allows CODA to use mSQL databases, which are integral to its operation. The AFECS platform is initialized on halldtrg5 with the command "platform", while the scripts for the ROC and EB are "\home\halld\start_roc" and "\home\halld\start_event_builder", respectively.
'''Images of RunControl Gui During Data Acquisition'''
<gallery>
file:codarcscreenshot.jpeg
file:codarcerror.jpg
file:codarcpopup.jpg
</gallery>
CODA has a characteristic format for the data files that it outputs. These are exported from halldtrg5 to gluey via an NFS link. As mentioned earlier, this is for the dual reason of preserving halldtrg5's flash memory, but it also allows for easier access to the data files for analysis. In fact, the CODA output format is essentially useless on its own, and must be interpreted and converted to a useful format. This is accomplished via the Event Analyzer program, which is described below.
==Analyzer==
==Analyzer==
In order to be able to analyze the data collected by the halldtrg5 VME crate, it's necessary to convert the CODA output files to a more useful, user-friendly format. In this case, we have chosen to convert the CODA files to .root files.
The analyzer, written in C++, opens the CODA file, and is currently configured to read from an fADC and F1TDC (see above for descriptions). The CODA file consists of events from a data run with these two components in operation. The analyzer was initially configured to read from two fADC's and one F1TDC, so this necessitated some reconfiguration. Once the analyzer opens the data file, it creates a .root file with the same name, loops over each channel included in the data file, and extracts events from these. From these events, the analyzer constructs an event tree (an n-tuple in ROOT), which is a file object that can be read by ROOT. The number of components of the n-tuple/tree is based on the number of active channels in the data run. 1D and profile histograms are then constructed from the n-tuples obtained from the fADC (which is essentially the primary readout controller in this particular setup, and thus the parsing/processing of of the data from the fADC makes up a sizable portion of the analyzer).
Since, as mentinoned before, I was relatively inexperienced with programming at the beginning of the semester, there was a relatively steep learning curve, as there are few comments and no documentation for the Event Analyzer file that was included with Halldtrg5, and this file was only intended to serve as an example. With the help of Alexander Somov from Jefferson Lab, I was able to make some sense of the analyzer, and use it to create .root files from my test set-up with the function generator.
I encountered a major problem at the end of the semester when I discovered that the set-up that I had been using was not exactly suitable for the testing that Dr. Jones and Alex Barnes had planned to do on the optical fibers. I had to incorporate an Event Recorder into the data acquisition run, by creating an mSQL database for CODA that included an Event Recorder. However, this lead to strange error messages when trying to initialize data runs, which I could resolve only by removing the Event Recorder from the database. This is not a feasible solution, since this prevents usable events from being recorded in the CODA output file. Without events, the Event Analyzer has nothing to export to the .root file. I plan to try to resolve this issue during the winter intersession. I have been speaking with Alex Somov some more regarding this, and hopefully he will be able to shed some light on how to fix this issue.
==ROOT==
==ROOT==
ROOT is a C/C++ based, object-oriented computing framework designed by CERN to efficiently process and analyze large amounts of data, e.g. from high-energy physics experiments. ROOT has an incorporated C/C++ intepreter, CINT, which is written in C++ itself.
The work I did learning C++ was most useful for ROOT. Trying to follow the construction of the Event Analyzer was one thing, creating new macros/scripts for use in ROOT, to facilitate data analysis, was a different matter entirely. My first successful endeavor was a relatively short macro, found on gluey at \home\acarta\ROOT\simplegraph.C, which allows for plotting measurements from a simple .txt file. I spent a good deal of time plotting and fitting measurements taken by Fridah Mokaya. It took me quite a while to get used to the objects and classes in ROOT, which differ from standard C++, as well as the various options and procedures for creating plots in ROOT. Especially troublesome was the use of the TCanvas objects, in particular trying to add multiple plots to the same canvas.
<gallery>
file:Test_spectrum.png | A sample plot from ROOT, created from some calibration measurments.
</gallery>
I initially thought that this macro would serve only as an exercise for my own benefit, but it turns out that my colleague John Bartolotta was able to use the simplegraph.C macro for his own work on the active collimator. The Labview program he is using apparently outputs .txt files, so this macro is well suited to his purposes. Since he was completely new to ROOT and programming at a later point in the semester, I spent some time working with him to help him get started on plots and fitting, which help give me a better grasp of ROOT as well.
Being able to construct and analyze histograms is more important for my own purposes, however. The analyzer is already equipped to construct histograms, but the data-files that I have been applying it to thus far are not suitable, as they contain no events. I was able to create some histograms using data from past lab classes, so once I resolve this particular issue, I should be able to get useful histograms from our DAQ station.
My immediate goal is to work towards resolving this issue during the winter intersession, after the Christmas holiday.