Skip to content

Adding UFO calibration, new CDI, fixing Xbb cut

Janik Von Ahnen requested to merge emu_CR into master

What does this MR do?:

  1. Adding a user-configured jet calibration tool for UFO jets when running on Data to avoid SUSYTools crash.
  2. updating to new CDI and jet uncertainties recommendation
  3. Adding an OR requirement for track jet based b-tagging and the Xbb_25 80% WP. I believe that in our current ntuples (v05) the preselection is not quite correct for doing Xbb-tagger studies because the preselection applied here is always selecting events which have 2 b-tagged VR trk jets associated to the large R jet. So applying the Xbb tagger also always applies the track jet b-tagging.

Problems

I tested 1. on a data18 sample file from the p4321 EXOT27 and it worked fine. When I tried to run on a file from Znunu_PTV500_1000 (364222) p4320 I got the following error:

Click to see error
xAOD::TAuxStore::readFrom WARNING Static branch (EventInfoAux.) with split level 0 discovered
xAOD::TAuxStore::readFrom WARNING The reading of complex variables from it may/will fail!
IncidentSvc                                                   ERROR Standard std::exception is caught handling incident0x7ffe295f0d98
IncidentSvc                                                   ERROR SG::ExcBadAuxVar: Attempt to retrieve nonexistent aux data item `::eventTypeBitmask' (1297).
IncidentSvc                                                   ERROR Standard std::exception is caught handling incident0x7ffe295f0d98
IncidentSvc                                                   ERROR SG::ExcBadAuxVar: Attempt to retrieve nonexistent aux data item `::eventTypeBitmask' (1297).
IncidentSvc                                                   ERROR Standard std::exception is caught handling incident0x7ffe295f0d98
IncidentSvc                                                   ERROR SG::ExcBadAuxVar: Attempt to retrieve nonexistent aux data item `::eventTypeBitmask' (1297).
IncidentSvc                                                   ERROR Standard std::exception is caught handling incident0x7ffe295f0d98
IncidentSvc                                                   ERROR SG::ExcBadAuxVar: Attempt to retrieve nonexistent aux data item `::eventTypeBitmask' (1297).
IncidentSvc                                                   ERROR Standard std::exception is caught handling incident0x7ffe295f0d98
IncidentSvc       WARNING ERROR message limit (10) reached for IncidentSvc. Suppressing further output.
xAOD::TAuxStore::readFrom WARNING Static branch (PrimaryVerticesAux.) with split level 0 discovered
xAOD::TAuxStore::readFrom WARNING The reading of complex variables from it may/will fail!
ToolSvc.TrigDecisionTool                                       INFO updating config with SMK: 2216 and L1PSK: 76 and HLTPSK: 260
DecorateLRTruthLabels                                         FATAL  Standard std::exception is caught 
DecorateLRTruthLabels                                         ERROR SG::ExcBadAuxVar: Attempt to retrieve nonexistent aux data item `::eventTypeBitmask' (1297).
AthAlgSeq                                                     FATAL  Standard std::exception is caught 
AthAlgSeq                                                     ERROR SG::ExcBadAuxVar: Attempt to retrieve nonexistent aux data item `::eventTypeBitmask' (1297).
AthMasterSeq                                                  FATAL  Standard std::exception is caught 
AthMasterSeq                                                  ERROR SG::ExcBadAuxVar: Attempt to retrieve nonexistent aux data item `::eventTypeBitmask' (1297).
Traceback (most recent call last):
File "/cvmfs/atlas.cern.ch/repo/sw/software/21.2/AthAnalysis/21.2.150/InstallArea/x86_64-centos7-gcc8-opt/jobOptions/AthenaCommon/runbatch.py", line 20, in <module>
  theApp.run()     # runs until theApp.EvtMax events reached
File "/cvmfs/atlas.cern.ch/repo/sw/software/21.2/AthAnalysis/21.2.150/InstallArea/x86_64-centos7-gcc8-opt/python/AthenaCommon/AppMgr.py", line 663, in run
  sc = self.getHandle()._evtpro.executeRun( nEvt )
Exception: StatusCode IEventProcessor::executeRun(int maxevt) =>
  SG::ExcBadAuxVar: Attempt to retrieve nonexistent aux data item `::eventTypeBitmask' (1297). (C++ exception of type SG::ExcBadAuxVar)
XAMPPAlgorithm                                                 INFO Finalizing XAMPPAlgorithm...
MetaDataMC::SaveMetaDa... INFO    Write metadata in file with DSID: 364222, ProcessID : 0, process name: Nominal_Inclusive SumW: 14279.906750, SumW2: 38391.967182, TotalEvents: 20000, ProcessedEvents: 0
TreeBase::FinalizeTree()  INFO    Successfully written MonoH_Nominal containing 0 entries.

