Problem with UT decoding in new MC samples

When testing the new MC samples using the files in the TestFileDB added in lhcb-datapkg/PRConfig!164 (merged), I came across a segmentation fault that seems related to the UT decoding, see the stack trace in the attachment stacktrack_newMC.txt

To produce the segmentation fault, I attach the options I used DC_newMC_Bd2Dstmumu.py and ran

Moore/run gaudirun.py DBASE/PRConfig/options/Moore/DataChallenges/DC_newMC_Bd2Dstmumu.py DBASE/PRConfig/options/Moore/DataChallenges/DC_default_conds.py Moore/Hlt/Moore/tests/options/DC_histo_file.py Moore/Hlt/RecoConf/options/hlt2_reco_baseline_with_mcchecking.py

added Decoding MC checking UT hlt2 labels

I've reproduced this on the avx2+fma platform. When I build and run with gcc9-dbg I get the following assertion error:

../Pr/PrKernel/PrKernel/PrUTHitHandler.h:84: void LHCb::Pr::UT::HitHandler::AddHit(const DeUTSector*, unsigned int, unsigned int, double, LHCb::UTChannelID, unsigned int, bool): Assertion `indices.first == indices.second' failed.

from https://gitlab.cern.ch/lhcb/Rec/-/blob/ff4dc56f69d8f0b37f187a5864a86d3243e91921/Pr/PrKernel/PrKernel/PrUTHitHandler.h#L84

Strangely, when I add options.print_freq = 1 I get a segmentation violation without a stack trace (on the second event). In any case it seems with that input file (root://x509up_u50863@eoslhcb.cern.ch//eos/lhcb/grid/prod/lhcb/MC/Upgrade/XDIGI/00122698/0000/00122698_00000003_1.xdigi) it is quite easy to reproduce.

mentioned in merge request LHCb!2914 (merged)

@sklaver : it looks like the error is because the option file DBASE/PRConfig/options/Moore/DataChallenges/DC_default_conds.py, which sets the old simcond tag (sim-20180530-vc-md100) from upgrade_DC19_01_Bs2PhiPhiMD Another question: I check the masted branch of PRConfig, but cannot find DC_newMC_Bd2Dstmumu.py. Could you please let me know which branch you use?

@xuyuan Aha, well spotted! Is it possible to add a check somewhere that the data is not compatible with the conditions? The assert is effectively such a check but it would be nice if we have one that runs also in optimized builds and produces a helpful error message.

@rmatev I can add a check in Pr/PrAlgorithms/src/PrStoreUTHit.cpp like if new condition used for new bank version. Is that OK?

yes, let's try that! we should check it doesn't slow down the processing

You can do something like

if (UNLIKELY(.... failure_condition .....) {
  throw GaudiException{"Conditions not compatible with data", this->name(), StatusCode::FAILURE};
}

mentioned in merge request Rec!2335 (merged)

@rmatev I see another MR LHCb!2913 (closed) from @mstahl with adding the version in UTReadoutTool. Should we think about to merge @mstahl 's change and then I can call the comparison of the version in ReadoutTool (inheriting from the condition) and RawBank?

I think my MR can be closed. Sorry for the confusion!

@mstahl I will merge your codes in my branch. Thanks for your codes.

I think it was decided we shouldn't make these changes. See the discussion at Rec!2334 (closed)

Hi Many thanks for the information. The thing confuses me that in my thought there should have three version: from UTgeometry, from condition simcond and that from RawBank and there should be a check with all these three version should be the same otherwise throw an error report in PrStoreUTHit. Of course these check with be added in the initialization part of PrStoreUTHit. So is that still a kind of 'hot' check?

The most important check with the raw bank version can only be done in the operator(). As @graven says, it is probably not so "hot" to check a few raw bank versions. In any case, let's try to implement such checks after Rec!2335 (merged) and we can see the performance.

hi @xuyuan, thanks for letting me know I was using the wrong tag, that indeed solved my problem :) I've now added all my tests to the branch sklaver_newMC_PRjobs in PRConfig, in case they're useful for you.