tanDip bug?

[sam-grant]

Possible tanDip bug

Hi all,

I have found a potential issue with tanDip going negative for downstream going track segments in EventNtuple, and would appreciate some guidance on how to proceed, since I use this parameter for a selection cut in an ongoing analysis.

As I understand it, tanDip = pz/pt per intersection. Therefore, if I apply a mask according to p_z > 0 per segment I should not see any negative tanDip values since it is signed by the z-momentum.

However, when I plot tanDip for downstream going track segments at the tracker entrance, I see negative peaks in both CeEndpoint and CosmicCRY nts datasets:

Additionally, if I calculate tanDip from the track segment momentum vector, I see something which looks much more sensible:

It was suggested that tanDip might be calculated at the stopping target and then broadcast to all segments, but I don't think that's what's happening. For one thing, if I simply print out the arrays for a single track I see tanDip changing over z-position and momentum:

trksegs.mom.fCoordinates.fZ: [[-23.8, -9.8, -9.8, -10.0, 30.4, 49.7, 49.5, 54.1, 54.9, 55.5]]
trksegs.pos.fCoordinates.fZ: [[-4122.2, -4350.5, -4350.5, -4359.2, -3922.2, -2679.8, -2381.0, -1631.1, 10.1, 1639.1]]
trksegpars_lh.tanDip: [[0.6, 0.5, 0.3, -0.2, 0.6, 0.6, 0.6, -0.1, -0.1, -0.1]]

I had a look at the code, and it all looks reasonable to me, although there is a subtlety where tanDip is calculated at trksegspars_lh.t0, here, which is not the same thing as trksegs.time.

trksegs.time: [[709.2, 714.0, 714.0, 714.3, 728.9, 739.4, 741.5, 746.4, 756.8, 767.0]]
trksegpars_lh.t0: [[757.5, 758.9, 773.4, 648.1, 756.9, 756.7, 756.8, 567.7, 567.7, 549.9]]

I understand that tanDip is marked as "deprecated", but it is still used as one of the "standard" track cuts, so I would appreciate some guidance on what to do here. Should I just calculate tanDip by hand from the momentum vector, or is there something I'm missing about this parameter.

Thanks,
Sam

[sophiemiddleton]

Good spot Sam! As you say we are actively trying to replace these old cuts, but while they are still present we should make sure they are correct.

[brownd1978]

'tandip' was a parameter of the (obsolete) BTrk Kalman filter fit. It is neither physical, nor does ever appear in any calculation used in current track reconstruction. That is why it is marked 'deprecated' The actual values stored in the art output for reconstructed track segments are the particle momentum, position, and time (plus covariance), plus the local BField sampled at that point. The parameters in the LH branch are derived from those stored values, and are there to support studies by tracking experts, not analysis. Those parameters are relative to the local BField direction, which is not along Z, and as such they cannot be interpreted as physical quantities. Sam's data show the calculation of 'tandip' in the LH branch likely has a bug. I am investigating. Finally, note that 'tandip', and even the more physical Pz/Pt are not constants of particle motion in Mu2e, due to our graded magnetic field. You will get different values if you sample different segments of the same track, making its use in analysis problematic. I strongly recommend analyzers investigate using more physical variables for track selection, which are now available in EventNtuple through track segments sampled at extrapolated positions. Dave

…

