Use flag HBFUtils.obligatorySOR to start raw data from TF with SOX + fixes

[shahor02]

@davidrohr : If the HBFUtils.obligatorySOR==false (default) the MC->Raw converted data will start from the 1st TF containing
data (i.e. corresponding to HBFUtils.orbitFirstSampled), the SOX in the RDH will be set only if this TF coincides
with the 1st TF of the Run (defined by the HBFUtils.orbitFirst).
With HBFUtils.obligatorySOR==true old behaviour will be preserved: the raw data will start from TF with HBFUtils.orbitFirst
with SOX always set and for CRU detectors all HBFs/TFs between HBFUtils.orbitFirst and 1st non-empty HBF will be
filled by dummy RDHs.

[davidrohr]

thx, will try tomorrow

[shahor02]

@aphecetche could you check cb1a73a ?
The o2-mch-digits-to-raw was calling writer->addData with IR starting from HBFUtils.orbitFirst even if the digitization was done with HBFUtils.orbitFirstSampled >> HBFUtils.orbitFirst. In principle, you should not use the HBFUtils.orbitFirst at all, unless you need to set some global parameter at the start of the run.

[davidrohr]

This should be

OBLIGATORYSOR=${OBLIGATORYSOR:-0}

Note the -!

[shahor02]

ok for - but why 0 and not false?

[davidrohr]

Fails the FST due to wrong bash syntax, but otherwise works correctly.

[davidrohr]

OK, was a bit too quick. Now I see problems in MID raw files:

[O2PDPSuite/latest] ~/alitest/tmp-test $> o2-raw-file-check raw/MID/MID_alio2-cr1-flp159_cru0_0.raw
[INFO] RawDataHeader v6 is assumed
[INFO] apply  check for Mismatch between flagged and calculated new TF start
[INFO] ignore check for No SOX found on 1st page
[INFO] ignore check for TF does not start by new superpage
[INFO] apply  check for Wrong HBF orbit increment
[INFO] apply  check for Number of TFs is less than expected
[INFO] apply  check for Number of HBFs per TF not as expected
[INFO] apply  check for Data does not start with TF/HBF
[INFO] apply  check for New HBF starts w/o closing old one
[INFO] ignore check for RDH.stop set of 1st HBF page
[INFO] apply  check for Wrong RDH.pageCnt increment
[INFO] apply  check for Wrong RDH.packetCounter increment
[INFO] perform check for /Wrong RDH.packetCounter increment/
[INFO] perform check for /Wrong RDH.pageCnt increment/
[INFO] perform check for /New HBF starts w/o closing old one/
[INFO] perform check for /Data does not start with TF/HBF/
[INFO] perform check for /Number of HBFs per TF not as expected/
[INFO] perform check for /Number of TFs is less than expected/
[INFO] perform check for /Wrong HBF orbit increment/
[INFO] perform check for /Mismatch between flagged and calculated new TF start/
[ERROR] Data does not start with TF/HBF
[ERROR]  ^^^Problem(s) was encountered at offset 0 of file 0
[ERROR] Unexpected RDH version 128 from
[INFO] [rdh0] 0xeb0d01c0 0x001feb0d 0x0180000f 0xeb0d0180
[INFO] [rdh1] 0x01c00050 0xeb0d01c0 0x0060eb0d 0x01c00070
[INFO] [rdh2] 0x0020eb0d 0x01c00030 0xeb0d01c0 0x0040eb0d
[INFO] [rdh3] 0xeb0d0180 0x0000eb0d 0x01c00010 0xeb0d01c0
[ERROR] Corrupted data, abandoning processing
[INFO] File   0 :         0 bytes scanned,      1 RDH read for    1 links from raw/MID/MID_alio2-cr1-flp159_cru0_0.raw
[ERROR] Abandoning processing due to corrupted data
Real time 0:00:00, CP time 0.000

Generated with

FIRSTSAMPLEDORBIT=256 SPLITTRDDIGI=0 NEvents=5 NEventsQED=100 ~/alice/O2/prodtests/full_system_test.sh

Before this PR the MID files were ok. Only tried once, not sure whether this is coincidence.

[shahor02]

OK, was a bit too quick. Now I see problems in MID raw files:

@davidrohr I cannot reproduce this, could you provide your middigits.root, collisioncontext.root and o2simdigitizerworkflow_configuration.ini ?

[davidrohr]

OK, was a bit too quick. Now I see problems in MID raw files:

@davidrohr I cannot reproduce this, could you provide your middigits.root, collisioncontext.root and o2simdigitizerworkflow_configuration.ini ?

files are here: https://qon.jwdt.org/nmls/tmp/mid.tar.gz

[shahor02]

@dstocco : You are subtracting from the ir a few 10s BCs, as a result, it can become negative (i.e. wrap to a huge value) or precede the 1st sampled TF. Could you check this part?

The example where this was happening (encountered by @davidrohr ) had the following:
1st sampled orbit: 256
Sampled collisions:

root [3] for (auto ir : irc) std::cout << ir << "\n"
BCid:   48 Orbit:    256 |T in BC(ns): -0.069
BCid: 1346 Orbit:    256 |T in BC(ns): 0.040
BCid: 1998 Orbit:    256 |T in BC(ns): -0.206
BCid: 1356 Orbit:    257 |T in BC(ns): -0.028
BCid:   42 Orbit:    258 |T in BC(ns): 0.129

Produced MID digits ROFs:

root [1] o2sim->Scan("MIDROFRecords.interactionRecord.bc : MIDROFRecords.interactionRecord.orbit")
***********************************************
*    Row   * Instance * MIDROFRec *  MIDROFRe *
***********************************************
*        0 *        0 *        48 *       256 *
*        0 *        1 *      1346 *       256 *
*        0 *        2 *      1356 *       257 *
*        0 *        3 *        42 *       258 *
***********************************************

Subtracting from the 1st ROF IR mElectronicsDelay.localToBC = 59 you call 1st addData for the orbit 255 which appears in the TF preceding the generated one.

[shahor02]

@davidrohr now should work though I am not sure this is a final fix for the MID, need @dstocco 's response.

[davidrohr]

works for me now

[shahor02]

@TimoWilken the fullCI builder seems to time-out, also in other PRs, e.g. #8590

[davidrohr]

ran FST manually and it worked, merging

[davidrohr]

This could be the geant4 problem i reported in the other mail thread. In long simulations it gets always stuck. Perhaps in the 5 event simulation of the fst it gets stuck randomly?