These are CMSSW packages designed mainly to analyze HCAL calibration
data. All the analysis is done at the digi level, no reconstruction involved.
HcalPedestalAnalysis computes pedestal constants (means, widths and correlation
coefficients per capID) and does pedestal validation. HcalLedAnalysis was
written mainly for the time synchronization of all channels using LED and laser
data. With a couple of ad-hoc modifications, it can be also used to e.g.
detect muon signatures in the MTCC data, although it was not originally
designed for
this and more dedicated tools should still be developed. The main
analysis codes are under:
CalibCalorimetry/HcalAlgos/src/HcalPedestalAnalysis.cc
and
CalibCalorimetry/HcalAlgos/src/HcalLedAnalysis.cc
respectively. Below are a couple of examples how to use these packages.
2. Getting started with CMSSW
2.0. If you're working at FNAL, first set up the intial CMS environment:
source /afs/fnal.gov/files/code/cms/setup/cshrc uaf
2.1. If you have already installed a reasonably recent CMSSW version,
then go straight to 2.2 and skip also 2.4. Otherwise, create a new project area
(note that some useful features, like reading data from castor, may not work
with earlier versions):
scramv1 project CMSSW CMSSW_0_8_0_pre3
2.2. Go to the main source directory:
cd CMSSW_0_8_0_pre3/src
2.3. Create your CMSSW environment:
eval `scramv1 runtime -csh`
2.4. Get code from cvs repository:
cmscvsroot CMSSW
cvs login
(the latter you do only once in your life and pw is 98passwd)
cvs co -r CMSSW_0_8_0_pre3 CalibCalorimetry/HcalStandardModules
cvs co -r CMSSW_0_8_0_pre3 CalibCalorimetry/HcalAlgos
2.5. Click here to get the latest version
of the somewhat modified analysis packages and user scritps,
2.6. Place the tarfile you've just downloaded in your current working
directory (src) and unpack it there:
tar xvf michals_stuff.tar
2.7. Compile it
cd CalibCalorimetry
scramv1 b
2.8. Go to the test directory where you can run the jobs:
cd HcalStandardModules/test
2.9. You're ready to go! It is sometimes convenient to redefine your
CMSSW_SEARCH_PATH so it contains the root directory and your current directory
(although in the present setup is not really necessary) - for this there is a
little script provided that you need to source (if you don't like its
name, feel free to change it).
3. Getting acquainted with user scripts
3.1. You always need to provide the correct cfg file (which should
contain info on which DCC to unpack, etc.) and the correct electronic map
for the kind of data you want to analyze. At the present moment,
the package contains two csh scripts that contain
the appropriate cfg files to analyze early MTCC data.
Use run_mtcc to read global DAQ data, or run_moe3 to read
local HCAL DAQ data (cmsmoe3). For some of the first MTCC runs
(with only HE+ sector 14 cabled up, that's global runs up to 1503, I think),
you in addition need to
edit run_mtcc, change the electronic map name to mtcc_he_only.map and
remove 702 and 703 from the FED list).
3.2. Edit run_mtcc.
- The script expects 3 arguments in the command
line: the run number, the first
file number to analyze and the last file number to analyze (some global DAQ
runs are split into many data files).
- The main body of the script is a loop
over the user defined input data files. For every data file, the script will
create an appropriate config file mtcc1.cfg and run cmsRun with it.
The contents of mtcc1.cfg are defined by whatever is between the two %
signs.
- The "source" line in the cfg defines data file names.
By default you may read files stored in castor; if you're on cmshcal01, you may
also choose to read from /bigspool.
- Following lines contain module names
along with parameter settings that will be used for the execution of each
module. Which modules should be actually activated, is defined in the
"path p = ..." line. In our case, path will contain only HcalRawToDigi
(nicknamed unpacker)
and one of our two analysis packages (nicknamed analpeds and analleds).
The last lines ("HcalTextCalibrations") define the electronic map file to
be used.
- After the input file loop is completed, additional user analysis on the
output files can follow, if desired.
3.3. Edit run_moe3. Its structure is very similar to run_mtcc. Relevant
differences are:
- It needs only one argument in the command line: the run number.
- A different type of DAQ is reflected in the "source" definitions and
choice of user parameters for HcalRawToDigi.
- Data files are expected on /bigspool and cannot be accessed from lxplus.
- The electronic map is different.
4. Getting pedestal constants
4.1. Edit run_mtcc and set "maxEvents" to 1000 (enough for our purpose).
4.2. Make sure HcalPedestalAnalyzer is in the execution path.
4.3. Run it! Example:
./run_mtcc 1545 0 0
4.4. When the run is completed, you should get 3 output files:
peds_mtcc_1545.txt
widths_mtcc_1545.txt
peds_mtcc_1545.root
containing respectively: all the pedestal means, the pedestal widths and
some pedestal histograms (by default not many of them, unless you select
hiSaveflag = 1 in your cfg).
5. Doing pedestal validation
5.1. Edit run_mtcc and uncomment the first two parameters in module
analpeds. Then, set pedValflag = 1.
The pedestal constants you just created in point 4 will
now be used as reference values to check pedestals computed from another run.
5.2. Run it on a different data sample. Example:
./run_mtcc 1544 0 0
5.3. You should get the standard 2 output txt files for run 1544 and
in addition the pedestal validation logfile:
HcalPedestalAnalysis.log
If all pedestals were found consistent with reference values, the logfile
will contain just one line: "All pedestals checked OK". Otherwise, a
detailed printout will be made of which channels/capIDs have changed and
by how much. Any channel or capID that was off in the reference run, but
present in the current run, will show up in the same way (in this case the
reference value will be quoted as -1).
5.4. As an exercise, you may change or delete some entries in
the reference pedestal file (but you'd better rename it and save the original
one, because you may still need it below for point 7) and rerun pedestal
validation. Unless your
changes were insignificant, they should all show up in the logfile.
If you wish to save the logfile you must rename it, otherwise the next
HcalPedestalAnalyzer run will overwrite it.
6. Checking pedestal stability in a long run
6.1. Let us process the local HCAL DAQ run 344 (long one). Edit run_moe3.
The user parameter "nevtsample" in HcalPedestalAnalyzer allows to divide
the input data into samples and compute pedestal constants sample by sample.
As an example, set nevtsample to 1000.
6.2. Run it!
./run_moe3 344
6.3. In your output root file
peds_sx5_344.root
you will get histograms of pedestal
stability: pedestal value vs sample number for each channel (click on
folder HB). You should also find a histogram with all the mean values
and the chi2 for each pedestal being constant in time.
If you have selected hiSaveflag=1, you will get
the standard pedestal histograms for each single sample, too.
7. Looking for cosmic muons with HcalLedAnalyzer
For this exercise, the HcalLedAnalyzer package has been modified
from the original. In addition to the standard pulse shape based analysis,
it will look for events in which the signal, summed over all time slices,
exceeds the pedestal by 10 fC or more: an alleged signature of a muon. The
time slice structure of these events will be dumped (in
ascii) in the logfile. At the end of run, a little fortran program
(lookformuons.f) is
called which scans thru all the outputs and counts how many muon candidates
were found at each eta/phi tower and in which time slice is the signal
peak. Real muons should
show up as an enhancement in the number of selected events, visible in all
the "good" eta/phi towers, at some time slice. In addition, two dimensional
eta vs phi event dumps of selected events are available in the logfile, which
allow to study the energy distribution of the whole event. Volunteers are
welcome to provide a tool for graphical display of the results.
7.1. Edit run_mtcc. Increase "maxEvents" to 100000 and replace
module analpeds with analleds in the execution path. We will now use the
pedestal
file from run 1545 as input to apply pedestal subtraction - see first user
parameter in module analleds.
7.2. Run it! Example:
./run_mtcc 1545 0 0
7.3. After some time you should get a printout on the screen: the
number of candidate muons per time slice in each Phi sector involved.
Can you see where the muons are? Which Phi sectors were working fine,
which ones were switched off and which were reading out garbage?
7.4. Additionally, the program ouputs files:
led_mtcc_run*.txt
led_mtcc_run*.root
which contain the mean timing per channel and histograms of pulse
shape, respectively. You may want to have look at their contents; for the
kind of data that we have just read, however, they are not particularly
useful.
7.5. As an extra exercise, look for muons also in the local HCAL DAQ
run 344. Can you see them?
8. Reading TB06 data (under development)
8.1. Using e.g. run_moe3 as a template, create a new dedicated
script to read TB06 data. Here's some hints:
- The data files are available on disk under
/bigspool/cmsmoe3/HTB_xxxxxx.root, where xxxxxx should be replaced by a
6-digit run number
- Presently, the good pedestal run numbers are: 99, 100 and 101
(csh fact: if you give as argument a number that starts with 0, you may
need to type it in quotation marks).
- Set the event limit to 1000.
- The DCC to unpack is 700 - this number should replace the 20 of
run_moe3 (in four places!).
- The electronic map to use is emap_mtcc_mod.txt.
- Make sure all the HcalPedestalAnalyzer user parameters and your
execution path are set accordingly to what you want to do.
8.2. Run it! If you succeed the first time, congratulations!!!
Last update: Jul 18 2006, 21:40.
Questions and comments to Michal.Szleper(at)cern.ch