Choose timezone
Your profile timezone:
Discussion about ARC implementation in DD4hep
→
Europe/Zurich
32/S-C22 (CERN)
Present
G Ganis (CERN, FCC), M Franck (CERN, DD4hep/LHCb), A Tolosa Delgado (CERN, FCC), S Easo (STFC, LHCb), J Smiesko (CERN, FCC), V Cairo (CERN, ATLAS), V Volkl (CERN, FCC), M Tat (Oxford, LHCb), R Forty (CERN, LHCb), B François (CERN, FCC), P Roloff (CERN, LHCb/FCC; remote)
Introduction
The context of the meeting is given by the ongoing FCC Feasibility Studies which, among many other things, should provide information on possible detector concepts matching the performance needs of the FCC physics program. The ARC concept is considered here for the electron-positron phase of the FCC project as a way to enhance particle identification capabilities of the detectors, in particular of the CLD and LAr-calo detector concepts (the IDEA Drift Chamber claims very good PID based on cluster counting; interoperability w/ ARC is interesting but not a priority). There exists two slightly different versions of the ARC concept, developed independently by R Forty, G Wilkinsons and M Tat, and by V Cairo and colleagues. The concepts are now ready to undergo a more realistic simulation for a better understanding of the systems and of the physics potential. The software should be able to handle the two ARC versions. The purpose of the meeting is to establish a concrete plan towards full simulation and reconstruction.
The ARC concept - reminder
(For more details see M Tat 's slides)
Martin reminded the main concepts of ARC. The goal is to cover the momentum range 2 to 40 GeV/c , which is achieved using two radiators, Aerogel and a gas (currently C4F10, to be replaced with a Novec gas, such C5F10O). The hexagonal cell structure has been chosen to eliminate corners where performance is worse. Cells parameters (mirror curvature, mirror position, PMT position and tilt) have been optimized using toy MC based on ray-tracing. While each cell is potentially different, thanks to symmetries there are 18 unique type of cells in the barrel and 21 (or 23) in the end-caps. Martin also mentioned that the effect of the B field was also studied using the same technique and found not significant. For the photon detector, the idea is to use SiPMT (LHCb is using MaPMT, though SiPMT are being evaluated). Photons will probably be in the visible (green), UV are cut out by Aerogel. Aerogel acting as thermal insulator, allows to cool down the SiPMT (to reduce the noise), while keeping the gas at a higher temperature. Aspects of the used coordinate system have been discussed; an optimal geometry description, including the most appropriate coordinate system, is part of the challenge of the DD4hep implementation.
Experience with implementing LHCb RICH 1/2 in DD4hep
(For more details see S Easo's slides)
Sajan reminded the main concepts of LHCb RICh solutions. He went then through the different aspects of the DD4hep implementation. For the visualisation, the main tool is OK, though there is a lack of flexibility due to limitation in ROOT, used under the hood (selective visualisation not available in ROOT; future is in browser, not clear if it would be supported). Also related with ROOT is a problem with the units which caused overlap determination issues related to lack numerical precision. The lack of support for different versions of the same sensitive detector (in the case of LHCb, the two different MaPMT used for RICH1 and RICH2) required a workaround. LHCb also found issues with the implementation of the optical processes in Geant4 which required the use of own geometry functions (e.g. not the ROOT ones); special physics lists have been developed and used only for these subdetectors. Overlaps are checked using the Geant4 overlap checker, which is better than the ROOT one.
Discussion
Markus pointed out that to proceed to the implementation one has to determine the geometry tree, i.e. which cells are required, and the detector tree which is the way these are assembled to get the full detector (layered assembling). The XML defines the parameters used to build the detector in the C++ code. All repetitive or algorithmic functionality should go in the C++ code. Debugging the geometry is the heaviest part, but a bad geometry (in terms of overlaps) might have big consequences in terms of performance and behaviour of the full simulation, so better to spend the time at the beginning to get it right. The choice of good geometry parametrisation, good coordinate systems, and optimal use of symmetries are crucial.
There has been common agreement that we should proceed by steps, starting from the simplest cases to get experience, adding components as soon as a better understanding is achieved. It was proposed to start form the end-caps where the description of the full cells is the simplest.
The workforce aspect was briefly discussed. We agreed that FCC core software will help with implementation of the detector description (XML compact files and C++ code to build the geometry and with the integration in key4hep), so that simulation and validation can start.
G Ganis, 21/12/2022
There are minutes attached to this event.
Show them.
