Skip to content

Latest commit

 

History

History
192 lines (143 loc) · 7.51 KB

QCDB.md

File metadata and controls

192 lines (143 loc) · 7.51 KB

QCDB

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 :

"tasks": {
  "QcTask": {       <---------- task ID
    "active": "true",
    "taskName": "QcTask",   <--------- task name
    "className": "o2::quality_control_modules::skeleton::SkeletonTask",
    "moduleName": "QcSkeleton",
    "detectorName": "TST",       <---------- detector name

If the task name is not specified then we use the task ID. 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);

Accessing objects in CCDB

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:

  "tasks": {
    "MyTask": {
    ...
      "dataSource": {
        "type": "direct",
        "query": "randomcluster:MFT/COMPCLUSTERS/0;cldict:MFT/CLUSDICT/0?lifetime=condition&ccdb-path=MFT/Calib/ClusterDictionary"
      },
    }
  },

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:

  "tasks": {
    "MyTask": {
    ...
      "dataSources": [{
        "type": "dataSamplingPolicy",
        "name": "mftclusters"
      }, {
        "type": "direct",
        "query": "cldict:MFT/CLUSDICT/0?lifetime=condition&ccdb-path=MFT/Calib/ClusterDictionary"
      }],
    }
  },

The requested CCDB object can be accessed like any other DPL input in monitorData:

void QcMFTClusterTask::monitorData(o2::framework::ProcessingContext& ctx)
{
...
    auto mDictPtr = ctx.inputs().get<o2::itsmft::TopologyDictionary*>("cldict");

Geometry and General Run Parameters (GRP) can be also accessed with the GRP Geom Helper.

If your task accesses CCDB objects using UserCodeInterface::retrieveConditionAny, please migrate to using one of the methods mentioned above.

Accessing from a Postprocessing task

PostProcessingTasks do not take DPL inputs, so in this case ConditionAccess::retrieveConditionAny should be used (it's inherited by PostProcessingInterface and any children).

Access GRP objects with GRP Geom Helper

To get GRP objects via a central facility, add the following structure to the task definition and set its values according to the needs.

      "myTask": {
        ...
        "grpGeomRequest" : {
          "geomRequest": "None",     "": "Available options are \"None\", \"Aligned\", \"Ideal\", \"Alignements\"",
          "askGRPECS": "false",
          "askGRPLHCIF": "false",
          "askGRPMagField": "false",
          "askMatLUT": "false",
          "askTime": "false",
          "askOnceAllButField": "false",
          "needPropagatorD":  "false"
        }
      }

The requested objects will be available via GRPGeomHelper::instance() singleton.

Global Tracking Data Request helper

To retrieve tracks and clusters for specific detectors or detector combinations, one can use the DataRequest helper. By adding the following structure to a QC task, the corresponding InputSpecs will be automatically added to the task.

      "myTask": {
        ...
        "globalTrackingDataRequest": {
            "canProcessTracks" : "ITS,ITS-TPC",
            "requestTracks" : "ITS,TPC-TRD",
            "canProcessClusters" : "TPC",
            "requestClusters" : "TPC",
            "mc" : "false"
        }
      }

Then, the corresponding tracks and clusters can be retrieved in the code using RecoContainer:

void MyTask::monitorData(o2::framework::ProcessingContext& ctx)
{
  o2::globaltracking::RecoContainer recoData;
  if (auto dataRequest = getGlobalTrackingDataRequest()) {
    recoData.collectData(ctx, *dataRequest);
  }
}

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.

  1. Download the local repository service from http://alimonitor.cern.ch/download/local.jar

  2. The service can simply be run with java -jar local.jar

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).

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”.

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

← Go back to Configuration | ↑ Go to the Table of Content ↑ | Continue to FLP Suite →