Added calo cluster informations

[pfedeli]

I Added the branch calorecoinfo with the general cluster information. There is a flag _caloinfo in TrkAnaTreeMaker_module.cc for it, which is now set to True, but we want to provide it as input.

[brownd1978]

It looks odd to me save a single component of a vector. if you need the COG why not just save it? A related question: cog3Vector is defined in the local calorimeter disk coordinate system, while every other vector in TrkAna is defined in the detector (tracker) coordinate system. Does it make sense to first transform it to the detector system, or does your use case require using the disk coordinate system? If the later, the variable name needs to be explicit and a comment added to show the difference.

On Wed, May 8, 2024 at 4:12 PM Andrew Edmonds @.***> wrote:

@.**** commented on this pull request.

In src/InfoStructHelper.cc https://github.com/Mu2e/TrkAna/pull/141#discussion_r1594796339:

@@ -354,12 +357,36 @@ namespace mu2e { tchinfo.csize = cc->size(); tchinfo.edep = cc->energyDep(); tchinfo.edeperr = cc->energyDepErr();

• tchinfo.cposX = cc->cog3Vector().getX();

Thanks. That makes sense

— Reply to this email directly, view it on GitHub https://github.com/Mu2e/TrkAna/pull/141#discussion_r1594796339, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAH577KYNPD26AVA4AAD43ZBKWPDAVCNFSM6AAAAABG4EJ5WWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDANBWHEYDKOBUGE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- David Brown @.*** Office Phone (510) 486-7261 Lawrence Berkeley National Lab M/S 50R5008 (50-6026C) Berkeley, CA 94720

[brownd1978]

One other point: the TrkCaloHitSeed data member _cpos has the same X and Y position as the COG of the associated cluster, in detector coordinates. But while the Z position of the COG is arbitrary, _cpos.Z() instead is the value at the POCA to the track trajectory, and so have valuable information for PID. Could your use case be met by using _cpos (= tchinfo.poca)?

On Wed, May 8, 2024 at 4:21 PM David Brown @.***> wrote:

It looks odd to me save a single component of a vector. if you need the COG why not just save it? A related question: cog3Vector is defined in the local calorimeter disk coordinate system, while every other vector in TrkAna is defined in the detector (tracker) coordinate system. Does it make sense to first transform it to the detector system, or does your use case require using the disk coordinate system? If the later, the variable name needs to be explicit and a comment added to show the difference.

On Wed, May 8, 2024 at 4:12 PM Andrew Edmonds @.***> wrote:

@.**** commented on this pull request.

In src/InfoStructHelper.cc https://github.com/Mu2e/TrkAna/pull/141#discussion_r1594796339:

@@ -354,12 +357,36 @@ namespace mu2e { tchinfo.csize = cc->size(); tchinfo.edep = cc->energyDep(); tchinfo.edeperr = cc->energyDepErr();

• tchinfo.cposX = cc->cog3Vector().getX();

Thanks. That makes sense

— Reply to this email directly, view it on GitHub https://github.com/Mu2e/TrkAna/pull/141#discussion_r1594796339, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAH577KYNPD26AVA4AAD43ZBKWPDAVCNFSM6AAAAABG4EJ5WWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDANBWHEYDKOBUGE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- David Brown @.*** Office Phone (510) 486-7261 Lawrence Berkeley National Lab M/S 50R5008 (50-6026C) Berkeley, CA 94720

-- David Brown @.*** Office Phone (510) 486-7261 Lawrence Berkeley National Lab M/S 50R5008 (50-6026C) Berkeley, CA 94720

[pfedeli]

You are right Dave, Andy told me that too, now I am saving directly the COG vector. In my analysis I use the information of the clusters in the calorimeter coordinates and the kinkal kl fit parameters. For this I needed to create the branch calorecoinfo with the information of all the clusters in the event. I thought to add the cluster position to tchinfo branch just to have a flag to see if, reconstructing the track on my own, I succeed in founding the right nearest cluster among all to the track extrapolation on the calorimeter. By the way, if I understand right, you are saying that tchinfo.poca has the same position in x and y as the cluster centroid, while I thought that the poca vector was the extrapolation of the track on the calorimeter so slighty different from the cluster centroid, and the doca was the distance between poca and cluster centroid. If it is the case we can surely drop my last updates because they are redundant. For what concern the Z-position of the cluster centroid I am absolutely going to use the Z extrapolation of the track and not the cog3Vector.Z() of the CaloCluster.hh class like you suggested.

[brownd1978]

Hi Pierluigi,

On Thu, May 9, 2024 at 1:18 PM Pierluigi Fedeli @.***> wrote:

You are right Dave, Andy told me that too, now I am saving directly the COG vector. In my analysis I use the information of the clusters in the calorimeter coordinates and the kinkal kl fit parameters. For this I needed to create the branch calorecoinfo with the information of all the clusters in the event. I thought to add the cluster position to tchinfo branch just to have a flag to see if, reconstructing the track on my own, I succeed in founding the right nearest cluster among all to the track extrapolation on the calorimeter.

Note that tchinfo refers to clusters that have already been associated with a track. We perform that association as part of the track fit, as the calo cluster time is helpful for constraining the t0 of the track fit. Currently we allow only 1 associated cluster/track, are you looking for additional clusters that might come from a track? Like cosmic muons that go through the tracker and both disks? Or are you thinking of a

By the way, if I understand right, you are saying that tchinfo.poca has the same position in x and y as the cluster centroid, while I thought that the poca vector was the extrapolation of the track on the calorimeter so slighty different from the cluster centroid, and the doca was the distance between poca and cluster centroid. If it is the case we can surely drop my last updates because they are redundant.

The X and Y values of tchinfo.poca and the COG are the same. tchinfo.poca. is the POCA to the track along the cluster axis, which is parallel to Z and goes through the COG in XY. The quantity you mention (track position at POCA ) is computed in the fit but not currently stored in tchinfo. tchinfo.doca is the distance between that position and tchinfo.poca.

For what concern the Z-position of the cluster centroid I am absolutely going to use the Z extrapolation of the track and not the cog3Vector.Z() of the CaloCluster.hh class like you suggested.

sounds good.

Dave

— Reply to this email directly, view it on GitHub https://github.com/Mu2e/TrkAna/pull/141#issuecomment-2103354473, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAH5722TT3QULAG3ISDLH3ZBPKZ5AVCNFSM6AAAAABG4EJ5WWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBTGM2TINBXGM . You are receiving this because you commented.Message ID: @.***>

-- David Brown @.*** Office Phone (510) 486-7261 Lawrence Berkeley National Lab M/S 50R5008 (50-6026C) Berkeley, CA 94720

[pfedeli]

I will remove that information.

The kind of cluster I want to reject are the ones connected to an accidentally cosmic rays that hit the disks while the tracker triggers an event, or, for cosmics that hit both the disk, being able to differentiate them. So for this I added the information of all the clusters in the event. Thanks for the help and the suggestions Dave!

[pfedeli]

Hi Andy, I changed the flag to false. I can see there are some conflict but I am not getting how to solve them, if you can help me it would be great!

[AndrewEdmonds11]

Hi Pierluigi - the conflicts looked a little complicated so I went ahead and resolved them. Could you pull them down, make sure it compiles, and that it runs correctly?

[AndrewEdmonds11]

I've reverted the merge commit that I did to resolve the conflicts (Pierluigi reported that it no longer compiled). Weirdly, it now looks like we can merge so I will try that and then test.

[AndrewEdmonds11]

OK something went wrong... I'll undo this merge