You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[← Go back to Post-processing](PostProcessing.md) | [↑ Go to the Table of Content ↑](../README.md) | [Continue to Frequently Asked Questions →](FAQ.md)
37
25
38
26
39
-
# CCDB / QCDB
40
-
41
-
## Accessing objects in CCDB
42
-
43
-
The MonitorObjects generated by Quality Control are stored in a dedicated repository (QCDB), which is based on CCDB.
44
-
The run conditions, on the other hand, are located in another, separate database.
45
-
46
-
The recommended way (excluding postprocessing) to access these conditions is to use a `Lifetime::Condition` DPL input, which can be requested as in the query below:
auto mDictPtr = ctx.inputs().get<o2::itsmft::TopologyDictionary*>("cldict");
86
-
```
87
-
88
-
Geometry and General Run Parameters (GRP) can be also accessed with the [GRP Geom Helper](#access-grp-objects-with-grp-geom-helper).
89
-
90
-
If your task accesses CCDB objects using `UserCodeInterface::retrieveConditionAny`, please migrate to using one of the methods mentioned above.
91
-
92
-
### Accessing from a Postprocessing task
93
-
94
-
PostProcessingTasks do not take DPL inputs, so in this case `ConditionAccess::retrieveConditionAny` should be used (it's inherited by `PostProcessingInterface` and any children).
95
-
96
-
## Access GRP objects with GRP Geom Helper
97
-
98
-
To get GRP objects via a central facility, add the following structure to the task definition and set its values
99
-
according to the needs.
100
-
101
-
```json
102
-
"myTask": {
103
-
...
104
-
"grpGeomRequest" : {
105
-
"geomRequest": "None", "": "Available options are \"None\", \"Aligned\", \"Ideal\", \"Alignements\"",
106
-
"askGRPECS": "false",
107
-
"askGRPLHCIF": "false",
108
-
"askGRPMagField": "false",
109
-
"askMatLUT": "false",
110
-
"askTime": "false",
111
-
"askOnceAllButField": "false",
112
-
"needPropagatorD": "false"
113
-
}
114
-
}
115
-
```
116
-
117
-
The requested objects will be available via [`GRPGeomHelper::instance()`](https://github.com/AliceO2Group/AliceO2/blob/dev/Detectors/Base/include/DetectorsBase/GRPGeomHelper.h) singleton.
118
-
119
-
## Global Tracking Data Request helper
120
-
121
-
To retrieve tracks and clusters for specific detectors or detector combinations, one can use the [`DataRequest`](https://github.com/AliceO2Group/AliceO2/blob/dev/DataFormats/Detectors/GlobalTracking/include/DataFormatsGlobalTracking/RecoContainer.h) helper.
122
-
By adding the following structure to a QC task, the corresponding `InputSpecs` will be automatically added to the task.
123
-
124
-
```json
125
-
"myTask": {
126
-
...
127
-
"globalTrackingDataRequest": {
128
-
"canProcessTracks" : "ITS,ITS-TPC",
129
-
"requestTracks" : "ITS,TPC-TRD",
130
-
"canProcessClusters" : "TPC",
131
-
"requestClusters" : "TPC",
132
-
"mc" : "false"
133
-
}
134
-
}
135
-
```
136
-
137
-
Then, the corresponding tracks and clusters can be retrieved in the code using `RecoContainer`:
The quality is stored as a CCDB metadata of the object.
187
-
188
-
### Data storage format before v0.14 and ROOT 6.18
189
-
190
-
Before September 2019, objects were serialized with TMessage and stored as _blobs_ in the CCDB. The main drawback was the loss of the corresponding streamer infos leading to problems when the class evolved or when accessing the data outside the QC framework.
191
-
192
-
The QC framework is nevertheless backward compatible and can handle the old and the new storage system.
193
-
194
-
## Local CCDB setup
195
-
196
-
Having a central ccdb for test (ccdb-test) is handy but also means that everyone can access, modify or delete the data. If you prefer to have a local instance of the CCDB, for example in your lab or on your development machine, follow these instructions.
197
-
198
-
1. Download the local repository service from <http://alimonitor.cern.ch/download/local.jar>
199
-
200
-
2. The service can simply be run with
201
-
`java -jar local.jar`
202
-
203
-
It will start listening by default on port 8080. This can be changed either with the java parameter “tomcat.port” or with the environment variable “TOMCAT_PORT”. Similarly the default listening address is 127.0.0.1 and it can be changed with the java parameter “tomcat.address” or with the environment variable “TOMCAT_ADDRESS” to something else (for example ‘*’ to listen on all interfaces).
204
-
205
-
By default the local repository is located in /tmp/QC (or java.io.tmpdir/QC to be more precise). You can change this location in a similar way by setting the java parameter “file.repository.location” or the environment variable “FILE_REPOSITORY_LOCATION”.
206
-
207
-
The address of the CCDB will have to be updated in the Tasks config file.
208
-
209
-
At the moment, the description of the REST api can be found in this document : <https://docs.google.com/presentation/d/1PJ0CVW7QHgnFzi0LELc06V82LFGPgmG3vsmmuurPnUg>
210
-
211
-
## Instructions to move an object in the QCDB
212
-
213
-
The script `o2-qc-repo-move-objects` lets the user move an object, and thus all the versions attached to it. E.g.:
@@ -292,9 +101,8 @@ These methods must be called after the objects has been published, i.e. after th
292
101
To install and run the QCG locally please follow these instructions : <https://github.com/AliceO2Group/WebUi/tree/dev/QualityControl#installation>
293
102
294
103
295
-
# Miscellaneous
296
104
297
-
##Data Sampling monitoring
105
+
# Data Sampling monitoring
298
106
299
107
To have the monitoring metrics for the Data Sampling (the Dispatcher) sent to a specific sink (like influxdb), add the option `--monitoring-backend` when launching the DPL workflow. For example:
300
108
@@ -306,7 +114,7 @@ This will actually send the monitoring data of _all_ DPL devices to this databas
306
114
307
115
**Note for mac users**: if you get a crash and the message "std::exception::what: send_to: Message too long", it means that you have to adapt a `udp` parameter. You can check the datagram size via `sudo sysctl net.inet.udp.maxdgram`. If it says something less than 64 kB, then increase size: `sudo sysctl -w net.inet.udp.maxdgram=65535`
308
116
309
-
##Monitoring metrics
117
+
# Monitoring metrics
310
118
311
119
The QC framework publishes monitoring metrics concerning data/object rates, which are published to the monitoring backend
312
120
specified in the `"monitoring.url"` parameter in config files. If QC is run in standalone mode (no AliECS) and with
@@ -315,7 +123,7 @@ printing them as soon as they are reported, please also add `--monitoring-backen
315
123
316
124
One can also enable publishing metrics related to CPU/memory usage. To do so, use `--resources-monitoring <interval_sec>`.
317
125
318
-
##Common check `IncreasingEntries`
126
+
# Common check `IncreasingEntries`
319
127
320
128
This check make sures that the number of entries has increased in the past cycle(s). If not, it will display a pavetext
321
129
on the plot and set the quality to bad.
@@ -345,7 +153,7 @@ The number of cycles during which we tolerate increasing (or not respectively) t
345
153
346
154
In the example above, the quality goes to bad when there are 3 cycles in a row with no increase in the number of entries.
347
155
348
-
##Common check `TrendCheck`
156
+
# Common check `TrendCheck`
349
157
350
158
This check compares the last point of a trending plot with some minimum and maximum thresholds.
351
159
@@ -396,7 +204,7 @@ The position and size of the text label that shows the check result can also be
396
204
397
205
The values are relative to the canvas size, so in the example above the label width is 50% of the canvas width and the label height is 10% of the canvas height.
398
206
399
-
####Full configuration example
207
+
### Full configuration example
400
208
401
209
```json
402
210
"MyTrendingCheckFixed": {
@@ -485,11 +293,11 @@ The values are relative to the canvas size, so in the example above the label wi
485
293
}
486
294
```
487
295
488
-
##Update the shmem segment size of a detector
296
+
# Update the shmem segment size of a detector
489
297
490
298
In consul go to `o2/runtime/aliecs/defaults` and modify the file corresponding to the detector: [det]_qc_shm_segment_size
491
299
492
-
###Readout chain (optional)
300
+
## Readout chain (optional)
493
301
494
302
In this second example, we are going to use the Readout as our data source.
495
303
This example assumes that Readout has been compiled beforehand (`aliBuild build Readout --defaults o2`).
0 commit comments