Add a StereoDispCombiner

[Hckjs]

This is basically the StereoCombiner already implemented here
in magic-cta-pipe.

It combines the mono DISP reconstruction by

1. calculating combinations of 2 telescopes for every array event
2. calculating the minimum distance for the 4 possible SIGN pairs for each combination
3. calculating the weighted average for the minimum distance SIGN pair (fov lon/lat) per combination
4. calculating the weighted average of all combinations for an array event with the summed weights from 3).

Update:
The StereoDispCombiner has essentially been generalized so that it can be configured to reproduce both the magic-cta-pipe and the EventDisplay behavior.

• The number N of telescope combinations was introduced as a traitlet.
• In addition, it is now possible to choose how many of the best telescopes, ranked by their weights, should participate in the averaging.
• Furthermore, a check analogous to the one in EventDisplay was introduced to reject subarray events with two participating telescopes whose shower axes are nearly parallel.

For each telescope combination of size n_tel_combinations, all possible DISP sign assignments are then evaluated, and the sign combination that minimizes the Sum of Squared Errors (SSE) between the participating telescopes is selected. The resulting per-combination FoV positions are then combined using the selected telescope weights, and a weighted mean FoV direction is computed for each subarray event.

If a subarray event has an valid telescope multiplicity smaller than n_tel_combinations (after applying n_best_tels and any angular-difference cuts), but at least two telescopes remain, the reconstruction is performed using all available telescopes of that subarray event. In this case, only one combination is formed, with a size equal to the event multiplicity, and the optimal DISP sign assignment is determined accordingly. Single-telescope events are handled separately using just the mono reconstruction.

Some hints for reviewing are here

[kosack]

We have a predicted disp.sign_score that is not used in this method, which seems odd. Is that the reason why the pair-wise average including both disps is made rather than a simple weighted average over predictions? Is there citation for the MARS method, by the way? i'd be interested to see if simpler methods were tested.

[LukasBeiske]

We have a predicted disp.sign_score that is not used in this method, which seems odd. Is that the reason why the pair-wise average including both disps is made rather than a simple weighted average over predictions? Is there citation for the MARS method, by the way? i'd be interested to see if simpler methods were tested.

This sign_score is mostly meant for performance plots (sign_score = np.abs(2 * sign_proba - 1.0) where sign_proba is the output of the sign classifier).
The weighted average over telescope-wise (alt, az) predictions is what the StereoMeanCombiner does for the disp reconstruction, but this method here seemed to perform better in a master thesis in Dortmund some years ago. We can add some performance plots here once the remaining issues are figured out.

[maxnoe]

The weighted average over telescope-wise (alt, az) predictions is what the StereoMeanCombiner does for the disp reconstruction, but this method was proven to perform better in a master thesis in Dortmund some years ago.

It's also easy to argue why: especially at low energies, disp sign is not really reconstructible (random guess, sign_score ~ 0.5). But with multiple telescopes, it's quite easy to see which option is actually correct and make the weighted average over the correct locations.

There are still a couple of different options for stereo disp, but most of them do not actually use the sign prediction, that is only used for mono as far as I know.

The MAGIC MARS method is explained in a short paragraph here:

Foreach of them, the disp identifies two possible reconstructed
source positions (head-tail ambiguity). At this stage for
each stereoscopic event, melibea evaluates all four possible
combinations of position pairs, and chooses the closest pair,
but only if its distance is smaller than a certain value. If none
of the pairs satisfies this condition, the event is rejected. The
stereo-reconstructed position is determined as the weighted
average of the chosen pair of positions.

https://cbpf.br/icrc2013/papers/icrc2013-0773.pdf

[maxnoe]

We have a predicted disp.sign_score that is not used in this method, which seems odd.

Not really, this is more of a book-keeping for doing lower-level performance plots. It could be used for a quality query or similar, but AFAIK, this was not yet done anywhere and would be a completely new development that needs to be tested. Would be a nice study though.

[Hckjs]

We have a predicted disp.sign_score that is not used in this method, which seems odd.

Not really, this is more of a book-keeping for doing lower-level performance plots. It could be used for a quality query or similar, but AFAIK, this was not yet done anywhere and would be a completely new development that needs to be tested. Would be a nice study though.

During the quantitative analysis of the StereoDispCombiner in its current form, i noticed that particularly high-energy events with a high scatter radius have an almost parallel reconstructed shower axis (often events with only 2 valid telescopes). This worsens performance compared to the StereoMeanCombiner at high energies because it isnt just averaging but choosing the complete wrong side. However, since this occurs mostly at high energies, the sign scores are also significantly higher, which I tested as a weighting factor in the selection of the minimum distance and was able to achieve significantly better performance for high-energy events. So far, I have only tested this on small data sets, but I will upload a few comparison plots soon.

[Hckjs]

combiner_theta2_reco_lon_lat_zen_20_az_0_ac_full_array.pdf
combiner_irfs_sens_zen_20_az_0_ac_full_array.pdf

The StereoDispCombinerSS is using the mentioned sign_score weightings on the minimum distance calculation. The effect doesnt seem to be as high as expected in the beginning...
I've also tried a KMeans and a DBScan approach having a quite similar performance compared to the DispCombiner. However they are slower because of a way less efficient table-wise processing.

[ctao-sonarqube]

Quality Gate failed

Failed conditions
1 New issue
3.5% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[maxnoe]

I'm not quite sure I understand the logic of weighting distances, which should be related to the absolute value of disp, with the sign score. Especially since we are trying out all combinations, effectively ignoring the predicted sign.

[maxnoe]

Sorry for the above message, I forgot about the comment of near-parallel high energy showers. So penalizing choosing what the classifier thinks is a clearly wrong sign is good I think.

I'm not sure though that weighting the distance achieves this goal.

For your comparison plots, it might help to include large percentiles to see differences. It expect this to mostly affect rare events, so the effect is probably only seen in something like a 90 % or 95 % containment, not 68 %.

[maxnoe]

Could you also maybe expand a bit what datasets you are using here and how they have been processed?
Maybe also add the HillasReconstructor to the comparison?

[ctao-sonarqube]

Quality Gate passed

Issues
0 New issues
1 Fixed issue
0 Accepted issues

Measures
0 Security Hotspots
88.6% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube