Implementation of "Analogue clustering" calibration method in Tracking/Acts
This MR starts the port of the "Analogue Clustering" pixel measurement calibration strategy to the Acts side.
- Implemented basic structure of tool, templated on trajectory type & the calibration data class (the latter is to keep implementation nominally decoupled from a specific detector)
- Implemented position and error calibration within said tool
- Implemented ITkAnalogueClusterizationTool as instantiation of the above
- Implemented python-side config
- Added a CI test
It is now possible to run with this calibration enabled, but it needs some tuning: see dcube output.
I propose we merge it now since it does work but leave it off as a default. I likely won't have significant time to look into this again for 1 or 2 weeks and I would like to avoid this developing conflicts in the meantime.
Merge request reports
Activity
added 1 commit
- 75110f22 - Add typename's to avoid breaking gcc11 build
20 { 21 ATH_MSG_DEBUG("Initializing " << AthAlgTool::name() << " ..."); 22 ATH_CHECK(m_pixelDetEleCollKey.initialize()); 23 ATH_CHECK(m_clusterErrorKey.initialize()); 24 ATH_CHECK(m_lorentzAngleTool.retrieve()); 25 ATH_MSG_DEBUG(AthAlgTool::name() << " successfully initialized"); 26 return StatusCode::SUCCESS; 27 } 28 29 template <typename calib_data_t, typename traj_t> 30 const InDetDD::SiDetectorElement* 31 AnalogueClusteringToolImpl<calib_data_t, traj_t>::getDetectorElement(xAOD::DetectorIDHashType id) const 32 { 33 SG::ReadCondHandle<InDetDD::SiDetectorElementCollection> pixelDetEleHandle( 34 m_pixelDetEleCollKey, 35 Gaudi::Hive::currentContext()); 
I agree it would be clearer & I do think it would be natural for the event context to be exposed from the Acts-side contextual objects, but I think we can have that discussion later. Since we don't have that now there is no other way since the call comes from deep inside the Acts fitter.
In principle, we have the calibration context for this purpose. Did you think about putting the event context in there? One could even go one step further and require setting up the context with the error data already, if we think the lookup down in the call chain is a performance issue.
-
@pagessin I think exposing the event context through our context objects makes a lot of sense. For the error data, that's a good point -- we'd set it up once per event instead of once per calibration call, but I'm not sure if it's a measurably costly operation (@goetz maybe?). If we go this way, we'd need to be sure to only do this on-demand (i.e. not if not using calibration or using pixel NN or ....)