WIP: Add Area accessor for calorimeter parts

This MR is a preparation to alter CaloFutureTrackMatch algorithm from Rec.

A new method Area is introduced to DeCalorimeter that returns identifier of calorimeter area (Inner, Middle, Outer) that a 3D point is inside. Currently for this case the Cell_ method is used: first a cell is extracted and then the area is determined from the cell. This relies on the costly IGeometryInfo::isInside method.

The Area relies only on IGeometryInfo::toLocal which AFAIU should take into account alignment, and on the X and Y size stored in the ConDB and accessible by DeSubSubCalorimeter::xSize and DeSubSubCalorimeter::ySize. In my profile tests it is ~5-6 times faster compared to calling Cell_.

It also relies on the order in which SubSubCalorimeter instances are stored in SubCalorimeter - Inner first, Outer last. There is also change in treatment of the beam hole - it is now part of Inner area.

As a byproduct I reduced usage of isInside in the Cell_ method and there should be slight speedup from first considering the Inner part as I assume more tracks are to be expected closer to the beam - I did not check this assumption very thoroughly though.

There is an additional possible speedup (in my back of the envelope calculations its ~25%) if the X/Y sizes of A and C sides and the whole calorimeter would be available through DeCalorimeter and DeSubCalorimeter classes as in the DeSubSubCalorimeter one. This code is currently commented out and marked as TODO. How would I go about it? Make a MR for lhcb-conddb project with altered relevant structure.xml files??

Needed for Rec!1842 (closed)

added Calo label

mentioned in merge request Rec!1842 (closed)

Correct me if I am misunderstanding something, the size of the Calorimeter is redundant information in the database if the positions and sizes of the sub parts are known. If yes, could you calculate the size on the fly when creating or updating DeCalorimeter due to a conditions change, and then cache it?

changed the description

I think that for the A/C side this should be easy as I have access to instance of Outer SubSubCalo and could simply use its size. For the whole calorimeter I could just take 2*size of single half in X. I think this is what is actually used in the ECAL geometry.xml anyway: https://gitlab.cern.ch/lhcb-conddb/DDDB/blob/master/Ecal/geometry.xml#L79

I'll try and propose a change that incorporates this.

What I do not understand is what happens on conditions change. Are the DeCalorimeter objects recreated?

added 98 commits

• 1e3c5417...1fa18099 - 92 commits from branch master
• c4035340 - Speedup determination of Calo area.
• c161d37f - Small improvements
• d7798cb1 - Change return type of DeCalorimeter::Area to std::optional.
• 46aa3adb - Implement auto determination of calorimeter dimensions
• ae5bfbe2 - Fix logic error.
• 3d9826e2 - Lint fixes.

Compare with previous version

The DeCalorimeter and DeSubCalorimeter dimensions are now calculated from the Outer DeSubSubCalorimeter. The DeCalorimeter::Area and DeCalorimeter::Cell use this info to finish early the iteration over SubSubCalorimeters.

The DeCalorimeter::Area returns a std::optional.

@sstahl As for the implementation of derivedCondition - I think the TrackMatchAlg in Rec would be the right place: https://gitlab.cern.ch/lhcb/Rec/blob/master/CaloFuture/CaloFuturePIDs/src/CaloFutureTrackMatchAlg.cpp#L39

The current implementation uses a state of TrackTool to store an instance of DeCalorimeter: https://gitlab.cern.ch/lhcb/Rec/blob/master/CaloFuture/CaloFuturePIDs/src/CaloFutureTrackTool.cpp#L39.

This is not thread safe, right? I could pass the DeCalorimeter obtained by the Algo as derivedCondition to the TrackTool methods as an additional paramater. Is there a better way?

Anyway the changes would be in the Rec package so I think this MR is ready.

unmarked as a Work In Progress

Hi @conrad, I notice you un-wip-ed this, but I guess we should wait for Rec!1842 (closed) and test them together?

This MR will work without Rec!1842 (closed), as it does not break the current interface. So we can do what's more convenient, merge this now and then cope with Rec!1842 (closed) or test them together.

Cool. I guess its better to spot problems early. I will start a ci-test.

/ci-test --merge

/ci-test --merge

Looks like that #Digit->MC links changed in the EcalDigitMCTruth algo. Looking through https://gitlab.cern.ch/lhcb/Lbcom/blob/master/Calo/CaloAssociators/src/CaloDigitMCTruth.cpp it is not obvious where a call to DeCalorimeter::Cell or DeCalorimeter::Cell_ would be made. Maybe when the digits are created??

Where should I look to find the code that creates the calo MC digits?

Also how do I run Boole on upgrade data, is there some default config available? So far I was testing the code with Brunel.

I know the links between Digits and MCDigits are created in CaloReCreateMCLinks but I don't know where MCDigits themselves are created. @jmarchan is looking into the encoding in Boole, hopefully he has been looking into this

@conrad please remove the WIP (and assign to the shifter) when you finished investigating

mentioned in issue Moore#141 (closed)

marked as a Work In Progress

assigned to @conrad

A small update.

Changing the order in which subSubCalos are stored (!2267 (diffs)) resulted in all MCCaloDigits having different energies.

I was looking into Boole/Calo/CaloDigit/src/CaloSignalAlg.cpp where AFAIU MCCaloDigits are created but so far everything is the same there.