]>
Commit | Line | Data |
---|---|---|
aa9dd72b | 1 | $Id$ |
2 | ||
e661d480 | 3 | The Offline Condition DataBase is described extensively on ALICE Offline pages. |
4 | ||
5 | Here you'll find only information relevant to the MUONCDB.C macro, which defines | |
6 | a set of functions to read/write MUON information to this CDB. Those functions are | |
7 | not meant to be used as black boxes. Please have a closer look before using | |
8 | (especially the ones writing to the CDB...) | |
9 | ||
10 | ------- | |
11 | Calibration data objects | |
12 | ------- | |
13 | ||
14 | We've designed generic data containers to store calibration information, | |
15 | tailored to the way we usually access MUON tracker data, that is, indexed by the pair (detElemId,manuId). | |
16 | This container is called AliMUONV2DStore. You can attach a TObject to every and each pair (detElemId,manuId). | |
17 | For the moment, that TObject is generally of AliMUONVCalibParam type, | |
18 | which handles a given number of channels (64 typically) as a group. | |
19 | As the class names suggest, both classes are only interfaces. Concrete ones are AliMUON2DMap (used instead of a vector | |
20 | as detElemId are not contiguous) for the V2DStore, CalibParam1I (VCalibParam storing one integer per channel), and | |
21 | CalibParam2F (VCalibParam storing 2 floats per channel). | |
22 | ||
23 | One exception are the HV values from DCS, which are stored "as they come" from the shuttle-dcs interface, as a TMap, where | |
24 | the key is the aliasname (TString), and the value a TObjArray of AliDCSValue. | |
25 | ||
26 | For trigger, the same virtual container idea applies, except we're using 1D container (AliMUONV1DStore). | |
27 | ||
28 | -------- | |
29 | CDB location | |
30 | -------- | |
31 | ||
32 | One very important notion is that of the DefaultStorage (which you set with | |
33 | AliCDBManager::Instance()->SetDefaultStorage(path)), which tells the CDB library where | |
34 | the CDB is sitting (either locally on disk, or on the grid). | |
35 | ||
36 | For local tests, path will be most likely = local://$ALICE_ROOT/MUON (i.e. there is, in CVS a slim version of the calibration objects needed | |
37 | for running the MUON code), or local://$ALICE_ROOT/SHUTTLE/TestShuttle/TestCDB for Shuttle testing. | |
38 | ||
39 | ------- | |
40 | Writing to CDB | |
41 | ------- | |
42 | ||
43 | In write mode, this macro was/is used to populate the CDB with fake calibration objects for testing purposes. | |
44 | Real calibration data will normally be handled by the Shuttle (see READMEshuttle). | |
45 | ||
46 | writeGains() and writePedestals() functions may be used to populate MUON tracker information, | |
47 | and generateTrigger() for trigger parts. | |
48 | ||
49 | ------ | |
50 | Reading the CDB | |
51 | ------ | |
52 | ||
53 | The actual reading is encapsulated into AliMUONCalibrationData class. | |
54 | e.g. to read pedestals for run 4567, one would do : | |
55 | ||
56 | AliCDBManager::Instance()->SetDefaultStorage(cdbPath); | |
57 | AliMUONCalibrationData cd(4567); | |
58 | AliMUONV2DStore* ped = cd.Pedestals(); | |
59 | ||
60 | If you want to plot calibration data (not terribly usefull as it's a really global view), use the plot() function | |
61 | in MUONCDB.C, e.g. : | |
62 | ||
63 | plot(*ped,"pedestal") | |
64 | ||
65 | which will create 2 histograms : pedestal_0 (mean) and pedestal_1 (sigma). | |
66 | ||
67 | You might also be interested in the diff() method which generates an AliMUONV2DStore | |
68 | containing the difference (either absolute or relative) of two AliMUONV2DStore. | |
69 | ||
70 |