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.

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

Merged
merged 66 commits into from
Apr 20, 2022
Merged

Lookup-table-based light simulation #70

merged 66 commits into from
Apr 20, 2022

Conversation

peter-madigan
Copy link
Member

Same as PR #69 except with a few revisions based on review comments.

Also cleaned up merge conflicts.

Copy link
Collaborator

@soleti soleti left a 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?

cli/dumpTree.py Outdated Show resolved Hide resolved
cli/dumpTree.py Outdated Show resolved Hide resolved
# We divide the sample in portions that can be processed by the GPU
step = 1

# charge simulation
event_id_list = []
Copy link
Collaborator

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?

Copy link
Member Author

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.

cli/simulate_pixels.py Show resolved Hide resolved
larndsim/consts/light.py Show resolved Hide resolved
@@ -29,7 +29,7 @@ def drift(tracks):

track = tracks[itrk]

pixel_plane = -1
pixel_plane = detector.DEFAULT_PLANE_INDEX
Copy link
Collaborator

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

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes thanks Dan!

@peter-madigan
Copy link
Member Author

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.

@soleti soleti merged commit c071148 into DUNE:master Apr 20, 2022
soleti added a commit that referenced this pull request Apr 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants