Tools: First implementation of general ML class

[AlexBigO]

Hi @fcatalan92@fgrosa !

Here is the first draft of the general ML class:

• basically a copy-paste of the HF class we currently have on the master branch
• comment on enum CutDirection and findBin method. The former is defined in the general ML header and redefined in SelectorCuts.h for PWGHF (where we use it to define configurable objects). The latter (defined in SelectorCuts.h originally) is now defined as a method of the general ML class. I tried implementing some general MlUtils.h (containing the definitions of this enum and findBin method; so that they would be defined only once) included in SelectorCuts.h and MlResponse.h but I got error at compilation times, complaining about multiple definitions of these objects so I went for the solution proposed in this PR
• As you can see, the HF sub-class (inheriting from the general one) is currently empty (apart from constructor and destructor). The PID method was removed because combined PID variables are now accessible via expression columns and a future PR will add some HF-dedicated attributes to fill the inputFeatures vector via JSON.

[fgrosa]

Hi @AlexBigO, thanks for starting this development!
Regarding the common utils: if you define the functions within a namespace you should get rid of the compilation errors. However, also your solution is good in my opinion.
Instead, for the HF derived class: I would put the common methods (e.g. that allows to convert the strings of features in indices and cache them) but for the array of possible features I would do it channel by channel (by adding other daughter classes). In this way each channel would have its own list of features and 1) we do not risk to use a feature for one channel which is only defined for another one (i.e. massKK is only meaningful for the Ds) and we avoid to have a very long list of features.

[vkucera]

Hi @AlexBigO , thanks for pushing the generalisation in the right direction.
Just a note on the findBin function.
I already moved it out into a separate header in #3115 which I want to merge tomorrow, because today we should merge #3046 which will cause conflicts in the former and I prefer to keep the two PRs in two different O2Physics tags for the testing possibility.
It would therefore be nice if you could adapt your PR to use the new header once #3115 is merged and move it outside PWGHF together with your development.

[AlexBigO]

Hi @AlexBigO, thanks for starting this development! Regarding the common utils: if you define the functions within a namespace you should get rid of the compilation errors. However, also your solution is good in my opinion. Instead, for the HF derived class: I would put the common methods (e.g. that allows to convert the strings of features in indices and cache them) but for the array of possible features I would do it channel by channel (by adding other daughter classes). In this way each channel would have its own list of features and 1) we do not risk to use a feature for one channel which is only defined for another one (i.e. massKK is only meaningful for the Ds) and we avoid to have a very long list of features.

Hi @fgrosa ! Thanks for the comment. I actually used a namespace but I couldn't make it work.
I fully agree on the HF side, namely define an array of available features for each decay channel and then define an array of strings in JSON that would contain some (or all) of these available features.

[AlexBigO]

Hi @AlexBigO , thanks for pushing the generalisation in the right direction. Just a note on the findBin function. I already moved it out into a separate header in #3115 which I want to merge tomorrow, because today we should merge #3046 which will cause conflicts in the former and I prefer to keep the two PRs in two different O2Physics tags for the testing possibility. It would therefore be nice if you could adapt your PR to use the new header once #3115 is merged and move it outside PWGHF together with your development.

Hi @vkucera ! Thanks for the heads-up, but it should not cause conflicts with this PR as we defined a new findBin as a method of MlResponse class that is only called in isSelectedMl method.

[fcatalan92]

Thanks @AlexBigO, it looks good to me!

@ddobrigk Can we merge this? The plan is to use it in the ML tutorial.

[alibuild]

Error while checking build/O2Physics/o2 for 0d8dfbc at 2023-10-13 21:04:

No log files found

Full log here.