Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Charge attenuation from finite electron lifetime #228

Open
krwood opened this issue May 13, 2024 · 1 comment
Open

Charge attenuation from finite electron lifetime #228

krwood opened this issue May 13, 2024 · 1 comment

Comments

@krwood
Copy link
Member

krwood commented May 13, 2024

Currently, the attenuation of ionization signals as they traverse the LAr to the anode plane for readout is done on a segment-by-segment (sometimes referred to as "tracks" in larnd-sim) basis. This means that longer segments that traverse a range of drift distances from the anode will suffer from having an average attenuation applied instead of one that is dependent on the local distance to anode from and allowed to vary across the segment.

It would be better to apply this attenuation after the segment has been projected onto the pixel plane so one can calculate the attenuation on a packet-by-packet basis.

It's also true that a response is induced on a pixel before the charge arrives at the pixel itself, and so, strictly spreading, it isn't correct to apply this attenuation factor once and before any pixel response is calculated.

@YifanC
Copy link
Collaborator

YifanC commented May 13, 2024

Agree on the comment that the varied length for segments may cause inaccurate electron lifetime application!
It would be good to voxelize larndsim early on, so we move away from segments.
However, I would argue for both electron lifetime and the field response, they are integrated effect. I'm not sure there's a strict order, but we can potentially interface the electron lifetime in the integral path. My naive understanding is that the field response would have larger impact for the close to anode path, so perhaps doing this way around isn't catastrophic?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants