Track extrapolation to ECAL calorimeter surface#64
Conversation
Fixes the pre-commit clang-format CI failure on PR #64. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The earlier clang-format pass used a newer clang-format that realigned the pre-existing m_initialTrackError_* continuation lines; CI's version disagrees. Restore the original alignment. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
acts tightened the OnLayerReturnsNode concept in BlueprintBuilder.hpp to require the callback result to be exactly std::shared_ptr<BlueprintNode> (std::same_as), so unsetXYCoG returning the derived std::shared_ptr<LayerBlueprintNode> no longer satisfies it and ElementLayerAssembler::onLayer fails to resolve. Return the base BlueprintNodePtr instead; `return layer;` upcasts implicitly. This satisfies the current concept and remains valid if acts-project/acts#5563 (which relaxes same_as -> convertible_to) is merged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…Tracking into calosurface-extrapolation
|
A couple of plots to validate the extrapolation against RefitFinal (using the MAIA geometry) 
|
madbaron
changed the title
paulgessinger
left a comment
paulgessinger
left a comment
There was a problem hiding this comment.
I'm not completely sure I understand the different between the ACTSSeededCKFTrackingAlg and the CKFTrackingAlg.
Otherwise, this is a way to do it. Pre-resolving the candidates by straight line intersect can sometimes fail. Another way (although I haven't tested this yet), would be to include the calo target surfaces as external surfaces in a regular navigation which includes the geometry. You could then attach a custom actor that terminates as soon as one of the surfaces in question is hit. That way, you wouldn't have to pre-resolve the candidates at all, and it would cleanly integrate the material handling, if needed.
|
2 participants
BEGINRELEASENOTES
ENDRELEASENOTES
PR aimed at #55.
This PR will make the ACTS tracks directly consumable by the Pandora algorithms (the state at calo is required to do track-to-cluster matching)
The extrapolation to the calorimeter face is currently done with the VoidNavigator outside of the tracking volume. For detector concepts with significant material between the tracking systems and the calorimeters, this simplification will have a non-negligible effect.
I'd plan to change this in a follow-up PR once material handling is introduced throughout the package.