Exit with an error if the first smoothed state is invalid #882
Conversation
| @@ -226,6 +239,16 @@ class kalman_fitter { | |||
| // return false; | |||
| } | |||
| auto& last = *fitter_state.m_fit_actor_state.m_it_rev; | |||
|
|
|||
| const scalar theta = last.smoothed().theta(); | |||
| if (theta <= 0.f || theta >= constant<traccc::scalar>::pi) { | |||
There was a problem hiding this comment.
To make it clear, this is where the fix was done.
There was a problem hiding this comment.
I absolutely like the direction that all of this is going in.
I was wondering for a moment whether we could make use of <system_error> in all of this, similar to what we do in Gaudi's StatusCode, but on a quick look std::error_code looks pretty GPU hostile. So simple enums are probably the best way to go about this. 🤔
I believe eventually we'll have a number of algorithm specific enums. And we'll need to think a bit more about the proper way of reporting back about these as well. But overall, I think this is a good direction to start in like this.
Just the unimportant question/suggestion from me, as shown below...
| @@ -0,0 +1,20 @@ | |||
| /** TRACCC library, part of the ACTS project (R&D line) | |||
| * | |||
| * (c) 2022-2024 CERN for the benefit of the ACTS project | |||
There was a problem hiding this comment.
This could be:
| * (c) 2022-2024 CERN for the benefit of the ACTS project | |
| * (c) 2025 CERN for the benefit of the ACTS project |
😉
|
|
||
| #include <cstdint> | ||
| namespace traccc { | ||
| enum class kalman_fitter_status : uint32_t { |
There was a problem hiding this comment.
I'm not in love with the name, but don't have fundamentally better suggestions for the moment. 🤔
But I wonder... Should we rather use std::uint32_t? I think the C++ standard only guarantees the existence of the std:: prefixed version.
https://en.cppreference.com/w/cpp/header/cstdint
But we certainly do this pretty inconsistently in the code elsewhere as well. 🤔
|
Mind you this contains a bunch of already merged changes, the PR needs to be rebased. |
That of course explains things. I'm just surprised that (as long as it can be cleanly rebased) GitHub doesn't do this automatically in showing the diffs. I think GitLab can do that. Though I'm not absolutely sure about that... |
|
Depends on #881.
This will solve the issue of seg fault issue in the benchmark by exiting with an error if the first smoothed state is invalid
Update: This does not solve the seg fault issue actually