Skip to content

Add work around to RichPID unpacking to correct incorrect data version.

Christopher Rob Jones requested to merge jonrob/LHCb:RichPIDPacking-AddIncorrectVersionWorkaround into 2018-patches

In 2017 a new version of the RICH reconstruction was introduced, based on the upgrade functional framework. Due to a few issues in the framework an issue exists in 2017 data where the DataObject version of the RichPID containers was not correctly saved. This version is used to identify older versions of the containers, and to perform various corrections accordingly, to account for various format changes that have occurred during Run1 and Run2. The bug means DaVinci, when reading the 2017 data, thinks these data is very old and performs a number of corrections, modifying the data in incorrect ways.

The impact of the bug is :

  • It only affects the Deuteron and BelowThreshold DLL values in the RichPID objects. All the others are unaffected. What happens, specifically, is the Deuteron DLL value is copied to the BelowThreshold value, and then set to zero.
  • The ProbNN PID values are affected only when recomputed from scratch, by the ANNPIDTupleTool, as they use the BelowThreshold DLL value. The values stored in the ProtoParticles themselves, which are the ones used by stripping lines for instance, are fine.
  • For physics reasons, the Deuteron and BelowThreshold DLL values are normally exactly the same value (Because the Deuteron hypothesis, has a heavy mass and thus high momentum threshold, and thus is normally also below threshold). This also reduces the impact of the bug as often the replaced DLL values are the same as the original ones.

My understanding is there are no lines that cut on Deuteron or BelowThreshold DLL values, so the stripping therefore is fine. Few users directly use these DLL values offline, but if you do you will be affected.

The primary impact is therefore at the user level, when the ProbNN values are recomputed for the DTT. Note this affects all hypotheses, as they all use the same list of inputs, that include the affected DLLs.

Luckily its easy to detect when this situation occurs, due to the fact I save independently the packing version from the data version, and the packing version is OK. So if packing version > 3 but data version = 0, I correct the data version to 2 during the unpacking. This MR implements this correction. Several DaVinci releases (now) include this work-around in the unpacking. This leads to warnings such as

UnpackRichPIDs    WARNING DataPacking::Unpack<LHCb::RichPIDPacker>::
Incorrect data version 0 for packing version > 3. Correcting data to version 2.
  • If you see these when processing 2017 data do not worry.
  • If you see these with any other years data, please report it.
  • If you are processing 2017 data you must use a DaVinci version with this fix, otherwise you could be using partly corrupted PID information.

Which versions to use ? As of 17th August 2018 :-

  • All DaVinci versions released on 2018-patches starting with v44r2 contain the fix (that is using Rec v23r2 at least). The latest is v44r4.
  • All DaVinci versions released on 2017-patches starting with v42r8 contain the fix (!1252 (merged), released in LHCb v42r8)
  • The first stack release on run2-patches will contain the fix (!1245 (merged)).
  • All DaVinci versions released on master starting with v50r1 contain the fix (!1251 (merged), released in LHCb v50r1).
Edited by Marco Cattaneo

Merge request reports