Rich update with additional detector element access classes

This contains the remaining DeXX classes for Rich mirrors, PMTs in Rich1 and Rich2.

Also contains an overhaul of the classes, developed with the reconstruction for better support there.

1. Introduce a number of base classes for shared generic functionality. Greatly simplifies the implementation in a number of places (e.g. the mirrors where there are four types, but now most of the functionality is in a single place). Also aids in the reconstruction downstream where having a single type that each entity can be access via is very useful.

2. A general clean up / modernization of the code.

3. Improvements to some static generator methods, which where not thread safe and also leaked memory on shutdown because the global static entities were never deleted.

assigned to @bcouturi

@seaso This MR has conflicts against master. Could you take a look ?

@seaso Just looking at the changes, it would be useful if you could provide (or just point me at if its already there) examples on how to access all the primary and secondary mirror segments from the DeRich1 and DeRich2 handle classes. Basically, what the reco. needs is something like the currently commented out methods

    /// Should return a vector of all primary mirror detector elements
    // inline auto& primaryMirrors() const noexcept { return ......; }

    /// Should return a vector of all secondary mirror detector elements
    // inline auto& secondaryMirrors() const noexcept { return ......; }

does this MR provide what is needed to be able to implement these methods ?

I think that, one cannot provide a vector of pointers to ‘actual detelements’, since it may not be safe in terms of their memory address. I think what you meant is pointer to 'XXelement' classes.

One can easily create a method which gives pointer to any given ‘mirror segment element’, along the lines of what is already done in Rich1_dump_detelem.cpp for these, in this MR. In practice it will give access to any related info on that segment as illustrated. In this case, having such a method directly from DeRich1, is just a matter of convenience and I can make one if needed.

As for MR conflict, I shall sort this. I kept this as a ‘draft’ since I may have some more updates soon and figured I do all MR stuff in one go.

@seaso I mean a vector of the 'handle classes', whatever they are called in dd4hep (sorry, its language still confuses me a little), that are the equivalents of what I currently get for the DeRich1, DeRich2 classes etc. As these handle classes are light, and transient, they can be passed by by value, or copied just fine. There are no memory issues with them.

@seaso Just to clarify a little. What I do not want is a method where I have to know the 'mirror number to ask for' and thus have to know via some other source what these numbers are. What I need is a single call like that above that gives me back all the objects in one go, in a vector, as then its completely unambiguous a) how many there are and b) what they are.

So, e.g. @seaso , If I look at the DeRich1Element class

https://gitlab.cern.ch/lhcb/Detector/-/blob/dd4hep-RichDetectorSystem-FromFebruary15-2022/Detector/Rich1/include/Detector/Rich1/DetElemAccess/DeRich1.h

What I believe I want from the methods

 // inline auto& primaryMirrors() const noexcept { return ......; }     
 // inline auto& secondaryMirrors() const noexcept { return ......; }

are vectors of the DeRich1Mirror1SegElement and DeRich1Mirror2SegElement objects respectiviely, as implemented in

https://gitlab.cern.ch/lhcb/Detector/-/blob/dd4hep-RichDetectorSystem-FromFebruary15-2022/Detector/Rich1/include/Detector/Rich1/DetElemAccess/DeRich1Mirror1.h

https://gitlab.cern.ch/lhcb/Detector/-/blob/dd4hep-RichDetectorSystem-FromFebruary15-2022/Detector/Rich1/include/Detector/Rich1/DetElemAccess/DeRich1Mirror2.h

as these are the 'lightweight' handle classes I was talking about, there should be no issue with passing back by value a vector of them, as they can be copied etc. just fine, as they are only handles over the real objects.

and then the equivalent for DeRich2Element.

btw. @seaso It does not have to be exactly as I describe above. e.g. the DeRich1Element class could just give me back the master objects for the mirrors, e.g. DeRich1Mirror2MasterElement and from there I get the vector of all mirrors. That will work just fine.

So, just to rephrase slightly what I need, starting from the DeRich1Element and DeRich2Element objects, I need a way to get to all the individual mirror handles for each.

DeRich1Mirror2MasterElement almost has what I want, namely

 auto Rich1Mirror2Seg( int aS ) const noexcept {       
return DeRich1Mirror2Seg( &( this->access()->m_Rich1Mirror2SegDetElem[aS] ) );    
 }

I just need a method very similar to that, that gives all the mirrors not just a single one.

added 1 commit

• 8822650c - Updates with detector element access classes related to Mapmt structures

Compare with previous version

added 1 commit

• 51fd604b - Fixed formatting

Compare with previous version

added 2 commits

• ec07c256 - Adding some vectors in detelement access classes
• e4a6057e - Minor Updates to detector element vectors

Compare with previous version