Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return error state if PDG number is unknown #861

Merged
merged 1 commit into from
Feb 14, 2025
Merged

Return error state if PDG number is unknown #861

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions core/include/traccc/utils/particle.hpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,8 @@ particle_from_pdg_number(const int pdg_num) {
return detray::pion_minus<scalar_t>();
}

return detray::muon<scalar_t>();
// TODO: Replace with `detray::invalid` in the future
return detray::pdg_particle<scalar_t>(0, 0.f, 0.f);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we expect to reach this "legitimately"? I wonder if we should "error out" more aggressively.

Since this code may be used in both host and device code (Though I doubt that device code actually calls this. Does it?), throwing an exception is not on the table. But maybe something else?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code is e.g. reached when we read Geant4 particle files which contain all kinds of horrendous PDG numbers (e.g. 1000701630). Currently our code assumes that such particles are muons by default, which leads to all kinds of hard-to-debug crashes when the sign of $q$ and the sign of $\frac{q}{p}$ differ.

I agree that it would be nice to have a more explicit system of errors, but indeed exceptions are a no-go, so I can't think of a better way than returning an explicitly invalid particle. Remember that the current code doesn't indicate any error at all and just keeps running silently!

}

// Apply the charge operator to return the antimatter
Expand All @@ -66,7 +67,8 @@ TRACCC_HOST_DEVICE inline detray::pdg_particle<scalar_t> charge_conjugation(
return detray::pion_plus<scalar_t>();
}

return detray::muon<scalar_t>();
// TODO: Replace with `detray::invalid` in the future
return detray::pdg_particle<scalar_t>(0, 0.f, 0.f);
}

// Return the consistent particle type based on the particle hypothesis and the
Expand Down
Loading