This can be fixed by changing AssembleIO() to AssembleIO(1) , i.e. changing access mechanism from kBranchAccess to kClassAccess. However, even with this fix the code breaks after a couple of thousand events have been processed with the following error:

Click to see error
AthenaEventLoopMgr                                             INFO   ===>>>  done processing event #0, run #0 1 events processed so far  <<<===
Entry 1000 / 20000 (5%) in file 1 / 1 @ 00:00:30. Physics Event Rate: 33.1 Hz, Computing Event Rate: 33.1 Hz, E.T.A.: 00:09:33 (updating screen each 1000 events)
Entry 2000 / 20000 (10%) in file 1 / 1 @ 00:00:58. Physics Event Rate: 34.2 Hz, Computing Event Rate: 34.2 Hz, E.T.A.: 00:08:45 (updating screen each 1000 events)
Entry 3000 / 20000 (15%) in file 1 / 1 @ 00:01:26. Physics Event Rate: 34.7 Hz, Computing Event Rate: 34.7 Hz, E.T.A.: 00:08:10 (updating screen each 1000 events)
Entry 4000 / 20000 (20%) in file 1 / 1 @ 00:01:54. Physics Event Rate: 34.8 Hz, Computing Event Rate: 34.8 Hz, E.T.A.: 00:07:39 (updating screen each 1000 events)
Entry 5000 / 20000 (25%) in file 1 / 1 @ 00:02:22. Physics Event Rate: 35 Hz, Computing Event Rate: 35 Hz, E.T.A.: 00:07:08 (updating screen each 1000 events)
Entry 6000 / 20000 (30%) in file 1 / 1 @ 00:02:51. Physics Event Rate: 35 Hz, Computing Event Rate: 35 Hz, E.T.A.: 00:06:39 (updating screen each 1000 events)
Entry 7000 / 20000 (35%) in file 1 / 1 @ 00:03:19. Physics Event Rate: 35 Hz, Computing Event Rate: 35 Hz, E.T.A.: 00:06:11 (updating screen each 1000 events)
XAMPPAlgorithm                                                FATAL  Standard std::exception is caught 
XAMPPAlgorithm                                                ERROR SG::ExcBadAuxVar: Attempt to retrieve nonexistent aux data item `::pdgId' (189).
AthAlgSeq                                                     FATAL  Standard std::exception is caught 
AthAlgSeq                                                     ERROR SG::ExcBadAuxVar: Attempt to retrieve nonexistent aux data item `::pdgId' (189).
AthMasterSeq                                                  FATAL  Standard std::exception is caught 
AthMasterSeq                                                  ERROR SG::ExcBadAuxVar: Attempt to retrieve nonexistent aux data item `::pdgId' (189).
Traceback (most recent call last):
  File "/cvmfs/atlas.cern.ch/repo/sw/software/21.2/AthAnalysis/21.2.150/InstallArea/x86_64-centos7-gcc8-opt/jobOptions/AthenaCommon/runbatch.py", line 20, in <module>
    theApp.run()     # runs until theApp.EvtMax events reached
  File "/cvmfs/atlas.cern.ch/repo/sw/software/21.2/AthAnalysis/21.2.150/InstallArea/x86_64-centos7-gcc8-opt/python/AthenaCommon/AppMgr.py", line 663, in run
    sc = self.getHandle()._evtpro.executeRun( nEvt )

The behaviour is the same for a Wenu_500_1000 (364182) file for which I have tested this. Could it be that there is something wrong with the EXOT27 derivations produced with p4320? Just to be clear I haven't seen these errors with the following EXOT27 productions: p3990 (364222 MonoH), p3991 (signal MonoH), p4050 (MonoH data), p4321 (data with UFO).

How to proceed?

There are 3 things which I would like to check the impact of and these are:

  1. UFO vs LCTopo
  2. 201810 vs 201903 vs Xbb b-tagging
  3. emu CR

The point 1. seems difficult because in the case that the problem with p4320 is not a problem of XAMPP we would have to wait for new derivations.

Point 3. I would like to address in our meeting tomorrow. This is also the reason I put this MR as WIP for the moment because I want to make some changes here before submitting a new ntuple production.

For this reason, I would propose that I produce a new set of ntuples with p3990 & p4062 (this is what we used for v05) but using 201903 b-tagging and the correct preselection for Xbb b-tagging which I could then compare to the Mono-H selection of the v05 ntuples addressing 2. and 3..

What are your thoughts @changqia @jburr ?

Edited by Janik Von Ahnen

Merge request reports