Sub events

[christophwelling]

Here is the implementation for the event group IDs so far. The event_group_id is a new property stored in the event class. To make it backward compatible, if no event_group_id is given, it is just set to the same as the event ID. To make sure all event IDs are unique, I created a utility class called eventIdProvider. It is a singleton, so only a single instance is used at a time. Every event that can introduce new event IDs into the program, like creating an event object or reading in files, informs the eventIdProvider about which IDs are already in use. When we need an ID for a new event, we can ask the eventIdProvider to give us one and it will make sure that we get an ID that is not in use.

This is not nearly finished, but I wanted to make this draft PR so we can discuss if this seems like a good way to do it.

[christophwelling]

I tested if this actually works if we create event IDs in different modules, and it looks good:

In [1]: import NuRadioReco.modules.io.NuRadioRecoio In [2]: io = NuRadioReco.modules.io.NuRadioRecoio.NuRadioRecoio(['MC_example_station_32.nur']) In [3]: import NuRadioReco.framework.event In [4]: event = NuRadioReco.framework.event.Event(0,99,0) In [5]: import NuRadioReco.utilities.event_id In [6]: id_provider = NuRadioReco.utilities.event_id.eventIdProvider() In [7]: id_provider.get_event_ids_in_use() Out[7]: [[0, 0], [0, 1], [0, 2], [0, 3], [0, 4], [0, 5], [0, 99]]

So the first 6 event IDs are from the file that we read in and the ID 99 is from the event that we created. So it looks like it's doing what we want it to do.

[cg-laser]

cool this seems to work!

Then we could implement the detector in the same way?

[christophwelling]

In principle yes. I'm just not sure how to handle the case when we have the detector in the event file. If we read in multiple event files, we will also need multiple detector objects.

[cg-laser]

@christophwelling can you explain your most recent commit? I don't get what you're trying to do.

[christophwelling]

The problem I was trying to solve is that if I skip to another event inside a loop over iter_events, NuRadioRecoio will lose track of where it was and crash. When you iterate over the events, NuRadioRecoio will always continue to read the next event from wherever it stopped reading the last time. That is a problem if you tried to access an associated event in the mean time, because NuRadioRecoio has no way to remember where it was before and just continue from where it stopped looking for the associated events (usually at the file end). This change makes the iterator keep track of where it is supposed to be.

[cg-laser]

The problem I was trying to solve is that if I skip to another event inside a loop over iter_events, NuRadioRecoio will lose track of where it was and crash. When you iterate over the events, NuRadioRecoio will always continue to read the next event from wherever it stopped reading the last time. That is a problem if you tried to access an associated event in the mean time, because NuRadioRecoio has no way to remember where it was before and just continue from where it stopped looking for the associated events (usually at the file end). This change makes the iterator keep track of where it is supposed to be.

Thanks! This makes sense. Could you document the source code with this information?

[anelles]

Concerning the status @christophwelling ? Is this up-to-date with all the changes in NuRadioMC? I believe we talked much more about subevents in that part of the code.