-
Notifications
You must be signed in to change notification settings - Fork 35
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.
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
Save action times on multi-stream CPU celer-sim #1065
Conversation
I can't reproduce the celer-sim crash locally :( |
@amandalund Do you have any idea why this could be segfaulting now? I'm at a loss. |
I'll see if I can reproduce it. |
Also failed to reproduce on wildstyle/openmp/cuda for debug, release, and reldeb :( |
No luck either so far... |
Ok, I was able to reproduce it with debug assertions on. In the new transporter accessor in the status: Creating states
status: Celeritas core state initialization complete
status: Warming up
status: Transporting 5 primaries
status: Creating states
status: Creating states
status: Celeritas core state initialization complete
status: Celeritas core state initialization complete
status: Transporting 5 primaries
status: Transporting 5 primaries
/home/alund/celeritas_project/celeritas/app/celer-sim/Transporter.cc:119: error: Exceeded step count of 256: aborting transport loop
/home/alund/celeritas_project/celeritas/app/celer-sim/Transporter.cc:119: error: Exceeded step count of 256: aborting transport loop
/home/alund/celeritas_project/celeritas/app/celer-sim/Transporter.cc:119: error: Exceeded step count of 256: aborting transport loop
/home/alund/celeritas_project/celeritas/app/celer-sim/celer-sim.cc:268: critical: While running input at <stdin>: /home/alund/celeritas_project/celeritas/app/celer-sim/Runner.cc:543:
celeritas: postcondition failed: result
status: Saving output
Failure written to simple-cms-cpu.out.failed.json
fatal: run failed with error 1 |
Are there more threads than events in this test? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @sethrj!
When we switched the regression problems to
"merge_events": false
on CPU, we lost the action-granularity timing results. This restores them. To be consistent with current output, the timing is averaged over the streams.