Adding option for tuning dE/dx on data for MC particles

[ChSonnabend]

This PR intends to bring the possibility to enable a flag which runs a separate process function in which a table is filled with dE/dx values sampled randomly from the Bethe-Bloch or Bethe-Bloch + Neural Network corrections. This should be usable similarly to the tune-on-data version from AliPhysics.

[ChSonnabend]

Pinging @jezwilkinson

[jezwilkinson]

Hi @njacazio (also pinging @wiechula in case he wants to take a look), this commit is now ready for review
This PR adds the functionality for TuneOnData for the TPC signal in MC, similar to what was used in Run 2:

• calculates the expected signal/sigma for the track based on MC truth
• samples the dE/dx as a random value distributed by Gaussian with that mean and sigma
• uses the new sampled dE/dx in the nsigma calculations for that track for all species instead of the simulated TPC signal
• In addition, a table is added, mcTPCTuneOnData, containing a mcTunedTPCSignal() column in case an MC analysis needs to directly access the sampled signal (e.g. if a specific dE/dx cut is used somewhere instead of just nsigma)
  This is added for both pid-tpc and pid-tpc-full. Have tested the "processStandard" loop comparing against the current tag as well, and the outputs are identical between this commit and the latest tag for both tasks and both with/without NN application as expected.

[njacazio]

Hi @jezwilkinson all, very good! This is extremely nice, outstanding work!
I quickly had a look but will see it in detail in a while if it's ok with you.

[wiechula]

Thanks a lot @jezwilkinson , I'm not an expert of the analysis framework, so I cannot really give deep comments. A few things I noticed:

• You could consider making variable that don't change const
• There seems to be quite a lot of copy-n-paste code in pidTPC.cxx and pidTPCFull.cxx is it possible to avoid this?
• I might be good to add something about the mc tuned signal to the pid qa, or switch to using the tuned signal in the plots in case it is requested

[wiechula]

Shouldn't this check logically be the first?

[njacazio]

Hi all! I like it very much. I'm wondering if in the interest of sanity one should just remove the full and tiny tasks and merge them together and produce only the needed tables. For TOF it would be helpful for sure and I'm wondering if it would make sense here as well, e.g. the dedx table will not be able to be produced if both tiny and full tables are produced.
For the tune on data, did you consider generating directly the nsigmas? It could be easier I guess from the bethe bloch parameters without needing the dedx rewritten.

[njacazio]

One should be careful that the generator does not repeat itself

[jezwilkinson]

added a "gRandom->SetSeed(0)" into the top of the process function, this will reset the seed according to UUID whenever process() is called

[njacazio]

Could this go in the PID.h or so?

[jezwilkinson]

Moved the function from both to pidTPCBase.h

[njacazio]

I would do the opposite, if enabled turn on the process function as well.

[jezwilkinson]

If I'm understanding you right - is it possible to do that? I didn't think the process switches let you change the workflow topology during the init() based on table requirements like that (we would also need to disable the "standard" one in this case) but maybe there's some trick with process switches I didn't know about

[njacazio]

yes, you can tune the process functions based on the needs. That saves quite some overhead.
Something like doprocessMcTuneOnData.value = true; or so, it's very convenient.

[jezwilkinson]

Hi @njacazio:

• For the tiny vs. full - This sounds reasonable, it for sure would cut down on the amount of code duplication and simplify the wagon setup. I guess it could be done so that all of the tables are produced as requested in the workflow, it'd reduce the overhead on the NN too in case (for some reason) both the tiny and full tasks are in the same workflow. Though on that point I would suggest that we do a unified pass on the TPC+TOF tasks all together at some point and keep that change separate from this, what do you think?
• as far as sampling the dE/dx vs directly sampling the nsigma is concerned: While it would be simpler to directly sample e.g. the nsigma(pi) for an MC pion, we also need to provide the nsigma(proton,electron,etc) for that same pion according to the same tuned TPC signal. Calculating the dE/dx based on MC truth as a first step and basing all the nsigmas on that seems to me the simplest way by far (plus: in case a later task uses TPCSignal() directly for whatever reason, they will need to be able to access the tuned dE/dx to get the efficiencies consistent so we anyway need to provide it somehow.)

[njacazio]

Hi @jezwilkinson
on the first point.
I mentioned because it's really a struggle to maintain two codes ensuring the same values are given. Also when accessing the CCDB and so on, the objects in memory are duplicated. CPU wise it also makes sense if the values are computed twice.
I mentioned it because I'm considering for TOF, I fully agree, let's decouple that from this PR and refactor (in one go?) both tasks.

On the second point, you're right. That works only for the particle of interest, for background it's harder.
Looks good!

[njacazio]

Hi, what is the status of the tune on data? Do you have a delivery estimate? It might be useful for the Pb-Pb

[jezwilkinson]

@njacazio picking back up on this - I made commits a little while ago for the most important points (moving the flag check into the PID header and making sure the seed is explicitly set to the UUID at the top of the process loop so the generator doesn't repeat)
On reflection I am not sure about the suggestion of having the process switch modified by the init() function, as it raises the chance of the option being accidentally set even if the user has explicitly disabled it in their configuration (for whatever reason - tuneondata should be the default for MC of course but there should be the option to not use it)

[njacazio]

Hi @jezwilkinson sounds good!