Calculate cluster direction from longitudinal samplings

[giovannimarchiori]

BEGINRELEASENOTES
Use longitudinal samplings of shower to refine cluster barycentre and calculate cluster direction

In addition, make cluster decoration tool work also for clusters in the turbine ecal endcap, so that clusters can be decorated with energy fractions and barycentre vs z layer, and their theta/phi can also be set.
ENDRELEASENOTES

Screenshot of decorations for EMEC clusters, with Elayer/Etot, r_layer, theta_layer, phi_layer, (x10 layers), n_cells

Screenshot of reconstructed phi (20 GeV photon in endcap, phi=45, slight bias observed but no correction and linear energy weighting of cells..)

Screenshot of reconstructed theta (20 GeV photon in endcap, theta=160, no correction and linear energy weighting of cells..)

A couple of screenshots of the reconstructed direction for one 20 GeV photon in endcap)

[giovannimarchiori]

@BrieucF MR ready for you

[BrieucF]

Hi Giovanni, thanks for this! For this one, fitting by eye gives a quite different result, or is it me?

[pjanot]

Hi Brieuc, You don't even need to fit by eye: the direction of the particle (track? true particle?) is on the same display in very light white and black/green dots , and it differs a lot from the from the fitted line (thick white line) Patrick. On 15 Jan 2026, at 09:52, Brieuc Francois ***@***.***> wrote: [https://avatars.githubusercontent.com/u/3646269?s=20&v=4]BrieucF left a comment (HEP-FCC/k4RecCalorimeter#193)<#193 (comment)> Hi Giovanni, thanks for this! For this one, fitting by eye gives a quite different result, or is it me? — <https://github.com/user-attachments/assets/966e5cf1-22e9-4e38-9b48-51d607da2eec> [preview.png] 536124908-966e5cf1-22e9-4e38-9b48-51d607da2eec<https://github.com/user-attachments/assets/966e5cf1-22e9-4e38-9b48-51d607da2eec> PNG Image · 254 KB<https://github.com/user-attachments/assets/966e5cf1-22e9-4e38-9b48-51d607da2eec> Reply to this email directly, view it on GitHub<#193 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABWI4QIUS2LSUDN4JVPU7DT4G5IOXAVCNFSM6AAAAACLGIQRY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONJTGYYTEMZSG4>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[giovannimarchiori]

Hi @BrieucF , I agree with you. And in fact, in my initial comment, I wrote "slight bias observed but no correction and linear energy weighting of cells..". This is for the endcap OOTB... As I said in the past, the performance of the algorithm has to be studied, understood and improved. This PR does not mean to provide a final solution, but an initial piece of code (basically ported from Pandora) to allow such studies and refining the algorithm. BTW, the algorithm itself does not use the red dots (G4 steps) as input but the digitised cells

[BrieucF]

Ok, let's then add a disclaimer (and what this PR does) in the docstring of the header file.

[BrieucF]

Can you reflect the modifications from this PR in the doc string?

[BrieucF]

And a disclaimer saying it should be improved

[BrieucF]

It looks like this is no longer looping over clusters

[BrieucF]

This will be deprecated soon, please use setIPhi() (https://github.com/key4hep/EDM4hep/blob/main/edm4hep.yaml#L424)

[BrieucF]

I guess a possible bias could come from this

  /// Weights for each detector layer for theta position log-weighting
  Gaudi::Property<std::vector<std::vector<double>>> m_thetaRecalcLayerWeights{
      this,
      "thetaRecalcWeights",
      {{-1, 3.0, 3.0, 3.0, 4.25, 4.0, 4.0, 4.0, 4.0, 4.0, 4.0}},
      "Weights for each detector layer for theta position log-weighting. If negative use linear weight."};

but ok, we can leave the tuning of the method for a later PR, provided that it is clearly stated that it was not tuned yet.

[BrieucF]

Should'nt we also update the cluster position?

[BrieucF]

Hi @BrieucF , I agree with you. And in fact, in my initial comment, I wrote "slight bias observed but no correction and linear energy weighting of cells..". This is for the endcap OOTB... As I said in the past, the performance of the algorithm has to be studied, understood and improved. This PR does not mean to provide a final solution, but an initial piece of code (basically ported from Pandora) to allow such studies and refining the algorithm. BTW, the algorithm itself does not use the red dots (G4 steps) as input but the digitised cells

Are you sure it is not with the logE weights already? From there

        if (m_thetaRecalcLayerWeights[k][layer] < 0) {
          sumThetaLayer[layerToFill] += (eCell * theta);
          layerCentroids[layerToFill] += (eCell * v);
        }
        else {
          sumThetaLayer[layerToFill] += (weightLog * theta);
          layerCentroids[layerToFill] += (weightLog * v);
        }

and the values of m_thetaRecalcLayerWeights it seems to me that we are using the logE weights.