[QC-1286] up to flp suite

Barthelemy · Barthelemy · commit bff913c77212 · 2025-05-12T09:13:20.000+02:00
diff --git a/doc/Configuration.md b/doc/Configuration.md
@@ -88,9 +88,8 @@ should not be present in real configuration files.
         "host": "ccdb-test.cern.ch:8080", "": "URL of a DB.",
         "maxObjectSize": "2097152",       "": "[Bytes, default=2MB] Maximum size allowed, larger objects are rejected."
       },
-      "Activity": {                       "": ["Configuration of a QC Activity (Run). This structure is subject to",
-                                               "change or the values might come from other source (e.g. ECS+Bookkeeping)." ],
-        "number": "42",                   "": "Activity number.",
+      "Activity": {                       "": ["Configuration of a QC Activity (Run). DO NOT USE IN PRODUCTION! " ],
+        "number": "42",                   "": "Activity number. ",
         "type": "PHYSICS",                "": "Activity type.",
         "periodName": "",                 "": "Period name - e.g. LHC22c, LHC22c1b_test",
         "passName": "",                   "": "Pass type - e.g. spass, cpass1",
@@ -721,4 +720,4 @@ TODO we miss the definition of the datasampling policies
 
 ---
 
-[← Go back to Framework](Framework.md) | [↑ Go to the Table of Content ↑](../README.md) | [Continue to FLP Suite →](FLPsuite.md)
+[← Go back to Post-Processing](PostProcessing.md) | [↑ Go to the Table of Content ↑](../README.md) | [Continue to QCDB →](QCDB.md)
diff --git a/doc/FAQ.md b/doc/FAQ.md
@@ -120,4 +120,4 @@ in the config:
         "maxObjectSize": "2097152",       "": "[Bytes, default=2MB] Maximum size allowed, larger objects are rejected."
 ```
 
-[← Go back to Advanced Topics](Advanced.md) | [↑ Go to the Table of Content ↑](../README.md) 
+[← Go back to Miscellaneous](Miscellaneous.md) | [↑ Go to the Table of Content ↑](../README.md) 
diff --git a/doc/FLPsuite.md b/doc/FLPsuite.md
@@ -205,4 +205,4 @@ See the details [here](https://github.com/AliceO2Group/QualityControl/blob/maste
 
 ---
 
-[← Go back to Configuration](Configuration.md) | [↑ Go to the Table of Content ↑](../README.md) | [Continue to Miscellaneous →](Miscellaneous.md)
+[← Go back to QCDB](QCDB.md) | [↑ Go to the Table of Content ↑](../README.md) | [Continue to Miscellaneous →](Miscellaneous.md)
diff --git a/doc/Framework.md b/doc/Framework.md
@@ -18,6 +18,7 @@ Framework
    * [Propagating Check results to RCT in Bookkeeping](#propagating-check-results-to-rct-in-bookkeeping)
    * [Solving performance issues](#solving-performance-issues)
    * [Understanding and reducing memory footprint](#understanding-and-reducing-memory-footprint)
+   * [Monitoring](#monitoring)
 <!--te-->
 
 ## Plugging the QC to an existing DPL workflow
@@ -736,4 +737,17 @@ ms_print massif.out.976329 > massif_abc_task.log
 
 6) Consider reducing the size and number of the biggest histogram. Consider disabling histograms which will not be useful for async QC (no allocations, no startPublishing).
 
+## Monitoring
+
+The QC uses the [O2 Monitoring](https://github.com/AliceO2Group/Monitoring/) library to monitor metrics.
+The user code has access to an instance of the Monitoring via the variable `mMonitoring`.
+It can be used this way:
+```
+mMonitoring->send({ 42, "my/metric" }); // send the value 42 keyed with "my/metric" 
+```
+By default the Monitoring will be printed in the terminal. If a proper Monitoring system
+is setup, one can update the monitoring url in the config file to point to it.
+
+---
+
 [← Go back to Post-Processing](PostProcessing.md) | [↑ Go to the Table of Content ↑](../README.md) | [Continue to Configuration →](Configuration.md)
diff --git a/doc/Miscellaneous.md b/doc/Miscellaneous.md
@@ -21,9 +21,6 @@ Miscellaneous
       * [Readout data format as received by the Task](#readout-data-format-as-received-by-the-task)
 <!--te-->
 
-[← Go back to Post-processing](PostProcessing.md) | [↑ Go to the Table of Content ↑](../README.md) | [Continue to Frequently Asked Questions →](FAQ.md)
-
-
 
 # Asynchronous Data and Monte Carlo QC operations
 
diff --git a/doc/ModulesDevelopment.md b/doc/ModulesDevelopment.md
@@ -11,10 +11,8 @@
    * [Developing with aliBuild/alienv](#developing-with-alibuildalienv)
    * [User-defined modules](#user-defined-modules)
    * [Repository](#repository)
-      * [Paths](#paths)
 * [Module creation](#module-creation)
 * [Test run](#test-run)
-   * [Saving the QC objects in a local file](#saving-the-qc-objects-in-a-local-file)
 * [Modification of the Task](#modification-of-the-task)
 * [Check](#check)
    * [Configuration](#configuration)
@@ -31,7 +29,6 @@
    * [DPL workflow](#dpl-workflow)
 * [Run number and other run attributes (period, pass type, provenance)](#run-number-and-other-run-attributes-period-pass-type-provenance)
 * [A more advanced example](#a-more-advanced-example)
-* [Monitoring](#monitoring)
 <!--te-->
 
 [← Go back to Quickstart](QuickStart.md) | [↑ Go to the Table of Content ↑](../README.md) | [Continue to Post-processing →](PostProcessing.md)
@@ -590,17 +587,6 @@ or
 o2-qc-run-advanced --no-qc | o2-qc --config json://${QUALITYCONTROL_ROOT}/etc/advanced.json
 ```
 
-## Monitoring
-
-The QC uses the [O2 Monitoring](https://github.com/AliceO2Group/Monitoring/) library to monitor metrics. 
-The user code has access to an instance of the Monitoring via the variable `mMonitoring`. 
-It can be used this way: 
-```
-mMonitoring->send({ 42, "my/metric" }); // send the value 42 keyed with "my/metric" 
-```
-By default the Monitoring will be printed in the terminal. If a proper Monitoring system 
-is setup, one can update the monitoring url in the config file to point to it. 
-
 ---
 
 [← Go back to Quickstart](QuickStart.md) | [↑ Go to the Table of Content ↑](../README.md) | [Continue to Post-processing →](PostProcessing.md)
diff --git a/doc/PostProcessing.md b/doc/PostProcessing.md
@@ -17,8 +17,6 @@
 * [More examples](#more-examples)
 <!--te-->
 
-[← Go back to Modules Development](ModulesDevelopment.md) | [↑ Go to the Table of Content ↑](../README.md) | [Continue to Advanced Topics →](Advanced.md)
-
 ## The post-processing framework
 
 This framework is intended for planned post-processing of objects generated by QC Tasks, Checks and correlating them with other data. The most common use-cases include correlation and trending of different properties of the detectors.
@@ -1153,4 +1151,4 @@ Use the Activity which leaves the run number empty, but indicate the pass and pe
       }
 ```
 
-[← Go back to Modules Development](ModulesDevelopment.md) | [↑ Go to the Table of Content ↑](../README.md) | [Continue to Framework →](Framework.md)
+[← Go back to Framework](Framework.md) | [↑ Go to the Table of Content ↑](../README.md) | [Continue to Configuration →](Configuration.md)
diff --git a/doc/QCDB.md b/doc/QCDB.md
@@ -5,14 +5,73 @@ QCDB
 <!--TOC generated with https://github.com/ekalinin/github-markdown-toc-->
 <!--./gh-md-toc --insert --no-backup --hide-footer --indent 3 QualityControl/doc/Advanced.md -->
 <!--ts-->
+   * [QCDB vs CCDB](#qcdb-vs-ccdb)
+   * [Details on the data storage format in the QCDB](#details-on-the-data-storage-format-in-the-qcdb)
+   * [Custom metadata for QC objects in the QCDB](#custom-metadata-for-qc-objects-in-the-qcdb)
+   * [Instructions to move an object in the QCDB](#instructions-to-move-an-object-in-the-qcdb)
+   * [Accessing objects in CCDB](#accessing-objects-in-ccdb)
+   * [Access GRP objects with GRP Geom Helper](#access-grp-objects-with-grp-geom-helper)
+   * [Global Tracking Data Request helper](#global-tracking-data-request-helper)
+   * [Local CCDB setup](#local-ccdb-setup)
 <!--te-->
 
-## Accessing objects in CCDB
+## QCDB vs CCDB
+
+The MonitorObjects generated by Quality Control are stored in a dedicated repository called **QCDB**.
+The run conditions, on the other hand, are located in another, separate database, called **CCDB**.
+
+Both are based on a technology called _CCDB_ which does not help with the confusion...
+
+## Details on the data storage format in the QCDB
+
+Each MonitorObject is stored as a TFile in the QCDB.
+It is therefore possible to easily open it with ROOT when loaded with alienv. It also seamlessly supports class schema evolution.
+
+The MonitorObjects are stored at a path which is enforced by the qc framework : `/qc/<detector code>/MO/<task name>/object/name`
+Note that the name of the object can contain slashes (`/`) in order to build a sub-tree visible in the GUI.
+The detector name and the taskname are set in the config file :
+
+```json
+"tasks": {
+  "QcTask": {       <---------- task name
+    "active": "true",
+    "className": "o2::quality_control_modules::skeleton::SkeletonTask",
+    "moduleName": "QcSkeleton",
+    "detectorName": "TST",       <---------- detector name
+```
+
+The quality is stored as a CCDB metadata of the object.
+
+## Custom metadata for QC objects in the QCDB
+
+One can add custom metadata on the QC objects produced in a QC task.
+Simply call `ObjectsManager::addMetadata(...)`, like in
+
+```
+  // add a metadata on histogram mHistogram, key is "custom" and value "34"
+  getObjectsManager()->addMetadata(mHistogram->GetName(), "custom", "34");
+```
+
+This metadata will end up in the _QCDB_.
+
+It is also possible to add or update metadata of a MonitorObject directly:
+
+```
+  MonitorObject* mo = getMonitorObject(objectName);
+  mo->addOrUpdateMetadata(key, value);
+```
+
+## Instructions to move an object in the QCDB
+
+The script `o2-qc-repo-move-objects` lets the user move an object, and thus all the versions attached to it. E.g.:
+
+```
+python3 o2-qc-repo-move-objects --url http://ccdb-test.cern.ch:8080 --path qc/TST/MO/Bob --new-path qc/TST/MO/Bob2 --log-level 10 
+```
 
-The MonitorObjects generated by Quality Control are stored in a dedicated repository (QCDB), which is based on CCDB.
-The run conditions, on the other hand, are located in another, separate database.
+## Accessing objects in CCDB
 
-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:
+The recommended way (excluding postprocessing) to access the run conditions in the _CCDB_ is to use a `Lifetime::Condition` DPL input, which can be requested as in the query below:
 
 ```json
   "tasks": {
@@ -26,9 +85,9 @@ The recommended way (excluding postprocessing) to access these conditions is to
   },
 ```
 
-The timestamp of the CCDB object will be aligned with the data timestamp.
+The timestamp of the _CCDB_ object will be aligned with the data timestamp.
 
-If a task needs both sampled input and a CCDB object, it is advised to use two data sources as such:
+If a task needs both sampled input and a _CCDB_ object, it is advised to use two data sources as such:
 
 ```json
   "tasks": {
@@ -45,7 +104,7 @@ If a task needs both sampled input and a CCDB object, it is advised to use two d
   },
 ```
 
-The requested CCDB object can be accessed like any other DPL input in `monitorData`:
+The requested _CCDB_ object can be accessed like any other DPL input in `monitorData`:
 
 ```
 void QcMFTClusterTask::monitorData(o2::framework::ProcessingContext& ctx)
@@ -56,7 +115,7 @@ void QcMFTClusterTask::monitorData(o2::framework::ProcessingContext& ctx)
 
 Geometry and General Run Parameters (GRP) can be also accessed with the [GRP Geom Helper](#access-grp-objects-with-grp-geom-helper).
 
-If your task accesses CCDB objects using `UserCodeInterface::retrieveConditionAny`, please migrate to using one of the methods mentioned above.
+If your task accesses _CCDB_ objects using `UserCodeInterface::retrieveConditionAny`, please migrate to using one of the methods mentioned above.
 
 ### Accessing from a Postprocessing task
 
@@ -115,51 +174,6 @@ void MyTask::monitorData(o2::framework::ProcessingContext& ctx)
 }
 ```
 
-## Custom metadata
-
-One can add custom metadata on the QC objects produced in a QC task.
-Simply call `ObjectsManager::addMetadata(...)`, like in
-
-```
-  // add a metadata on histogram mHistogram, key is "custom" and value "34"
-  getObjectsManager()->addMetadata(mHistogram->GetName(), "custom", "34");
-```
-
-This metadata will end up in the QCDB.
-
-It is also possible to add or update metadata of a MonitorObject directly:
-
-```
-  MonitorObject* mo = getMonitorObject(objectName);
-  mo->addOrUpdateMetadata(key, value);
-```
-
-## Details on the data storage format in the CCDB
-
-Each MonitorObject is stored as a TFile in the CCDB.
-It is therefore possible to easily open it with ROOT when loaded with alienv. It also seamlessly supports class schema evolution.
-
-The MonitorObjects are stored at a path which is enforced by the qc framework : `/qc/<detector code>/MO/<task name>/object/name`
-Note that the name of the object can contain slashes (`/`) in order to build a sub-tree visible in the GUI.
-The detector name and the taskname are set in the config file :
-
-```json
-"tasks": {
-  "QcTask": {       <---------- task name
-    "active": "true",
-    "className": "o2::quality_control_modules::skeleton::SkeletonTask",
-    "moduleName": "QcSkeleton",
-    "detectorName": "TST",       <---------- detector name
-```
-
-The quality is stored as a CCDB metadata of the object.
-
-### Data storage format before v0.14 and ROOT 6.18
-
-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.
-
-The QC framework is nevertheless backward compatible and can handle the old and the new storage system.
-
 ## Local CCDB setup
 
 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.
@@ -177,15 +191,8 @@ The address of the CCDB will have to be updated in the Tasks config file.
 
 At the moment, the description of the REST api can be found in this document : <https://docs.google.com/presentation/d/1PJ0CVW7QHgnFzi0LELc06V82LFGPgmG3vsmmuurPnUg>
 
-## Instructions to move an object in the QCDB
-
-The script `o2-qc-repo-move-objects` lets the user move an object, and thus all the versions attached to it. E.g.:
-
-```
-python3 o2-qc-repo-move-objects --url http://ccdb-test.cern.ch:8080 --path qc/TST/MO/Bob --new-path qc/TST/MO/Bob2 --log-level 10 
-```
 
 ---
 
-[← Go back to Post-processing](PostProcessing.md) | [↑ Go to the Table of Content ↑](../README.md) | [Continue to Configuration →](Configuration.md)
+[← Go back to Configuration](Configuration.md) | [↑ Go to the Table of Content ↑](../README.md) | [Continue to FLP Suite →](FLPsuite.md)
 
diff --git a/doc/QuickStart.md b/doc/QuickStart.md
@@ -12,8 +12,6 @@
    * [Post-processing example](#post-processing-example)
 <!--te-->
 
-[↑ Go to the Table of Content ↑](../README.md) | [Continue to Modules Development →](ModulesDevelopment.md)
-
 ## Read this first!
 
 This page will give you a basic idea of the QC and how to run it. Please read it *in its entirety* and run the commands along the way. Do not start developing your module before you have reached the next section called "Modules Development". Also, make sure you have pulled the latest QC version.

Original file line number	Diff line number	Diff line change
`@@ -205,4 +205,4 @@ See the details [here](https://github.com/AliceO2Group/QualityControl/blob/maste`
`205`	`205`
`206`	`206`	`---`
`207`	`207`
`208`		`-[← Go back to Configuration](Configuration.md) \| [↑ Go to the Table of Content ↑](../README.md) \| [Continue to Miscellaneous →](Miscellaneous.md)`
	`208`	`+[← Go back to QCDB](QCDB.md) \| [↑ Go to the Table of Content ↑](../README.md) \| [Continue to Miscellaneous →](Miscellaneous.md)`