graphnet-team
Treatment of hull entering tracks that are not found in the MCTree
Describe the bug
This bug happens when using the I3Calorimetry Extractor. This extractor counts all energies that are present within a hull around the detector with a specified padding value. The core functionality of this extractor is the get_energies function, which recursively calculates the energy left in this hull.
The problem is the treatment of tracks entering this detector hull from outside (e.g. throughgoing_tracks, etc.).
The following if clause determines the treatment of tracks:
https://github.com/graphnet-team/graphnet/blob/401f28b450e995cc567a70e83bb813757e9a4d63/src/graphnet/data/extractors/icecube/i3calorimetry.py#L220
The if statement checks if the event is a track and if it is in the track_lookup, which is a dictionary created by looping through the MMCTrackList and harvesting the tracks with MuonGun. See:
https://github.com/graphnet-team/graphnet/blob/401f28b450e995cc567a70e83bb813757e9a4d63/src/graphnet/data/extractors/icecube/i3calorimetry.py#L92-L114
If an event is a track that is not in the track_lookup, we only consider its daughters, here:
https://github.com/graphnet-team/graphnet/blob/401f28b450e995cc567a70e83bb813757e9a4d63/src/graphnet/data/extractors/icecube/i3calorimetry.py#L307-L323
This can happen, e.g. if a track is very far away from the detector. In this case, the track mostly does not cross the boundary of the hull, and it is fine to just look at the daughters.
The problem, however, arises when a track crosses the boundary of the hull but is NOT in the track_lookup. In this case, we cannot get the necessary information that we need--the energy of the track at the entry of the hull--to calculate the desired energy, because the track is not stored in the MMCTrackList or harvestable by MuonGun.
In this case, we should return Nans to mark that for this event, we cannot calculate the correct energy proxies. But currently, we just ignore this and continue on to the children of this track.
These "tracks" that cross the boundary and are not in the track_lookup are you certain that these are indeed light producing particles and not tagged with the Dark, which indicates that it does not produce any light. If this is the case then it would seem to me that this might have to be handled on the IceCube side of things.
Good point. I'm not sure how it is handled. I know that they only consider tracks in the MMCTrackList that are within a certain region of the detector, and thus, you cannot find all of the tracks in that list. You are probably right in that these tracks do not emit light. However, if we were to keep the current approach, then we would not be consistent with taking the track's energy at hull entry because we cannot calculate it.
I don't know if I agree that this should return NaNs. Isn't it just that the calculated energy is the energy deposited by visible particles inside the detector, and not the energy of all (including invisible) particles inside the detector, here assuming that the missing tracks inside the detector volume are in fact produced by non-light producing particles.