You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
which returns tuples of tracks (one track from each table of tracks).
19
19
20
-
There are several *CombinationIndexPolicies* available which are explained [here](../framework/framework.md#getting-combinations-pairs-triplets-). It is recommended that you will get first well acquainted with combinations before moving on to mixing.
20
+
There are several *CombinationIndexPolicies* available which are explained [here](../basics-tasks/CombiningData.md). It is recommended that you will get first well acquainted with combinations before moving on to mixing.
21
21
22
-
## Event mixing
22
+
## Mixing generator
23
23
24
24
`GroupedCombinationsGenerator` which generates mixed event pairs is a generalization of block combination policies. Therefore, it accepts the same parameters:
25
25
26
26
- binning policy
27
27
- outsider
28
28
- category neighbours (equivalent to the number of other collisions to mix with)
29
29
30
-
You can consult a detailed description of these parameters in the [block combinations section](../framework/framework.md#block--binned-combination-policies).
30
+
You can consult a detailed description of these parameters in the [block combinations section](../basics-tasks/CombiningData.md#block--binned-combination-policies).
31
31
32
32
The `GroupedCombinationsGenerator` general constructor is defined as:
This is a more general functionality which potentially could be used for other applications beyond event mixing. However, to simplify this tutorial, let's assume our `grouping` table is the table of collisions, and the `associated` are tables of structures like tracks and V0s.
@@ -43,7 +43,8 @@ This is a more general functionality which potentially could be used for other a
43
43
-`T1`: type of an outsider value as well as the value itself as a parameter,
44
44
-`GroupingPolicy`: type of a *BlockCombinationIndexPolicies* which specifies how collision pairs will be generated (strictly upper, upper or full block combinations)i,
45
45
-`BP`: type of a binning policy applied to the block combinations of collisions as well as the policy instance,
46
-
- input grouping (collisions) and associated (tracks, V0s) tables and their types.
46
+
- input grouping (collisions) and associated (tracks, V0s) tables and their types
47
+
- a pointer to the `SliceCache` which is used implicitly for efficient slicing of associated tables
47
48
48
49
To simplify the code, there are helper shortcuts defined for the most common use cases:
SameKindPair<aod::Collisions, aod::Tracks, BinningType> pair{binningOnPositions, 5, -1}; // indicates that 5 events should be mixed and under/overflow (-1) to be ignored
36
+
SameKindPair<aod::Collisions, aod::Tracks, BinningType> pair{binningOnPositions, 5, -1, &cache}; // indicates that 5 events should be mixed and under/overflow (-1) to be ignored
36
37
```
37
38
38
39
In this case, only table types and the binning police type need to be passed, as the rest is taken from the defaults.
This is the same task as above, with the difference that binning policy and `SameKindPair` are declared inside `process()`. This is particularly helpful when your bins are ConfigurableAxes. The standard out-of-process declaration of binning policy and corresponding mixing structure would take only default configurable values.
59
60
60
-
### Task with different table structures
61
+
##Tasks with different table structures
61
62
62
63
These tasks demonstrate how mixing works with Filtered and Join.
63
64
64
-
###MixedEventsDynamicColumns
65
+
## MixedEventsDynamicColumns
65
66
66
67
This is a more realistic example with mixing of collisions binned by z-vertex and multiplicity V0M. As `MultFV0M` is a dynamic column, its type is templated on the contributing column types. Therefore, the binning policy type is:
67
68
@@ -71,15 +72,15 @@ using BinningType = BinningPolicy<aod::collision::PosZ, aod::mult::MultFV0M<aod:
71
72
72
73
The rest of the task is the same as in the basic example.
73
74
74
-
###Tasks with different table kinds
75
+
## Tasks with different table kinds
75
76
76
77
These tasks demonstrate usage of `Pair`, `Triple` and `SameKindTriple` on tracks and V0s.
77
78
78
-
###MixedEventsWithHashTask
79
+
## MixedEventsWithHashTask
79
80
80
81
This task shows how one can use `NoBinningPolicy` in case of bins predefined somewhere else.
81
82
82
-
###MixedEventsPartitionedTracks
83
+
## MixedEventsPartitionedTracks
83
84
84
85
This is a bit more advanced example which shows how one can further partition the tracks from mixing. As the tracks tables are produced only at the generation of each mixed collision pair, `Partitions` must be declared inside the mixing loop. Additionally, each partition must be bound to a respective table -- `tracks1` or `tracks2`. Then, the corresponding partitioning condition is applied to the selected table.
The task demonstrates how to use FlexibleBinningPolicy if binning cannot be calculated straight from the collision columns, but is obtained from other variables in a user-defined function.<br>
103
+
This is naturally implemented for mixing inside `process()`, as the helper lambda function is usually defined inside `process()`. For example:
auto associatedTracks = tracks.sliceByCached(o2::aod::track::collisionId, col.globalIndex(), this->cache); // it's cached, so slicing/grouping happens only once
110
+
return associatedTracks.size();
111
+
};
112
+
```
113
+
114
+
The binning policy:
115
+
116
+
```cpp
117
+
using BinningType = FlexibleBinningPolicy<std::tuple<decltype(getTracksSize)>, aod::collision::PosZ, decltype(getTracksSize)>;
A tuple with types of all lambda functions must be first passed in the `BinningType` definition, before the rest of arguments follow in the order of usage.<br>
122
+
Similarly, in `binningWithLambda` definition, one must first pass a tuple with all lambda functions before other arguments.<br>
123
+
Note that binning with respect to z-vertex is calculated from column values as before, while the lambda is used only for the multiplicity axis. You must be careful to follow the same order of columns/lambdas in the `BinningType` definition and of the corresponding axes in binning instantation.
124
+
Any combination of lambda- and column-based binning is possible.
125
+
126
+
Finally, the mixing structure is defined like in previous examples:
0 commit comments