On Mon, Jul 14, 2025 at 2:33 PM Samuel Grant ***@***.***> wrote: *sam-grant* created an issue (Mu2e/EventNtuple#287) <#287> Possible tanDip bug Hi all, I have found a potential issue with tanDip going negative for downstream going track segments in EventNtuple, and would appreciate some guidance on how to proceed, since I use this parameter for a selection cut in an ongoing analysis. As I understand it, tanDip = pz/pt per intersection. Therefore, if I apply a mask according to p_z > 0 per segment I should not see any negative tanDip values because it is signed by the z-momentum. However, when I plot tanDip for downstream going track segments at the tracker entrance, I see a large negative peak in both CeEndpoint and CosmicCRY nts datasets: h1o_debug_tanDip.1.png (view on web) <https://github.com/user-attachments/assets/7ca1cfc2-6994-4fbc-9f4f-b4099cb3e7d5> Additionally, if I calculate tanDip from the track segment momentum vector, I see something which looks much more sensible: h1o_tanDip_calc.1.png (view on web) <https://github.com/user-attachments/assets/6019477b-a4e7-45b4-ad87-868077a6fd04> It was suggested that tanDip might be calculated at the stopping target and then broadcast to all segments, but I don't think this is what's happening. For one thing, if I simply print out the arrays for a single track I see tanDip changing over z-position and momentum: trksegs.mom.fCoordinates.fZ: [[-23.8, -9.8, -9.8, -10.0, 30.4, 49.7, 49.5, 54.1, 54.9, 55.5]] trksegs.pos.fCoordinates.fZ: [[-4122.2, -4350.5, -4350.5, -4359.2, -3922.2, -2679.8, -2381.0, -1631.1, 10.1, 1639.1]] trksegpars_lh.tanDip: [[0.6, 0.5, 0.3, -0.2, 0.6, 0.6, 0.6, -0.1, -0.1, -0.1]] I had a look at the code, and it all looks reasonable to me, although there is a subtlety where tanDip is calculated at trksegspars_lh.t0, here <https://github.com/Mu2e/EventNtuple/blob/main/src/InfoStructHelper.cc#L137-L161>, which is not the same thing as trksegs.time. As I understand it, t0 is the time when the helix crosses z=0. trksegs.time: [[709.2, 714.0, 714.0, 714.3, 728.9, 739.4, 741.5, 746.4, 756.8, 767.0]] trksegpars_lh.t0: [[757.5, 758.9, 773.4, 648.1, 756.9, 756.7, 756.8, 567.7, 567.7, 549.9]] I understand that tanDip is marked at "deprecated", but it is still used as one of the "standard" track cuts, so I would appreciate some guidance on what to do here. Should I just calculate tanDip by hand from the momentum vector, or is there something I'm missing about this parameter. Thanks, Sam — Reply to this email directly, view it on GitHub <#287>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAH576CD2JBKI2POCP4JIT3IQAXJAVCNFSM6AAAAACBP5X3HGVHI2DSMVQWIX3LMV43ASLTON2WKOZTGIZDSOBQGQ4TIOI> . 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

[sophiemiddleton]

Thanks Dave for the detailed explaination, your last sentence is what we hope to encourage moving forward and as we discussed last week the utils will soon be upgraded to support that.

[sam-grant]

Thanks Dave. I'll do some work to understand whether tanDip can be dropped entirely from my analysis and will move towards using constants of particle motion for track cuts as a general rule.

Mostly for my own reference: I'll also look at using number of intersections at the a surface, as shown in your DocDB-53334, to replace cut parameters like d0.

[brownd1978]

I have isolated the source of the discrepancy between tandip (parameter) and Pz/Pt seen by Sam. The sort at this line <https://github.com/Mu2e/EventNtuple/blob/95cfd0054fba1bb719d98d308034f4c695eb78ef/src/InfoStructHelper.cc#L133> scrambles the synchronization between the trksegs branch and the trksegspars_lh branch, so that selections made on one give different values than the other. Can anyone comment whether the time ordering applied by this sort is important for analysis or not? If so, we have to restructure how the 'pars' branch is filled. If not the fix is simply to remove that line.

…

On Tue, Jul 15, 2025 at 10:20 AM Samuel Grant ***@***.***> wrote: *sam-grant* left a comment (Mu2e/EventNtuple#287) <#287 (comment)> Thanks Dave. I'll do some work to understand whether tanDip can be dropped entirely from my analysis and will move towards using constants of particle motion for track cuts as a general rule. Mostly for my own reference: I'll also look at using number of intersections at the a surface, as shown in your DocDB-53334 <https://mu2e-docdb.fnal.gov/cgi-bin/sso/ShowDocument?docid=53334>, to replace cuts parameters like d0. — Reply to this email directly, view it on GitHub <#287 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAH577Q3RN5FZ2OIKRRLM33IUL27AVCNFSM6AAAAACBP5X3HGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZUGEYDGMZWGA> . 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

[sophiemiddleton]

Hi Dave,

I introduced that to solve this #235 (comment)

I think it does help a little with the analysis, at least ive found it iseful, but, we should ensure that it doesnt effect what yoi can do with the pars branch.

Can you provide an example peice of code (i mean a simple code example) thay I could look at to see if theres a quick fix

[AndrewEdmonds11]

This is fixed with #288