add summary feature nodedefinition

[sevmag]

Adding a new NodeDefiniton called DOMSummaryFeatures which is a per DOM summary statistics NodeDefiniton used by different architectures in IceCube. This exact version is taken from Theo Glauchs thesis (https://mediatum.ub.tum.de/node?id=1584755). The reason for this PR is because I heard of other people also using/interested in these type of features.

Features of the DOMSummaryFeatures

- total charge
- charge accumulated after times `charge_after_t`
- time of first hit per DOM
- time spread per DOM
- time std per DOM
- time took to collect the charge percentiles `time_after_charge_pct`
- number of pulses per DOM

Here is a visual representation of the feature (more details are in Theos thesis above)

And the numerical ranges of these features:

NOTE: I had to change the clustering utility implemented by @Aske-Rosted in #770 (Therefore the review request) .

• I added functionality for sorting the clustered table by an additional feature
• changed some of the functions (NOTE: this functions are not being used in default GN atm if I'm not mistaken)
  • add_charge_threshold_summary (changed it so it does not alter the _padded_x attribute anymore)
  • _calculate_charge_sum (change to deal with nans)
  • added the necessary functions for my features

I also did timing tests:

And some ratios:

Here the NodeDefinitons:

input_feature_names = ['dom_x', 'dom_y', 'dom_z', 'dom_time', 'charge']
nodes = {
    'nodes_as_pulses': NodesAsPulses(
        input_feature_names=input_feature_names,
    ),
    'prct_clust_5pcts' : PercentileClusters(
        input_feature_names=input_feature_names,
        cluster_on = ['dom_x', 'dom_y', 'dom_z'],
        percentiles=np.linspace(0.2, 1.0, 5),
    ),
    'prct_clust_10pcts' : PercentileClusters(
        input_feature_names=input_feature_names,
        cluster_on = ['dom_x', 'dom_y', 'dom_z'],
        percentiles=np.linspace(0.1, 1.0, 10),
    ),
    'prct_clust_20pcts' : PercentileClusters(
        input_feature_names=input_feature_names,
        cluster_on = ['dom_x', 'dom_y', 'dom_z'],
        percentiles=np.linspace(0.05, 1.0, 20),
    ),
    'ice_mix_max512': IceMixNodes(
        input_feature_names=input_feature_names,
        max_pulses=512,
        add_ice_properties=False,
        sample_pulses=True,
    ),
    'ice_mix_max1024': IceMixNodes(
        input_feature_names=input_feature_names,
        max_pulses=1024,
        add_ice_properties=False,
        sample_pulses=True,
    ),
    'ice_mix_max2048': IceMixNodes(
        input_feature_names=input_feature_names,
        max_pulses=2048,
        add_ice_properties=False,
        sample_pulses=True,
    ),
    'dom_summary': DOMSummaryFeatures(
        input_feature_names=input_feature_names,
        cluster_on = ['dom_x', 'dom_y', 'dom_z'],
        
    ),
}

[RasmusOrsoe]

Reference to wrong class in docstring

[RasmusOrsoe]

Typo - indices

[RasmusOrsoe]

As you point out in the docstring, the method may aggregate information across any defined cluster. To avoid confusion, I think the name of the class should reflect this. It could for example be ClusterSummaryTheo :-)

[RasmusOrsoe]

Not just for DOMs!

[sevmag]

@Aske-Rosted and I talked about some functionality and wanted to change a few small things.

• Before ClusterSummaryFeatures enforced the sorting of the data per cluster by time. @Aske-Rosted requested to make this optional since sometimes the data is already sorted in the database, which then would create an unnecessary overhead when sorting again (New class init argument and got rid of assert in the cluster_and_pad class) I did not make any timing checks for that.
• Possibility for logarithmic standardisation of the charge features (added functionality to handle both logarithmic and scalar multiplication standardisation)

See new feature ranges:

[Aske-Rosted]

Two very minor things that you might consider, but otherwise good to go. Looking forward to using it on my end.

[Aske-Rosted]

Should probably say of the node.

[sevmag]

Maybe I do not understand what you mean by node, but I do not agree. The reference time is a weighted median of all pulses in the event, not just those at a single cluster/node. It is important to have a per-event reference point to have the relative time information between the clusters. Am I missing something?

[Aske-Rosted]

Could be made to a class feature since it is used in several of the class functions.

[Aske-Rosted]

Two very minor things that you might consider, but otherwise good to go. Looking forward to using it on my end.