Update detray version to v0.73.0

[beomki-yeo]

As of detray v0.73.0, we need to handle the particle hypothesis appropriately.
Free covariance matrix is also removed as it turned out to be unnecessary.

It is not relevant with the detray version update, but the PR make the test for the track parameter estimation cover the positive charge as well.

[krasznaa]

No fundamental issues of course, just some technical questions.

Would we not need to teach traccc::options about the extension in traccc::finding_config? (And even the one in the simulation config I suppose.) We'd like to be able to set the new particle hypothesis value from the command line as well I guess. 🤔

[beomki-yeo]

Would we not need to teach traccc::options about the extension in traccc::finding_config? (And even the one in the simulation config I suppose.) We'd like to be able to set the new particle hypothesis value from the command line as well I guess

This is done now. As there was no function for casting particle type from double to float, I just used traccc::scalar everywhere but this can be fixed in the future

[beomki-yeo]

One issue appeared was that the particle hypothesis may have different charge with the reconstructed track. For example, the track fitting starts with muon hypothesis but there can be tracks with positive charge. In that case, the particle hypothesis is changed to its anti-matter.

[beomki-yeo]

Any approval?

[krasznaa]

Joana is right to worry about all the "if statements". 🤔 We'll have to see exactly what this does to the GPU code, but even when most of the threads will take one path, having any new branching point cannot be good for the code's performance. The question is only how bad it is. Not whether it's bad.

That being said, if we need to live with this, then we do. Still, any "trick" that allows us to perform an operation without an if or switch statement, is a good trick. 😉

[beomki-yeo]

I think @krasznaa is misunderstanding sth. The branching only happens inside the function. It is not like it will create entire new branching for the next stages.

[krasznaa]

I think @krasznaa is misunderstanding sth. The branching only happens inside the function. It is not like it will create entire new branching for the next stages.

?

It's happening inside of a function, which is called from the track finding kernel. This is the definition of branching in the GPU threads... 😕

Again, it may be unavoidable (though maybe not based on the discussion so far), but let's not kid ourselves that adding if(...) statements in device code would be for free...

[beomki-yeo]

I have never said that it is free. I just said it is going to be "tiny".
Welp that's why I added the benchmark monitoring. So don't worry too much

[niermann999]

I have never said that it is free. I just said it is going to be "tiny". Welp that's why I added the benchmark monitoring. So don't worry too much

Yeah, its probably benign. It just seemed avoidable

[krasznaa]

👍