1 How to test the Shuttle preprocessor(s) for MUON.
3 We will get two "logical" MUON preprocessors : one for the tracker and one for the trigger.
4 Both will manage several subtasks (e.g. the tracker one will handle pedestals,
5 gains and deadchannels, while the trigger one will handle masks and trigger lut)
6 "Physically", only one class will manage both the tracker and the trigger : AliMUONPreprocessor.
7 Depending on the subsystem and on the task to be performed (based on the run type), this class
8 will instanciate the correct set of AliMUONVSubProcessor(s) which does the actual job.
9 Output of most processors will end up in OCDB (Offine Condition DataBase). A set of helper functions
10 to peek at this OCDB are gathered in MUONCDB.C macro.
13 TestMUONPreprocessor.C
16 This is the master macro used to check the MUON part of the Shuttle.
17 Depending on what you want to test, you'll have to modify the input files
18 (using shuttle->AddInputFile) and/or the run type (using shuttle->AddInputRunParameter())
21 AliMUONPreprocessor(const TString& detName)
24 Depending on how this one is constructed, and depending on the runtype, it will
25 perform differents tasks. Note that for the moment the runtypes are "fake", i.e.
26 put by hand in the TestMUONPreprocessor.C macro, and might not correspond to
27 the final values to be used by the DAQ.
29 detName runType task to be done worker class (AliMUONVSubprocessor child)
30 --------------------------------------------------------------------------------------------------------
31 MCH PEDESTAL_RUN read ASCII ped files AliMUONPedestalSubprocessor
32 and put them into OCDB
34 MCH GMS read GMS alignment files AliMUONGMSSubprocessor
35 and put them into OCDB
37 MCH PHYSICS read DCS HV values and AliMUONHVSubprocessor
40 MCH ELECTRONICS_CALIBRATION_RUN read ASCII gain files to be done
41 and put them into OCDB
43 MTR to be defined to be defined to be done
49 Two options here. You can either use a pre-done set of ASCII pedestals files (generated as
50 explained below for the 2nd option), located at /afs/cern.ch/user/l/laphecet/public/LDC*.ped,
53 We've written an AliMUONPedestalEventGenerator which creates fake pedestal events. The pedestal values
54 are taken from the Offline Condition DataBase (OCDB) (which is itself fakely filled
55 using the writePedestals() function located in the MUONCDB.C macro.
57 So first generate a valid pedestal CDB entry but using the MUONCDB.C macro.
60 root[] const char* cdbpath="local://$ALICE_ROOT/SHUTTLE/TestShuttle/TestCDB"; // where to put the CDB
61 root[] Bool_t defaultValues = kFALSE; // to generate random values instead of plain zeros...
62 root[] Int_t startRun = 80;
63 root[] Int_t endRun = 80;
64 root[] writePedestals(cdbpath, defaultValues, startRun, endRun);
66 Expected output is (don't worry about the warnings, they are harmless) :
68 W-AliMpExMap::AddKey: AliMpExMap::AddKey: resized Key array
69 W-AliMpExMap::AddKey: AliMpExMap::AddKey: resized Key array
70 W-AliMpExMap::AddKey: AliMpExMap::AddKey: resized Key array
71 W-AliMpExMap::AddKey: AliMpExMap::AddKey: resized Key array
72 W-AliMpExMap::AddKey: AliMpExMap::AddKey: resized Key array
73 W-AliMpExMap::AddKey: AliMpExMap::AddKey: resized Key array
74 W-AliMpExMap::AddKey: AliMpExMap::AddKey: resized Key array
75 W-AliMpExMap::AddKey: AliMpExMap::AddKey: resized Key array
76 W-AliMpExMap::AddKey: AliMpExMap::AddKey: resized Key array
77 W-AliMpExMap::AddKey: AliMpExMap::AddKey: resized Key array
78 W-AliMpExMap::AddKey: AliMpExMap::AddKey: resized Key array
79 W-AliMpExMap::AddKey: AliMpExMap::AddKey: resized Key array
80 W-AliMpExMap::AddKey: AliMpExMap::AddKey: resized Key array
81 W-AliMpExMap::AddKey: AliMpExMap::AddKey: resized Key array
82 W-AliMpExMap::AddKey: AliMpExMap::AddKey: resized Key array
83 W-AliMpExMap::AddKey: AliMpExMap::AddKey: resized Key array
84 16828 Manus and 1064008 channels.
87 Then use the AliMUONPedestalEventGenerator to produce simulated pedestal events.
90 root[] AliCDBManager::Instance()->SetDefaultStorage(cdbpath); // so you will read
91 // back pedestals values generated in the previous step
92 root[] const char* dateFileName = "raw.date"; // base filename for the output
93 root[] Int_t runNumber = 80; // run number used to fetch the pedestals from the OCDB
94 root[] Int_t nevents = 100; // # of events to generate. 100 should be enough
95 root[] AliMUONPedestalEventGenerator ped(runNumber,nevents,dateFileName);
98 It *will* take a lot of time (mainly due to the fact that we're writting a
99 bunch of ASCII files = DDL files), so please be patient.
101 The output should be the normal simulated sequence of MUON.Hits.root, MUON.SDigits.root,
102 MUON.Digits.root, raw/*.ddl files and raw.date.LDCi where i=0-3 (i.e. one DATE file
103 per LDC, as will be used in real life), the latter ones being roughly 100 MB each.
105 The raw.date.LDC* files are then processed using the makeped online program
106 (currently found, pending an agreement on where to put online programs under cvs,
107 under /afs/cern.ch/user/a/abaldiss/public/v15; Please contact Alberto to check
108 it's the latest version) which outputs manus-*.ped ASCII files (one per LDC) :
110 makeped -f raw.date.LCDi (i=0,1,2,3)
111 mv manus-1.ped LDCi.ped
113 (repeat for each LDC)
115 The LDCi.ped files are the input for the pedestal subprocessor,
116 which is tested using the TestMUONPreprocessor.C macro.
117 The output of the pedestal subprocessor (upon success only) is written into the OCDB.
118 Difference between the input and the output can be inferred using the diff() function
126 HV DCS values are created in CreateDCSAliasMap() of TestMUONPreprocessor.C
127 You might want to modify this function to create a given set of error conditions
128 in order to test whether the HVSubprocessor is reacting properly to those errors.