non-reproducibility in Tau nano branches

[vlimant]

While we know about #32628 non reproducibility of tau branches came up during a technical PR integration #44295 .
This issue should be tracked down and understood, to make sure there isn't anything else suspicious in the tau branch content.

[vlimant]

type tau

[vlimant]

assign xpog

[vlimant]

assign reconstruction

[cmsbuild]

New categories assigned: xpog,reconstruction

@vlimant,@hqucms,@jfernan2,@mandrenguyen you have been requested to review this Pull request/Issue and eventually sign? Thanks

[cmsbuild]

cms-bot internal usage

[cmsbuild]

A new Issue was created by @vlimant.

@smuzaffar, @sextonkennedy, @Dr15Jones, @antoniovilela, @rappoccio, @makortel can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[vlimant]

in the nano test workflow 2500.01_NANOdata106Xul16v2/all_NANO_step2 plots like

showed up

[mbluj]

@vlimant thank you for providing the plot. I will also preform some tests.
One comment and one kind request:

• The attached plot is for TauProd, i.e. tau object constituents. It could be that the "erase bug fix" by @makortel (Erase from correct vector in PATTauHybridProducer #44067) introduces a small difference in this (here 8 items less over ~23k in total);
• Is it possible for you to check easly if there is any difference in some Tau object variable, e.g. Tau_eta? It can narrow down area for studies.

[makortel]

• Erase from correct vector in PATTauHybridProducer #44067) introduces a small difference in this (here 8 items less over ~23k in total);

The test in #44295 (comment) used CMSSW_14_0_X_2024-03-03-2300. The 14_0_X backport of #44067, i.e. #44272, was merged in CMSSW_14_0_X_2024-03-04-2300, so this hypothesis is possible.

[mbluj]

I produced NanoAOD on top of 48k semileptonic ttbar events (2018 UL) with the following config:

cmsDriver.py --python_filename nano_cfg.py --eventcontent NANOAODSIM --customise_commands=process.add_(cms.Service('InitRootHandlers',EnableIMT = cms.untracked.bool(False)));process.MessageLogger.cerr.FwkReport.reportEvery=1000 --datatier NANOAODSIM --fileout file:nano.root --conditions auto:phase1_2018_realistic --step NANO --filein file:TTToSemiLeptonic.root --era Run2_2018,run2_nanoAOD_106Xv2 --no_exec --mc -n -1

with the following three software setups:

• plain CMSSW_14_0_X_2024-03-03-2300
• above+"erase fix" (commit 5584911)
• above+"erase fix"+"sorting improvements" (commit 6f6f634).

Then I checked no. of items in Tau and TauProd collections. The former was unchanged while the latter changed by ~1e-4 after introducing "erase fix" and not changed by "sorting improvements". Then I checked that the change is limited to PFGammas for tau candidates built for jets tagged as tau by ParticleNet and not reconstructed by the HPS algorithm. This is exactly the subset of TauProds that could be affected by the "erase fix". For this subset the difference in no. of items is ~1e-3.
As for me the issue is understood.

For reference, the TauProds of interest were selected like this:

Events->Draw("TauProd_pdgId","Tau_idDecayModeNewDMs[TauProd_tauIdx]==0&&abs(TauProd_pdgId)==22","");

[vlimant]

ok, thanks for the check