Fix calorimetry

[sevmag]

This PR is addressing issue #816.

The modifications consist of:

• Adding the option to not only take the highest energy primary but also other primaries (uses new functionality of the get_primaries function introduced through Fixing the get_primaries function of I3Extractor #818 )

Updates in the call function:

• Instead of looking at the Tree twice, once for cascades and once for tracks, we recursively go through the tree and add energies of the particles to the corresponding variable (see function get_energies). This assures that nothing is counted twice.
• Do the assertion that e_total is smaller than the primary energies always, not only if daughters is True. e_total should never exceed the summed primary particles.
• Handle cases where the primaries list is empty (insert nan)
• Corrected the if statement for the Dark Cascades

EDIT:

New Feature

• added an argument cascade_deposited_only which allows to count the true energies of cascades, not only the visible ones

[Aske-Rosted]

Is this correct? If the track has daughters, then my understanding is that these would be generated at the end of the track (I don't think there is any particle generation without "ending" the current particle). We would then have to check the energy at the end of the track and then also consider the daughters of the track. Also if you aren't specifically removing the daughters of the track aren't these going to show up either in other tracks or in the cascade particles?

[sevmag]

The problem lies with the e_ent_track variable, which represents the energy of a track at its first intersection with the surface. Therefore, this energy already encompasses all the energies of its potential daughters. If one were to continue to loop through the daughters of this track, one would again count energies that are already captured in e_ent_track. I agree that this is not the most sensible handling of this case. Especially in events like a double bang, one would essentially count the energy of the second cascade towards the track.

[sevmag]

However, it does not take into account daughters of tracks, since the recursion is stopped once there is a track.

Note that in the case a track is registered, the function does not call the next recursion like it's done in other cases, e.g. the call here:

graphnet/src/graphnet/data/extractors/icecube/i3calorimetry.py

Lines 253 to 266 in 93d7f45

	(
	e_dep_cascade,
	e_dep_track,
	e_ent_track,
	) = tuple(
	np.add(
	(e_dep_cascade, e_dep_track, e_ent_track),
	self.get_energies(
	frame,
	daughters,
	track_lookup,
	),
	)
	)

[Aske-Rosted]

Is it possible that we should just drop the e_ent_track, which is essentially the energy of all tracks as they enter the detector volume, I don't currently use it at and just created it since a similar feature exists in I3HighestEparticleExtractor The actual value of this quantity might be of limited use and also does not fit great with it being a calorimetric approach.

[sevmag]

But it is used to calculate the e_total, which is arguably the most important quantity in this extractor.

[sevmag]

graphnet/src/graphnet/data/extractors/icecube/i3calorimetry.py

Line 118 in 93d7f45

e_total = e_ent_track + e_dep_cascade

[sevmag]

We could switch out e_ent_track with e_dep_track

[Aske-Rosted]

Yeah, this target task is of course easier than the previous one, but it is more aligned with the calorimetric approach. Otherwise we would have to think a bit more about how to calculate this e_ent_track in a meaningful way.

[sevmag]

Yeah, I agree with you. It is a more calorimetric way if we only consider the deposited energy. I did some checks on the e_visible calculated with the current status of this PR from the calorimetry extractor, and it seemed to be a nice label to train on. I am looking more into the HEP now to see if it is a good substitute for this. If yes, I'm happy to get rid of e_ent_track in the calorimetry extractor.

[sevmag]

I have thought about it a bit more, and there is an extra amount of work that is implied when also looking at the daughters of tracks. The problem is that the daughters of tracks frequently are track segments, which are not physical particles, which implies that double-counting energies again can happen quite easily. Frankly, I do not have the time to look into this more. I think this PR already fixes the Bugs mentioned in issue #816, and I would leave it at that for the moment. We could mention this PR in the class description to make the user aware of the limitations that exist for now. Do you agree with this @Aske-Rosted?

[Aske-Rosted]

I am also interested in knowing whether these changes significantly impact the running time or if it is roughly the same, did you do any testing of this?

[sevmag]

I am also interested in knowing whether these changes significantly impact the running time or if it is roughly the same, did you do any testing of this?

I have not made any tests for this yet

[Aske-Rosted]

This looks good to me now, however one of the tests seems to be failing after your latest push.

[sevmag]

That was just a connection error to the ERDA-hosted services. It should be all good now.

[Aske-Rosted]

Good to go