DRICH needs some way of knowing whether a charged particle passed through it or not before attempting track propagation.

[c-dilks]

The DRICH needs some way of knowing whether a charged particle passed through it or not before attempting track propagation. Hopefully there is a better solution than track propagation to some specific 'filter' surface.

Originally posted by @c-dilks in https://github.com/eic/EICrecon/pull/1016#issuecomment-1732768320

[c-dilks]

cf. #564

[wdconinc]

Can you do a quick constant field approximation with a helix?

[c-dilks]

@wdconinc's idea of a big cylinder would work, which encloses the IP and has the radius of the dRICH vessel, and one of the end caps at the dRICH exit plane.

Then make sure the propagated point is on that exit plane.

This should be a filtering algorithm before RichTrack_factory so it could benefit other PID subsystems, or one needs to refactor this:

https://github.com/eic/EICrecon/blob/main/src/algorithms/tracking/TrackPropagation.h#L53-L54

(trackPointCut has a different (important) purpose, so I don't think that can be used.)

[c-dilks]

Can you do a quick constant field approximation with a helix?

This is one of the ideas that came up last time we discussed this issue with the tracking group.

A filtering surface seemed to be the more general solution.

[wdconinc]

This is not just something that affects the dRICH either. We need to propagate every track through either the effective surface of the ecal (endcap or barrel) or until it starts curving back onwards for low energy tracks. The 1000 steps timeouts may be either tracks leaving the hall or tracks spiraling inside the magnet. Neither of those are useful and we need to kill them as soon as we can.

[simonge]

Could the DRICHHits collection be passed to the RichTrack_factory to make sure there exists at least one hit in the dRICH before trying to propagate tracks, or is the absence of the signal in this case important too? I'm just simulating particles in the backwards direction and this is taking 90% of the total computation time (for my subset of collections) to work out it's not hitting the detector.

[c-dilks]

We need this to work for the general event, where we expect tracks in all directions. So a backwards-going track would still have a propagation attempt if we just require dRICH hits, since there are also likely forward-going tracks which pass through the dRICH radiator(s).

[simonge]

I get that, but as a catch for even general events where there actually aren't any dRICH hits this would improve the performance. This is not proposed as the entire solution to this issue. Perhaps a more useful semi-solution would be filtering out trajectories by the associated hit detector/surface ids which should never be able to host a track which propagates into it.