Log and kill geometry/propagation errors #1290
Conversation
sethrj
added
enhancement
There was a problem hiding this comment.
Thanks @sethrj! I think this looks good overall. I'm not sure I would classify looping tracks as a "geometry/propagation error", except in the (hopefully rare) case a track that is actually stuck is marked as looping. I think it's really more of a tracking cut: there's nothing wrong with their behavior and we could continue transporting them to completion, but we choose to kill them because they make progress so slowly and the computational cost of transporting them would be too high. But anyway, nomenclature aside the logic for killing looping tracks or tracks with geometry errors should be the same.
| { | ||
| //---------------------------------------------------------------------------// | ||
| /*! | ||
| * Launch the boundary action on device. |
There was a problem hiding this comment.
| * Launch the boundary action on device. | |
| * Launch the geometry error action on device. |
|
|
||
| //---------------------------------------------------------------------------// | ||
| /*! | ||
| * Launch the boundary action on host. |
There was a problem hiding this comment.
| * Launch the boundary action on host. | |
| * Launch the geometry error action on host. |
| } | ||
| else | ||
| { | ||
| msg << "lost " << deposited << " energy"; |
There was a problem hiding this comment.
| msg << "lost " << deposited << " energy"; | |
| msg << "lost " << deposited << " " << Energy::unit_type::label() << " energy"; |
There was a problem hiding this comment.
Hmmm apparently I forgot to push!
| CELER_LOG_LOCAL(error) << "Track entered a volume without an " | ||
| "associated material"; |
There was a problem hiding this comment.
Under what circumstances might this occur?
There was a problem hiding this comment.
Our GeoMaterial input takes a map of volume name/material IDs and fills the rest with invalid IDs. Those IDs can be legitimate if the volume isn't reachable by the tracking routine (e.g., the [EXTERIOR] volume, or other "imaginary" volumes defined for convenience by vecgeom/g4). However if there's an error in the input or importing or something, you can end up with undefined materials...
There was a problem hiding this comment.
Thanks, makes sense. In what cases do you think we should be asserting/validating vs. logging an error and killing on the CPU/silently killing the track on the GPU?
| # define CELER_CHECK_POSITION 0 | ||
| # if CELERITAS_DEBUG | ||
| # undef CELER_CHECK_POSITION | ||
| # define CELER_CHECK_POSITION 0 |
There was a problem hiding this comment.
Should this be defined in this case?
| # define CELER_CHECK_POSITION 0 | |
| # define CELER_CHECK_POSITION 1 |
| */ | ||
| CELER_FUNCTION void SimTrackView::status(TrackStatus status) | ||
| { | ||
| CELER_EXPECT(status != this->status()); | ||
| CELER_EXPECT(status != this->status() || status == TrackStatus::killed); |
There was a problem hiding this comment.
When might we set the status to killed more than once?
There was a problem hiding this comment.
It happens if the track is killed during initialization; we can't leave it as "alive" if it has an undefined volume/material so I have to kill it there. This is kind of messy.
There was a problem hiding this comment.
Ok, so if it's killed during initialization and then killed again sometime later (I guess in either the interaction or eloss applier)?
|
This was a bit of a half-baked idea, you're perfectly right about the looping track not being the same as a geometry error. Maybe we should just make this a "tracking cut" action? Should we print log messages immediately when the error occurs? It also exposes some of the fragility in our implementation... there's still a test failure due to a hardcoded condition not being met... |
|
Yeah, a "tracking cut" or more generic kind of "track killer" action might make more sense, same with printing the whole error message immediately. |
|
OK I think I'm going to rework this: maybe a combination of
|
|
I'm going to close this in favor of a fresh PR. |
This replaces the "kill looping tracks" with an explicit kernel for killing tracks, and replaces a host-only "validate" for tracks being inside the geometry and having a valid material ID. It logs descriptions and error messages for each of these cases.
A follow-on PR will add internal error states to the geometry tracking so we can catch issues with the current ORANGE implementation.
See #687 .