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

Optimize chunks splitting based on number of corresponding photons #283

Open
dachengx opened this issue Dec 30, 2024 · 3 comments
Open

Optimize chunks splitting based on number of corresponding photons #283

dachengx opened this issue Dec 30, 2024 · 3 comments

Comments

@dachengx
Copy link
Contributor

dachengx commented Dec 30, 2024

If we still do not allow re-chunking of simulation results,

rechunk_on_save = False

a more optimized way is to set the number of tolerable quanta, especially electrons. Interaction with 1 electron and 1E6 electron takes the different sizes of chunks in higher data_type, e.g. propagated_s2_photons.

We have two ways to solve this:

  1. For ChunkCsvInput, deduce roughly the size of the tolerable quanta; for ChunkInput, deduce roughly the size of the tolerable energy deposition in higher data_type.
    chunk_idx = dynamic_chunking(
  2. Allow re-chunking in higher data_type.
@dachengx
Copy link
Contributor Author

Or we should build a new base class like OverlapWindowPlugin, not based on time(endtime) but cluster_id.

@HenningSE
Copy link
Collaborator

Hi @dachengx I like the idea of revisiting the chunking settings for fuse. Initially rechunk_on_save was set to False in order to prevent memory issues in the later plugins (S2 photon propagation and raw records simulation). Now that these plugins will create smaller chunks on the fly, we might actually be able to allow rechunk_on_save for all non-Down chunking plugins.

@dachengx
Copy link
Contributor Author

dachengx commented Jan 6, 2025

Hey @HenningSE . It will be a problem if the chunking makes photons from different cluster_id end up in different chunks. So we have to validate the potential change. That is not trivial. I will let you know once I have the PR ready.

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

No branches or pull requests

2 participants