]>
Commit | Line | Data |
---|---|---|
1 | // $Id$ | |
2 | ||
3 | /*! | |
4 | ||
5 | \page README_calib Calibration | |
6 | ||
7 | The Offline Condition DataBase is described extensively on ALICE Offline pages. | |
8 | ||
9 | Here you'll find only information relevant to the AliMUONCDB class | |
10 | (formerly MUONCDB.C macro), which defines a set of functions to read/write | |
11 | MUON information to this CDB. Those functions are not meant to be used | |
12 | as black boxes. | |
13 | ||
14 | Please have a closer look before using (especially the ones writing to the CDB...) | |
15 | ||
16 | ||
17 | \section calib_s1 Calibration data objects | |
18 | ||
19 | We've designed generic data containers to store calibration information, | |
20 | tailored to the way we usually access MUON tracker data, that is, | |
21 | indexed by the pair (detElemId,manuId). | |
22 | This container is called AliMUONV2DStore. You can attach a TObject to every and | |
23 | each pair (detElemId,manuId). | |
24 | ||
25 | For the moment, that TObject is generally of AliMUONVCalibParam type, | |
26 | which handles a given number of channels (64 typically) as a group. | |
27 | There's also an AliMUONV1DStore for data types which only requires indexing | |
28 | by 1 value (like trigger masks for instance). | |
29 | ||
30 | As the class names suggest (V...), those classes are only interfaces. | |
31 | Concrete ones are AliMUON2DMap (used instead of a vector as detElemId are | |
32 | not contiguous) for the V2DStore, AliMUON1DArray (for things where indices are | |
33 | contiguous) and AliMUON1DMap for the V1DStore, and CalibParamNI (VCalibParam | |
34 | storing n integer per channel), and CalibParamNF | |
35 | (VCalibParam storing n floats per channel). | |
36 | ||
37 | One exception are the HV values from DCS, which are stored "as they come" from | |
38 | the shuttle-dcs interface, as a TMap, where the key is the aliasname (TString), | |
39 | and the value a TObjArray of AliDCSValue. | |
40 | ||
41 | For trigger, the same virtual container idea applies, | |
42 | except we're using 1D container (AliMUONV1DStore, for masks) or specific ones (for LUT | |
43 | and efficiency) | |
44 | ||
45 | \section calib_s2 CDB location | |
46 | ||
47 | One very important notion is that of the DefaultStorage (which you might set with | |
48 | AliCDBManager::Instance()->SetDefaultStorage(path)), which tells the CDB library where | |
49 | the CDB is sitting (either locally on disk, or on the grid). | |
50 | ||
51 | For local tests, path will be most likely = <code> "local://$ALICE_ROOT/OCDB"</code> | |
52 | (i.e. there is, in CVS a slim version of the calibration objects needed | |
53 | for running the MUON code), or <code> "local://$ALICE_ROOT/OCDB/SHUTTLE/TestShuttle/TestCDB </code> | |
54 | for Shuttle testing. | |
55 | ||
56 | When using alien, the path definition can be eg. | |
57 | <code> "alien://folder=/alice/data/2007/LHC07w/OCDB" </code>. | |
58 | ||
59 | \section calib_s3 Writing to CDB | |
60 | ||
61 | AliMUONCDB class is used to populate the CDB with fake calibration objects for testing purposes. | |
62 | Real calibration data will normally be handled by the Shuttle (see READMEshuttle). | |
63 | ||
64 | The various WriteXXX() methods may be used to populate MUON tracker and trigger | |
65 | information. | |
66 | A full set of calibration data types can be created from scratch using, from | |
67 | the Root prompt (from within the $ALICE_ROOT/MUON directory to get the correct | |
68 | list of libraries loaded by the loadlibs.C macro) | |
69 | ||
70 | <pre> | |
71 | root[0] AliMpCDB::LoadDDLStore2(); | |
72 | root[1] AliMpCDB::LoadManuStore2(); | |
73 | root[2] AliMUONCDB cdb; | |
74 | root[3] Int_t startRun = 0; | |
75 | root[4] Bool_t defaultValues = kTRUE; | |
76 | root[5] cdb.WriteTrigger(startRun); | |
77 | root[6] cdb.WriteTracker(defaultValues,startRun); | |
78 | </pre> | |
79 | ||
80 | ||
81 | \section calib_s4 Reading the CDB | |
82 | ||
83 | The actual reading is encapsulated into AliMUONCalibrationData class. | |
84 | e.g. to read pedestals for run 4567, one would do : | |
85 | ||
86 | <pre> | |
87 | AliCDBManager::Instance()->SetDefaultStorage(cdbPath); | |
88 | AliMUONCalibrationData cd(4567); | |
89 | AliMUONV2DStore* ped = cd.Pedestals(); | |
90 | </pre> | |
91 | ||
92 | If you want to plot calibration data (not terribly usefull as it's a really global view), | |
93 | use the Plot() function of AliMUONCDB, e.g. | |
94 | ||
95 | <pre> | |
96 | AliMUONCDB cdb(cdbpath); | |
97 | cdb.Plot(*ped,"pedestal") | |
98 | </pre> | |
99 | ||
100 | which will create 2 histograms : pedestal_0 (mean) and pedestal_1 (sigma). | |
101 | ||
102 | You might also be interested in the AliMUONStoreHelper::Diff() method | |
103 | which generates an AliMUONV2DStore containing the difference | |
104 | (either absolute or relative) of two AliMUONV2DStore. | |
105 | ||
106 | \section calib_s5 A note on status and status map | |
107 | ||
108 | A special kind of object is the status map. It would deserve a full documentation | |
109 | (and that will need to be done some day), but for the moment, please have a look | |
110 | at the MUONStatusMap.C macro which can let you play with it. For more information, | |
111 | have a look at the AliMUONPadStatusMaker and AliMUONPadStatusMapMaker. | |
112 | ||
113 | This chapter is defined in the READMEcalib.txt file. | |
114 | */ | |
115 |