ODD Strip Module Handling, main branch (2024.05.08.) #581
Conversation
Based it on the RMS of the variation on the second dimension of the binning data. Since this is set to a large value for strip detectors in our current setup.
Filling it from the newly added peoprty in the digitization data, during cell reading.
krasznaa
added
cuda
There was a problem hiding this comment.
Note that I also didn't touch the spacepoint creation algorithm in this PR. That one will need a bit more careful PR, since our device code currently assumes that it would create a fixed sized space point collection. Which would have to become a resizable one. 🤔
So, in a future PR...
core/include/traccc/clusterization/impl/measurement_creation.ipp
Outdated
Show resolved
Hide resolved
|
I'll open a PR with "truth maching code updates" still today. But until then, somebody should have a look at this PR. Since the truth matching code that I'll propose, absolutely relies on these changes. |
|
This sort of "detector description" information will have to remain in some traccc specific format, so that we could give it to the measurement and spacepoint creation algorithms conveniently. But the source of the information will not remain so hacky of course. I've been working for a while on replacing our current cell_module type completely. It was just not the highest priority recently. But I'll have a proposal soon for how we should handle this info in our algorithms in the long term. 😉 |
As discussed many times recently, currently we are handling all modules / surfaces as pixels when reconstructing ODD data. Which leads to some funky behaviour in its short and long strips.
As discussed on Mattermost, we can use a sort of hacky way to determine which modules / surfaces are 1D and 2D, by looking at the variations assigned to their 2 dimensions. Since the digitization config always describes 2 dimensions for the surfaces, even for strip modules. (It's a long story...)
With the info added to
traccc::digitization_configand then totraccc::cell_module, I could make the host and device measurement creation algorithms take this information into account.It did not cause any significant changes in our host<->device agreement numbers, those just moved around a tiny bit. But also, this did not seem to break anything either... 😉