Open wdconinc opened 2 months ago
Hi Wouter,
not sure I correctly understand you...
In principle the segmentation handle class in DD4hep/Segmentations.h
allows to access the underlying cell dimensions
in an abstract way independent from knowing the concrete implementation:
/** \brief Returns a vector<double> of the cellDimensions of the given cell ID
* in natural order of dimensions, e.g., dx/dy/dz, or dr/r*dPhi
*
* \param cellID cellID of the cell for which parameters are returned
* \return vector<double> in natural order of dimensions, e.g., dx/dy/dz, or dr/r*dPhi
*/
std::vector<double> cellDimensions(const CellID& cellID) const;
Does this not work correctly for MultiSegmentation
objects ?
If not, this is a bug, but the implementation does not suggest so:
std::vector<double> MultiSegmentation::cellDimensions(const CellID& cID) const {
return subsegmentation(cID).cellDimensions(cID);
}
But clearly the meaning of the elements of the returned vector depend on the concrete sub-segmentation.
In your code link you only seem to be interested in the cellDimensions
, so where is your problem?
In the ePIC event reconstruction framework we store the cell dimensions as part of calorimeter hits. Depending on the type of segmentation, we store different values, so we have a selection based on
auto segmentation_type = m_converter->findReadout(local).segmentation().type();
. E.g.For some calorimeters we have a MultiSegmentation, and we would like to resolve the specific segmentation type of the hit before we get into our
if
statements.We have implemented this with some internal implementation calls at https://github.com/eic/EICrecon/pull/1594/files. In particular, we now use the underlying detail pointers:
We're wondering if there's a way to handle this (no pun intended) with just Handles, without relying on internal implementation details.