Questions about the processing of pedestals data for MCH

@shahoian @laphecet @ppillot @zampolli @bond I have committed a first version of the MCH pedestals calibrator code, it is available from this branch.
The workflow is composed of:

  • a special decoder that generates “fat” digits. The decoder is supposed to run on several EPNs and to send the digits to the centralized calibrator
  • a calibrator that collects the digits from the various time slots (the length of the time slot is not really important) and updates the channel-by-channel mean and RMS of the pedestal values

I would appreciate if some expert could have a look at the code and let me know if it is compatible with the expected implementation of O2 calibrators.
The part that should fill the CDDB with the calibration output is not yet implemented, as the optimal format of the stored objects is not yet clear…

Thanks!

@aferrero

You need just 1 time slot == full duration of calibration run, right?
Then instead of these settings you should set in the init “infinit” amount of TFs per slot and the setMaxSlotsDelay is irrelevant since all TFs will be within your 1st slot.

For the MCHChannelCalibrator: why do you accumulate digits in the vector within the slot, rather than process it on the fly?

Within the paradigm of time-slot calibration you should have these data members in the slot itseld, i.e. as data member of the MCHChannelData (instead of having there the vector of PDigits), and the MCHChannelData::fill method would update on the fly the pedestal and noise arrays for every TF accounted.

Cheers,
Ruben

@shahoian how ofter would the MCHChannelData::fill() method be called in the case of time slots of infinite duration? Once for every TF coming from the decoder(s), or only once for the full slot?

In the latter case, the size of the digits buffer would probably grow too much…

fill is called every time new TF data is added to the slot.

For TOF, the TOFCalibCollector also has only 1 slot, but I implemented it a bit differently. In my case, I defined

mCollector->setMaxSlotsDelay(0);

and the slot length is just 1. This allows to verify at every TF whether I can or not send the output (I am just writing to file), if not, the slot is enlarged. I am afraid, but maybe I misread the code, that if the length is inifinite, then the hasEnoughData will never be called:

Am I overlooking something?

@zampolli : as far as I understand, @aferrero does not want to quit once hasEnoughData==true, he wants to process till the end of the run. For this reason the setUpdateAtTheEndOfRunOnly mechanism is used, which disables the checkSlotsToFinalize call for every TF.

But I have to correct/complete my prev. message:

  1. the tf-per-slot should be large to cover the whole run, but still finite, i.e. < constexpr uint64_t INFINITE_TF = 0xffffffffffffffff

  2. The max-delay can be anything ensuring that max-delay + tf-per-slot < INFINITE_TF, to trigger the finalization of the unique slot when called with INFINITE_TF . I would use e.g. tf-per-slot = INFINITE_TF-10 and max-delay=1.

  3. the hasEnoughData method must return true if the data should be unconditionally processed in the end of the run (the only call of checkSlotsToFinalize).

Otherwise, if there is indeed a risk of insufficient statistics and some action should be taken in such a case, then the hasEnoughData must really evaluate the stat. and corresponding action should be implemented.

I have modified the code following your suggestions, and the new version is committed to the same branch as my previous draft.

I have run some tests and as far as I can tell, the code properly generates and sends one BadChannelsVector object when the end-of-stream is reached. However I would really appreciate if you could have another look to see if I fixed all places.

The output is actually just a vector of 32-bit integers, so I am wondering what is the most efficient way of storing it…

Thanks!

@shahoian @zampolli @laphecet
given that the bulk structure of the code is now clear, I have created a draft PR: [WIP] MCH: pedestals calibration workflow by aferrero2707 · Pull Request #5627 · AliceO2Group/AliceO2 · GitHub

I propose to continue the discussion in the PR’s comments.

One thing that I would like you to double check in particular is the definition of the BadChannelsVector object that is being stored in the CCDB, and wether it should be moved to the MCH-specific part of the O2 DataFormats.

The code in this branch will have to be rebased once #5620 is merged.

Thanks!

Hi Ruben,

I was checking the MCH code, and especially the use of setUpdateAtTheEndOfRunOnly. When one uses this option, the slot length does not matter, because at every new TF which happens in the future, it is enlarged, see

This was done on purpose for the TOF channel calibrator. Also the max_delay is not really useful. And in fact, I don’t even set time slot length and max delay for TOF.

Do you see any flaw in the way the setUpdateAtTheEndOfRunOnly was implemented?

Chiara