FT0 LUT prepared as Singleton for DigitBlockFT0 usage

[afurs]

Static member (o2::ft0::LookUpTable) in DigitBlockFT0 changed to simple Singleton(o2::ft0::SingleLUT)

[shahor02]

Hi @afurs
Thanks, but I still have a question: at the moment the processDigits is not called anywhere in the code, where is it supposed to be called first? I see that you are still reading from the CCDB at the time of LUT creation. The CCDB is supposed to be ready to take queries only from the DPL processing function (run(...)), when the TF with defined timestamp is processed.

Also, in general the CCDB-dependent core is supposed to re-query the CCDB for every TF, unless you know a priory that the object validity covers whole period. But if I understood @AllaMaevskaya correctly, this seems to be the case for this LUT?

[afurs]

Hello @shahor02,
proccessDigits is called in DigitBlockBase::process()

AliceO2/Detectors/FIT/raw/include/FITRaw/DigitBlockBase.h

Line 42 in ef71fd2

static_cast<DigitBlock*>(this)->processDigits(dataBlock, linkID);

And DigitBlockBase::process() is in RawReader::processBinaryData()

AliceO2/Detectors/FIT/raw/include/FITRaw/RawReaderBase.h

Line 71 in ef71fd2

digitIter->second.template process<DataBlockType>(dataBlock, linkID);

which is working within full data flow (run(...)), after initialization. So, first call of SingleLUT will be in first iteration.

"CCDB-dependence" could be easily changed to readings from config file if it is necessary. As I understand, LUT is expected to be a constant within several runs(definitely between two Technical Stops), or even period. And CCDB is just playing main holder role for FT0 LUT, in other words it doesn't depend on TFs. @AllaMaevskaya could you confirm or reject my statements, or to correct them?

So, in such cases, is it normal to use CCDB during initialization? Or CCDB usage before data flow is forbidden for all cases?

[shahor02]

@afurs OK, thanks. It is fine to load config from CCDB, why I meant is in that case one should check for eventual update when the TF changes. In this context, the initialization of the LUT or possible update is better to do not deep in the loop but in the beginning of the run(). Anyway, will merge this PR once the checks are passed, changes may be done later.