EDM De-Algebraification #1, main branch (2026.04.08.)

[krasznaa]

With this let me start yet another big rewrite / redesign. 🤔

It's been bugging me for a long time that the data model we use depends on the algebra that we use. Which in my mind is not a workable API. The data itself needs to be fixed somehow.

So I started by making traccc::edm::silicon_cell and traccc::edm::measurement not be dependent on the build setup of the project. As these seemed technically the easiest to do, and since edm::measurement is used pretty much everywhere, I thought that this would be a good stress-test for the rewrite.

Making edm::silicon_cell always use float values for its "activation" and "time" properties was a trivial change, that didn't actually necessitate any code changes. So that was surprisingly easy.

But of course edm::measurement was a bit more tricky. What we do currently is that we use the detray::point2D type for storing the local coordinates and the variances of those local coordinates. But I believe it's a lot better idea to just store plain std::array<float, 2> objects. Independent of what algebra we want to use for our calculations.

To help with this, I added a couple of additional functions to edm::measurement. Which would help with both retrieving and setting the local_position and local_variance variables using Detray objects directly. Just so that the actual algorithmic code would look a bit more "natural". Like:

    const point3 global = sf.local_to_global(
        gctx,
        meas.template local_position_in<typename detector_t::algebra_type>(),
        {});

(Okay, maybe "natural" is a bit over-selling it. 🤔)

I see this all as one step towards hiding the whole algebra business behind the scenes. As the API of the GPU tools should really not reveal what algebra is being used underneath. In case we end up using array and Eigen algebras interchangeably in the end after all. 🤔

I assume there will be plenty of discussion around this. Especially around what we'll do with edm::track_state afterwards. (As there I do have some worries about what we actually want to do.) But let's see how this goes...

[stephenswat]

Removing the algebra from the EDM is largely uncontroversial, so I'm on board with this. The only real issue with this PR is that it tasks the EDM with the responsibility of type conversions where that should really be the callers' responsibility.

[stephenswat]

Looks much nicer, thanks.

[stephenswat]

Is there a good reason why this cannot return the dpoint2D by value?

[krasznaa]

I'm trying to balance between writing code in the style of existing code, and writing it in a way that I would like. 🤔 But indeed, while the existing API makes sense for variable sized matrices, it's indeed not great for fixed sized vectors.

[sonarqubecloud]

Quality Gate passed

Issues
18 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
7.4% Duplication on New Code

See analysis details on SonarQube Cloud

[stephenswat]

Looks good, let's go with this. 👍