[Event mixing] Update tutorials for new binning policy

[saganatt]

Hi @jgrosseo

I updated the tracksCombination tutorial to show the usage of the new Binning Policy interface.
There is an example how to use configurable binning - I would suggest everyone that uses selfCombinations (you + FemtoDream + PWGDQ) to update the codes. We can perhaps advertise this at a Monday meeting?

Also, would we like to provide more support for configurable bins, to allow for defining configurable Binning Policy also outside process()?

Updated event mixing examples commented out, as they will cause compilation errors until we merge mixing integration. I will submit this integration in the next PR after AliceO2Group/AliceO2#8362 will be merged.

[iarsene]

Hi Maja,
Will the old selfCombination version still be available? With the current implementation of selfCombinations we have in DQ at the moment, we can select the variables and binning for the event mixing via configurables. I am not sure i know how to use the BinningPolicy with the new selfCombinations to achieve the same. Do you have any suggestions?
Ionut

[saganatt]

Hi Ionut,

Configurable bins are supported - you can see in the last task in tracksCombinations.cxx in this PR.
My question was if we want to support also defining BinningPolicy with configurables outside the process().

Selection of the variables -- i.e., what you have now as "fMixingHash" in your codes? That would be indeed harder at runtime.
The idea was to get rid of the hash task and the "mixing hash", and supply directly the initial variables you want to be considered for mixing.

Maybe you could describe me more your use case?

[iarsene]

Hi Maja,
I may have misunderstood what you meant. I think that, in short, for the DQ analysis code, it is important that we still keep the selfCombinations function which makes use of the mixing hash. But i guess this should not be a problem i hope.

Now, in more details, the point in general is being able to select via configurables the variables and binning based on which we are doing event mixing. In DQ, we have a quite generic analysis task (PWGDQ/Tasks/tableReader.cxx) which is supposed to be used by most analyses, which means that depending on which analysis, collision system or data model, we will use a different set of event variables in the event mixing. So, the current implementation, is making use of the calculation of a hash, as in your older implementation, and in fact as also in our Run2 analysis framework, based on a configurable number of mixing variables and binning. Also, we do not use directly the table columns for mixing, but variables computed in the VarManager since we foresee that in mixing we will use also more complex variables, not only table columns.

So at least for now i would like to still be able to use the selfCombinations function based on the mixing hash.
I see the utility of the BinningPolicy that you prepared, but i still have to think how i can implement it in the framework we have in DQ at the moment.
Also, for us, the task that produces the hash is not actually too much of a headache, since we anyway have a task that subscribes to the event tables in order to make event selections. That task is both computing event decisions (and filling QA if needed) and the hash needed by the mixing. The hashing part is relatively small.
Cheers,
Ionut

[saganatt]

Hi Ionut,

I see your point So, each analyser writes his own hash task?

I forgot yesterday, but I have also a NoBinningPolicy just for such cases - when you want to use straight the value from a column - in your case, the column from the hash table. This will do exactly the same thing as passing the string to the selfCombinations. I suppose the hash column always has the same name, so hardcoding it should not be a problem?

I added an example of using the combinations with hashes to the tracksCombinations tutorial, and a more sophisticated example of mixing to the event mixing tutorial - please see the last two tasks in each file. You could use the mixing exactly in the same way in your tableReader. The mixing is commented now, as first the relevant code must be merged in O2.

Does it look right to you now? :-)

[jgrosseo]

@iarsene The idea of this work was to get rid of the hash task wherever we can and make it implicit. This reduces the code the user has to write and allows to have several event mixing tasks in the same train (e.g. through subwagons) or from different users. If one uses an explicit hash task (as in DQ) this produces an O2 table, and then only one of those can be added to a train and this is a severe limitation.

[iarsene]

@jgrosseo I understand, and i guess this is true for any table being produced by analysis tasks, not just the hash tables for mixing. But in the DQ case, in principle we just need one instance of the task to run in a train, so there should be no limitations.