Skip to content

Consistency of Conditions between DetDesc and DD4Hep for processing of MC samples

For processing simulated samples in HLT1 and HLT2 when produced with DetDesc and processed with DD4Hep as well as to compare simulated samples produced with DetDesc and DD4Hep (Gauss+Boole) in Sim11 it is essential to use consistent descriptions of the geometry and of the Conditions.

Background information

DetDesc - DDDB and SIMCOND

When using DetDesc as geometry backend the geometrical information is taken from DDDB and conditions from a dedicated GitLab project, SIMCOND.

The branches used for Run3 are upgrade/master in DDDB and upgrade/master and upgrade/magup for magnet down and magnet up conditions respectively in SIMCOND.

The two SIMCOND branches are kept in synch and the only differences are what relevant for the different magnet polarity.

Tags are made as upgrade/TAG on the respective branches and can be used without the upgrade prefix as CondDB will resolve it when DataType = 2022, 2023, 2024, Run3

Conditions are declared in the MainConditions.xml catalog in SIMCOND

DD4hep - Detector and LHCb Conditions

When using DD4hep as geometry backend the geometrical information is taken from the Detector project and conditions from dedicated BRANCHES in the LHCb Conditions GitLab project.

The branches for Simulation reflect the simulation VERSION and the data talking YEAR or RUN they have to model:

  • sim10 - all branches for Sim10 (determined by Gauss v56rX as determined by the versions of Geant4, 10.6.p02) have this as top level. Boole modelling is reflected in the Data Taking period
    • sim10/run3-ideal, if for the ideal - or perfectly working - Run3 detector
    • sim10/2022, should contain the conditions corresponding to the data used for physics verifications in 2022
    • sim10/2023, should contain the conditions corresponding to the data used for physics early measurements in 2023
    • sim10/2024, will contain the conditions corresponding to the data used for physics analysis in 2024
  • sim11 - all branches for Sim11 (determined by Gauss >= v60rX and Geant4 10.7.XX) have this as top level
    • sim11/run3-ideal, will be made branching from sim10/run3-ideal once the version of Geant4 for Sim11 is fixed, it will then be kept in synch until needed
    • sim11/run5-ideal, contains the starting perfect conditions for Upgrade 2 studies

Conditions are declared in Detector and attached to a detector element.

Geometry versions and conditions tags

Version of the geometry in DDDB are identified with GitLab tags. So far they have been in the form dddb-DATE where DATE is that of the deployment.

In Detector a version is identified a a directory version in the compact xml directory under the run3 directory for those that refers to run3, while run3/trunk has the evolving geometry. This is inspired by svn code repository.

A new convention for version identifiers has been setup and consist of the concatenation of data taking period being modeled + version.

For more details refer to the Detector contributing file and this presentation by Menglin at the Glasgow 2024 LHCb week.

The same convention can be used from now on for DDDB tags and Detector version directories.Identifiers of conditions are via GitLab tags in the relevant branches.

Tags in SIMCOND need to be preceded by upgrade/ to distinguish them from the Run1 and Run2 tags in CondDB() to allow picking up different detectors.

Tags in LHCb Conditions do not need preceded by upgrade/

Conditions identifiers are a concatenation of simVersion + data taking period being modeled + version + list [special data taking modifiers]

Details on the convention setup for geometry version and conditions identifiers can be found in LHCb- INT-2023-011 [1]

Physical and virtual complements of conditions tags

In SIMCOND we have different branches for different magnet polarities and special data taking, e.g SMOG. To avoid exploding the number of simulation branches in LHCb Conditions a new paradigm has been devised. Tags are composed of a real part, identifying a reference set of conditions, and a virtual part corresponding to a sub-set of run-related conditions. The reference set of conditions corresponds to a branch in the database and defines the default settings for a stable data taking period to be described. The virtual part of the tag results in modification of the reference default conditions via an update of their values at initialisation via CondDB() and correspond for example to different magnet polarity.

More information can be found in this presentation by Gloria at the Glasgow LHCb week and in LHCb- INT-2023-011 [1]

Steps

  • Verify conditions in sim10/run3-ideal are a superset of what if in master for data
  • Define what will need to be treated as virtual tags beside magnet polarity and VELO motor position
  • Verify all needed conditions for simulation are in SIMCOND upgrade/master and in LHCb Conditions sim10/run3-ideal
  • Decide what is needed for 2024 differently than for run3-ideal and ensure that is what is in LHCb Conditions sim10/2024
  • Verify values in conditions are the same and as needed (note that for RICH this may be different) between SIMCOND upgrade/master (or predefined tag) and LHCb Conditions sim10/2024
  • Support and test virtual tags machinery (To Be Discussed)

References

[1] LHCb-INT-2023-011, LHCb Identifiers for geometry description and simulation conditions

cc: @msaur @cmarinbe @mexu @mwhitehe @kreps, @clemenci

Edited by Yingao Tang