Detectors base support

Geometry and GRPs CCDB fetcher helper

Consist of 2 classes:

1) o2::base::GRPGeomRequest class to formulate the request of what is needed: put in the device spec definition:

DataProcessorSpec getMyDeviceSpec()
{
 std::vector<InputSpec> inputs;
 // fill your input requests then:
 auto ccdbRequest = std::make_shared<GRPGeomRequest>(orbitResetTime=true, GRPECS=true, GRPLHCIF=false, GRPMagField=true, askMatLUT=true, geom=GRPGeomRequest::Aligned, inputs);
 // ...
 return DataProcessorSpec{ "my-device", inputs, outputs, AlgorithmSpec{adaptFromTask<MyTaskClass>(ccdbRequest,...), Options{..}} };
}

2) Instanciate helper in the device class constructor and make sure that the method GRPGeomRequest::instance()->finaliseCCDB(ConcreteDataMatcher& matcher, void* obj) is called from the device finaliseCCDB method and the method GRPGeomRequest::instance()->checkUpdates(pc) is called in the beginning of the run method, i.e.

class MyTask {
 public:
  MyTask(std::shared_ptr<GRPGeomRequest> req, ...) : mCCDBReq(req) {
  }
  void init(o2::framework::InitContext& ic) {
    GRPGeomHelper::instance()->setRequest(req);
    ...
  }
  void finaliseCCDB(ConcreteDataMatcher& matcher, void* obj)
  {
    GRPGeomHelper::instance()->finaliseCCDB(matcher, obj);
    ...
  }
  void run(ProcessingContext& pc)
  {
    GRPGeomHelper::instance()->checkUpdates(pc);
    ...
  }
  protected:
   std::shared_ptr<GRPGeomRequest> mCCDBReq;
};

Requested objects can be accessed via getters, e.g. GRPGeomRequest::instance()->getGRPECS() and finaliseCCDB will update the o2::base::Propagator with the fields and material LUT if the GRPMagField and MatLUT arguments were set to true in the request.

Geometry

Loading geometry

The o2sim_geometry.root file is generated by the o2-sim (only for the modules which are asked for the simulation). Currently it has to be loaded from the local file, in future its uploading from the CCDB will be implemented.

The standard way to load the geometry is via static method

o2::base::GeometryManager::loadGeometry(std::string_view geomFilePath = "", bool applyMisalignment = true);

An empty geomFilePath is interpreted as a request to load o2sim_geometry.root from the current directory. Otherwise, the following attempts will be done: (i) if it is a valid file name, load as is, (ii) if it is a valid directory path, load from it o2sim_geometry.root file, (iii) otherwise, interpret it as a prefix to compose a file name geomFilePath_geometry.root. Note that if the ConfigurableParam-type NameConf.mDirGeom string is not empty or equal to none, then its value will be prepended in front of the geomFilePath as a top directory.

The argument applyMisalignment will trigger an attempt to apply the misalignment from the CCDB (see below).

Applying geometry (mis)alignment

The TGeoManager object stored in the file (or CCDB) corresponds to closed but unlocked ideal geometry, whose volumes declared as alignable can be modified applying the relevant TGeoHMatrix. This matrix is generated on the fly from the o2::detectors::AlignParam objects, which are stored in the vector per detector in the <DET>/Aling path on the CCDB.

The volume aligned by given AlignParam object is identified by the its mSymName data member (which must be the same as assigned when declaring the volume alignable via gGeoManager->SetAlignableEntry(...) in the detector geometry builder) and (for sensitive volumes only) by the mAlignableID data member, also provided for the sensors as an argument of SetAlignableEntry(...) (for the non-sensor volumes mAlignableID must be -1).

The value of the mAlignableID must be composed by the static method o2::base::GeometryManager::getSensID(DetID detId, int sensID), where sensID is the sequential number of the sensor for given detector detId.

Some details about the transformations applied by the o2::detectors::AlignParam (similar to the Aliroot AliAlignObjParams) can be found in the The delta-transformation page.

Currently the test CCDB server http://ccdb-test.cern.ch:8080 is populated with empty vectors (generated by the O2/macros/UploadDummyAlignment.C macro) which do not modify the geometry (except for the ITS whose misalignment is generated by the sample macro O2/Detectors/ITSMFT/ITS/macros/test/ITSMisaligner.C.

On the low level the (mis)alignment is applied to the geometry by the static method o2::base::GeometryManager::applyAlignment(const std::vector<o2::detectors::AlignParam>& algPars). When loading the geometry via o2::base::GeometryManager::loadGeometry(..) method the alignment will be applied if the argument applyMisalignment is true, using the o2::base::Aligner helper. This latter inherits from the ConfigurableParam, so it can be configured from the command line by passing --configKeyValues "align-geom.<key>=<value>" string (provided the workflow invokes o2::conf::ConfigurableParam::updateFromString(configcontext.options().get<std::string>("configKeyValues"))). It allows to set the following parameters:

• align-geom.mCCDB : URL of the CCDB server, default: "http://ccdb-test.cern.ch:8080"
• align-geom.mDetectors : Comma separated list of detectors, "all"(default) or "none"
• align-geom.mTimeStamp : the time-stamp for CCDB query. If it is 0 (default) then the time-stamp =now()` in milliseconds will be used.

TODO: once the framework will provide CCDB service, the helper will be adapted to retrieve the alignment objects via query to DPL.