Return error state if PDG number is unknown #861
Conversation
| @@ -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); | |||
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
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!
|
This makes sense to me if there is no particle with pdg number of 0 🤔 |
As far as I can tell there isn't: https://pdg.lbl.gov/2007/reviews/montecarlorpp.pdf ACTS also uses 0 to represent invalid states: |
Currently, we assume that any unknwon PDG number is a muon, but this is obviously false. In order to remove this silent failure state, we should instead return some kind of invalid PDG particle. For this, we can use the same standard that ACTS uses, e.g. to use the number 0.
|
Currently, we assume that any unknown PDG number is a muon, but this is obviously false. In order to remove this silent failure state, we should instead return some kind of invalid PDG particle. For this, we can use the same standard that ACTS uses, e.g. to use the number 0.