-
Notifications
You must be signed in to change notification settings - Fork 29
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
Lookup-table-based light simulation #70
Lookup-table-based light simulation #70
Conversation
Upgrade/add segment time info
Upgrade/calc det response
Upgrade/add light triggers
Fix bugs light simulation
… are included in `examples/`). Added a conditional for this renaming/reinitialization
…) and `i4` (new)
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.
Looks good to me, apart from some minor comments. Am I right to assume there is no MC truth - light simulation association atm?
# We divide the sample in portions that can be processed by the GPU | ||
step = 1 | ||
|
||
# charge simulation | ||
event_id_list = [] |
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.
Can you clarify the logic here? I had moved these inside the for in order to save the output after each event, does it now happen every EVENT_BATCH_SIZE
events?
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.
That's right. It helps speed up the Module 0 simulation a bit, since each event isn't actually that big. That can be adjusted to optimize for different detectors (or made into a script parameter).
As a side note, I did a little bit of profiling and it now spends about equal time in the "simulation" piece as in the "export_to_hdf5" piece. So, there's a potential x2 speed-up that could be achieved by letting the export to hdf5 run in a separate process. Just something to think about - it would take a fair bit of work.
@@ -29,7 +29,7 @@ def drift(tracks): | |||
|
|||
track = tracks[itrk] | |||
|
|||
pixel_plane = -1 | |||
pixel_plane = detector.DEFAULT_PLANE_INDEX |
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.
Thank you for this, much better than -1
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.
Yes thanks Dan!
OK @soleti take a look now. I think I've addressed all your comments. The only truth information that is saved is the intensity data for each track segment, which does require some interpretation. But it's not obvious to me what other information we would want that isn't just the sample-by-sample truth info (which quickly becomes a ton of mostly irrelevant data). I figure we can start with what we have, and if later on we find out there is additional information that would be good to track, deal with it then. |
Lookup-table-based light simulation
Same as PR #69 except with a few revisions based on review comments.
Also cleaned up merge conflicts.