Realistic BTOF digitization #1635
Conversation
Update BTOFHitDigi.cc
Update BTOFHitDigi.h
Update BTOFHitDigi.cc
… distance relative to the center of the center cell. Now it's changed so spread is calculated relative to the true hit location.
…ighbors when cell ID from BitFieldDecoder for cellID is negative.
…ith dead spaces implemented.
…ion-clusterization
github-actions
bot
added
topic: tracking
There was a problem hiding this comment.
@ssedd1123 Looks good, you've addressed my main concern about accepting hits at any time in the pulse generation.
I have a couple of comments in the digitization code but otherwise happy enough for a first implementation now.
Down the line I would still like to see some changes to make this more reflect the separation of analogue and digital components of the readout in a more general way.
| double thres = -m_cfg.t_thres; | ||
| int adc_range = m_cfg.adc_range; | ||
|
|
||
| for (const auto& pulse : *simhits) { |
There was a problem hiding this comment.
This will currently produce multiple hits for the edge cases where the analogue signal is above threshold on both sides of a 25ns boundary. This is (almost certainly) not going to be how the electronics works but hopefully won't cause issues at the moment.
There was a problem hiding this comment.
You are correct. In the current implementation, if a pulse crosses the threshold very close to the 25 ns boundary, it will result in two hits: one with the correct TDC but incorrect ADC, and the other with the incorrect TDC but correct ADC. As you've rightly pointed out, this occurs because the time when the pulse crosses the threshold and the location of the pulse peak fall into different 25 ns windows.
I anticipated this issue and briefly mentioned it in my reply on December 20. However, I didn't take any further action because, as frustrating as it sounds, all the experts I consulted are also unsure about what will happen in such edge cases. The electronics are still under development, and I don't think anyone knows how this will behave in real-world scenarios.
I believe the best course of action is to document this behavior so that it can be addressed more accurately once we have more information. For now, I believe this is good enough as a reasonable first step toward digital simulation.
Co-authored-by: Simon Gardner <[email protected]>
…ough is now a config parameter. The condition to check if 2 cells belong to the same sensor is now also a config parameter.
…com/eic/EICrecon into pr/BTOF-digitization-clusterization
for more information, see https://pre-commit.ci
…com/eic/EICrecon into pr/BTOF-digitization-clusterization
This improves portability.
…, algorithms_digi depends on evaluator)
Capybara summary for PR 1635
|
|
Okay, last comment from me! The capybara report makes it seems like there's a few cases where a |
This is expected for 64 bit values. We often have upper 32 bit split into x and y coordinates that are non-zero and produce an overall large cellID. |
Ahhhhh gotcha! I see! |
|
Sorry I did not update this request for a month. Unfortunately I am having significant difficulty with my work visa so I am legally forbidden from performing any research related work at the moment. I will return to this request once I worked out my visa situation. |
No worries! We completely understand given the situation! Just let us know if you need help, and we'll be happy to jump in! |
Briefly, what does this PR introduce?
It's an attempt to make LGAD sensor response for Barrel TOF more realistic by doing the following,
Noise, edge correction and time talk correction will be developed in the future.
What kind of change does this PR introduce?
Please check if this PR fulfills the following:
Does this PR introduce breaking changes? What changes might users need to make to their code?
Does this PR change default behavior?
It replaces the content of "TOFBarrelRecHit" with results of this new clusterization. It was originally just geant point + random smearing. I have communicated to the reconstruction group and they advise that I submit this pull request so they can study the effect of having this new digitization/clusterization algorithm. They will decide if I should save the data in a new branch or replace the origin content.