|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
<html>
<body>
<font size=+2><tt>CSCTFRawToDigi</tt></font> package performs unpacking
of raw CSC Track-Finder data. It is unlikely that you need it,
unless you are explicitly working with CSC TF data (for Data Quality
Monitoring or hardware validation purposes). So far no High Level Trigger
algorithms are known to use this kind of information.
<br>
<br>
The package is built around a set of core unpacking classes. Those are
accessors:
<tt>CSCSP_MEBlock</tt>, <tt>CSCSP_MBBlock</tt>, <tt>CSCSP_SPBlock</tt>,
<tt>CSCSPHeader</tt>, and <tt>CSCSPTrailer</tt>
and containers:
<tt>CSCSPRecord</tt>(also accessor), <tt>CSCSPEvent</tt>, and <tt>CSCTFEvent</tt>.
Accessors are essentially bit field classes, which directly map corresponding
raw data blocks. Containers hold clones of accessors and other containers
in a certain hierarchy. For references see
<a href="http://grid.ihepa.ufl.edu/~kkotov/LU-SP2DDU_Event_Record_Structure_4d1.pdf">hardware specification</a>.
<br>
<br>
The core unpacking classes can be easily compiled in a stand-alone executable.
An example can be found in
<a href="http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/CMSSW/EventFilter/CSCTFRawToDigi/test/test.cc?rev=1.1&cvsroot=CMSSW&content-type=text/vnd.viewcvs-markup">
test/test.cc</a>. If you want to use it you need to install CSC file reading
package in your local CMSSW installation (you don't need to compile it):
<br>
<b>cvs checkout -P IORawData/CSCCommissioning</b>
<br>
Go to EventFilter/CSCTFRawToDigi/test and comlipe the package:
<br>
<b>cd EventFilter/CSCTFRawToDigi/test</b>
<br>
<b>g++ -o test test.cc -I../../../</b>
<br>
After that you can run it on any CSCTF .raw data file:
<br>
<b>./test YOUR_RAW_FILE.raw</b>
<br>
<br>
The package is interfaced to CMSSW with help of 2 modules: <tt>CSCTFUnpacker</tt> and <tt>CSCTFPacker</tt>.
<br>
<br>
With parameter <i>producer</i> of <tt>edm::InputTag</tt> type the unpacking module can
be instructed to query <tt><a href="https://twiki.cern.ch/twiki/bin/view/CMS/WorkBookCMSSWFramework#ProcModel">edm::Event</a></tt>
for data buffers from particular producer (by default this is <tt>source:</tt>).
<br><br>
<font color=red>If you are analyzing 2008 data, you may skip the reset of this paragraph
and go to next one.</font><br>
Every Sector Processor board (SP) of the CSC Track-Finder crate is connected to
1 of 12 sectors. The firmware on every board should be configured so, that board
reports which sector it is connected to. Unfortunately, this was not a routine
configuration procedure during <a href="http://cms-emu-slicetest.web.cern.ch/cms-emu-slicetest/">CSC SliceTest</a>,
and most of our data, taken earlier than August of 2007, lack this information.
Nevertheless, this can be fixed off-line with help of
integral array-parameter <i>slot2sector</i>. In general it has 22 entries (same as
number of slots in CSC Track-Finder crate) which can be set to either 0 or sector number (1—12).
0 instructs module to use original sector number from data, while numbers from
1 to 12 override it with corresponding value.
If you work with the <a href="http://cms-emu-slicetest.web.cern.ch/cms-emu-slicetest/">CSC SliceTest</a>,
data you probably need default settings of
<a href="http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/CMSSW/EventFilter/CSCTFRawToDigi/data/csctfunpacker.cfi?revision=1.4&view=markup">
data/csctfunpacker.cfi</a> or you may want to change the first value of <i>slot2sector</i>
array which assigns data from any "unconfigured" SP to sector number, which you set there.
For raw data obtained in simulation (see below) you need to set all values to 0.
<br>
<br>
Supplementary <tt>CSCTFPacker</tt> module helps to generate "fake" raw data file
from CSC TF digi. It can be instructed to use digi from certain producers by setting
<i>lctProducer</i> and <i>trackProducer</i> <tt>edm::InputTag</tt>s accordingly.
It is likely, that you don't need to change other parameters from their default
values (<i>zeroSuppression=true</i> and <i>nTBINs=7</i> are hardware defaults).
One additional parameter, <i>activeSectors</i>, allows to "skim" data from some
particular sector(s). Any of its 12 bit may be set to 1 or 0 allowing
of denying data from corresponding sectors to be converted to raw buffers.
If you are validating some of SP boards you are likely to set only one of these bits.
Output is controlled by two parameters: <tt>outputFile</tt>, which sets file name
for storing data in local_DAQ-like format (make it an empty string "" if yo don't
need these files), and <tt>putBufferToEvent</tt>, which specifies if
<tt><a href="https://twiki.cern.ch/twiki/bin/view/CMS/WorkBookCMSSWFramework#ProcModel">edm::Event</a></tt> will be populated with raw data buffers. See
<a href="http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/CMSSW/EventFilter/CSCTFRawToDigi/test/writedigis.cfg?view=markup">
test/writedigi.cfg</a> for example of usage.
</body>
</html>
|