Skip to content
This repository has been archived by the owner on Jun 5, 2024. It is now read-only.

Mismatch in event_number #394

Open
PavelKavrigin opened this issue Jul 18, 2022 · 6 comments
Open

Mismatch in event_number #394

PavelKavrigin opened this issue Jul 18, 2022 · 6 comments

Comments

@PavelKavrigin
Copy link
Contributor

As for now, event_number in truth (i.e. the numbers generated by epix) does not correspond to event_number in the event-level data generated by straxen, e.g. event_info. The latter one is generated here:

https://github.com/XENONnT/straxen/blob/f6e0966e3d78c7e663f7cd4caca2eff32b12643e/straxen/plugins/event_processing.py#L127

The result is very misleading since one might select certain events via event_info (testing cuts etc.) and then look for the origin of these events in the truth using event_number. The result will be incorrect.

Here's an example notebook which demonstrates this issue:
/dali/lgrandi/pkavrigin/2022-07-18_wfsim_test/2022-07-18_wfsim_test.ipynb

Possible solutions:

  • Remove event_number from truth. We can use g4id for event grouping, if needed. This way we can at least make sure that nobody tries to match truth to event-level output in a wrong way.
  • Propagate event_number from truth to event-level output. I do not see a way to do it without modifying straxen, so this is probably not a good idea.
  • Match events in event-level output to truth using time. It is feasible (and it is the only way to match them right now) but it's not clear if we can add it as some post-processing stage to wfsim.

@ramirezdiego @terliuk @petergaemers @shenyangshi - Any ideas?

@JoranAngevaare
Copy link
Contributor

JoranAngevaare commented Jul 18, 2022

@PavelKavrigin
Copy link
Contributor Author

Thanks! But I think we still need to remove event_number from truth to avoid confusion unless we add this matching using pema as a default option in wfsim.

@JoranAngevaare
Copy link
Contributor

Hi Pavel, yeah I see the point in that, it's super frustrating if two things look the same but mean something completely different. Perhaps just renaming the event_number -> sim_number is indeed a good idea. The g4id is not used for the default (non-epix) simulation.

@PavelKavrigin
Copy link
Contributor Author

I was trying to use truth_events from pema to do the matching, and it failed with this assertion:

assert np.all(res['endtime'] > res['time'])

I've checked the output, and we do indeed have interactions in truth where time equals endtime. Is this a bug or are they allowed to be equal?

@JoranAngevaare
Copy link
Contributor

I think this could be an issue in WFSim, probably we should make sure that endtime is in fact t_last_photon; or are there no photons in your instructions? Maybe related to #373.

@PavelKavrigin
Copy link
Contributor Author

In all of these suspicious events there are no electrons and no photons, but amp is non-zero.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants