Introduce traccc::silicon_detector_description, main branch (2024.06.21.)

[krasznaa]

This is going to be a big, and painful PR... It attempts to completely re-design how we deal with "detector description information" in the algorithms.

At the moment we create two "event data" collections as input to our algorithm chain.

• traccc::cell_collection_types: Describing the actual cell (pixel/strip) data;
• traccc::cell_module_collection_types: Describing the modules that the cells are on.

The latter collection we create separately for each event, and have to ship event-by-event to a device to use.

Instead of doing that, one should (of course...) only copy the description of every detector module to the device once (per IoV...). And have the cells refer to that global object. The detray::detector object is not enough for this as it happens. Since the tracking geometry doesn't (and shouldn't) know about the segmentation of the modules, the signal thresholds in them, etc. This is where the traccc::silicon_detector_description type comes in. 😄

It's an SoA container based on vecmem::edm. Ensuring that since most clients will only need to access a small part of a module's info at a time, this would be done efficiently.

At the same time I also created some "named Detray detector types" in the code. With the intention of bringing the templating of the track finding and fitting algorithms under control. And also allowing to centralise the I/O of the geometry and detector description info a little better. Note that with all these "geometry updates" the client code for constructing traccc::default_detector::host and traccc::silicon_detector_description::host becomes a bit less sketchy than what we're doing now. (Most importantly, we don't need to pass around a weird std::map between function calls in this setup.)

Since traccc::cell_module is used in half of our source files (with a bit of exaggeration), I didn't yet manage to update all of the project to the new status quo yet. Hence the draft status for now. I just wanted people to have a look already, since I've been working on this code for long enough already... (Check the name of my branch...)

[beomki-yeo]

I might be OK with that but this is also time we need to think of the extension to wire measurements.
As we elaborate detector description for pixel/strip based on the digitization it is going to be difficult to harmonize with gaseous detector measurement such as straw tube or drift chamber. They are not described by cell type and don't have segmentation like pixel does.

This may have nothing to do with this PR but it is not bad to keep that in mind in the detector description design.

[krasznaa]

I don't even know conceptually what we'll want to do with clusterization and seeding in gas detectors. 🤔 But we'll need to find a unified interface for their "detector description" eventually for sure...

[stephenswat]

Does anyone really do seeding in gas detectors? Correct me if I am wrong, but I don't think ATLAS does, right?

[beomki-yeo]

For wire measurements, it is more like a peak search in the ADC data rather than clusterization
Still I am not also sure about exact data type. We might need to ask Phase 1 reconstruction experts.

Does anyone really do seeding in gas detectors?

Maybe not for ATLAS TRT. But other experiments, yes

[krasznaa]

Yes, we'll need to discuss about this soon. Since in general the input EDM of the relevant algorithms will probably need to be generalized in the end. 🤔 Eventually we'll probably want to name our current cell collection to something like Acts::Acc::SiCellCollection. (Just to foreshadow the general renaming that awaits us during the migration into the Acts repository...)

[stephenswat]

Overall I really like the look of this; I appreciate the simplification of having the same type for all of this information across the algorithms.

I'll give it a deeper look on Monday.

[beomki-yeo]

This will be helpful if @krasznaa is going to consider the detector description for non-Si-based detectors
https://gitlab.cern.ch/atlas/athena/-/blob/main/InnerDetector/InDetCalibTools/TRT_CalibTools/src/Calibrator.h#L77

[krasznaa]

Over the weekend I looked at making the spacepoint formation use detray::detector instead of the placement() variable of traccc::silicon_detector_description. That part of the change is actually super easy, our algorithmic code uses placement() in exactly a single place at the moment.

But I had to realize that we have a gazillion tests that use TML data at the moment. We'll need to change all of those tests to use ODD data once we go for retiring TML compatibility completely. Which is definitely something that we need to do soon. But I decided to not do it in this PR after all.

I'd propose to keep traccc::silicon_detector_description::placement() in this PR, as is. Then I'll / we'll remove all TML support in a follow-up PR. We'll anyway need to check carefully how that will interact with the changes that @beomki-yeo has been working on recently. (Since he's also been working on removing TML support.)

Everyone, please give this another look. It would be great to push it through the finish line finally.

[beomki-yeo]

I approve this PR gladly although there are a couple of issues that need to be handled in the near furure (e.g. strip in spacepoint formation, copy of transform objects)