Unable to read 2018D data using CMSSW_10_2_10

[Dr15Jones]

From hypernews: https://hypernews.cern.ch/HyperNews/CMS/get/physTools/3647.html

I can use CMSSW_10_2_10 to process 17Sep2018 Run 2018/A/B/C data without any problem.
However, when I run on 2018D PR data, I get the following error

Exception Message:
No Dictionary for class: 'vector<reco::FeaturesTagInfo<btagbtvdeep::DeepDoubleBFeatures> >’ 

I was wondering whether anyone know how to fix this problem.

The pull request #25370 which was a backport to CMSSW_10_2 removed the class DeepDoubleBFeatures thereby making it not possible to read the Run2018D processed data.

[Dr15Jones]

assign reconstruction

[cmsbuild]

New categories assigned: reconstruction

@slava77,@perrotta you have been requested to review this Pull request/Issue and eventually sign? Thanks

[cmsbuild]

A new Issue was created by @Dr15Jones Chris Jones.

@davidlange6, @Dr15Jones, @smuzaffar, @fabiocos, @kpedro88 can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[slava77]

Here is an update from today.

One file name was shared as an example of the problem
/store/data/Run2018D/DoubleMuon/MINIAOD/PromptReco-v2/000/320/673/00000/FEC164FC-E897-E811-A713-FA163EE4DD06.root
The file was created in prompt reco using version CMSSW_10_2_1.

There is no data saved in the file output branches with DeepDouble* type, as seen from loading the file and then doing Events->Print().

As a test, using CMSSW_10_2_10, I ran nanoAOD processing on this file using configuration strings from the 2018 data workflow 136.8521.

[Dr15Jones]

I ran the following code in CMSSW_10_2_10

import FWCore.ParameterSet.Config as cms

process = cms.Process("TEST")

process.source = cms.Source("PoolSource", 
                            fileNames = cms.untracked.vstring("/store/data/Run2018D/DoubleMuon/MINIAOD/PromptReco-v2/000/320/673/00000/FEC164FC-E897-E811-A713-FA163EE4DD06.root") )

process.out = cms.OutputModule("PoolOutputModule", fileName = cms.untracked.string("copy.root"))

process.o = cms.EndPath(process.out)

which copied (slowly) every object from the input to the output. This ran fine for all 69169 events.

[slava77]

I managed to get a ~simple test with code in CMSSW which leads to the same problem.

import FWCore.ParameterSet.Config as cms
process = cms.Process("TEST")

process.maxEvents = cms.untracked.PSet( input = cms.untracked.int32(1000) )
process.source = cms.Source(
    'PoolSource',
    fileNames = cms.untracked.vstring('/store/data/Run2018D/DoubleMuon/MINIAOD/PromptReco-v2/000/320/673/00000/FEC164FC-E897-E811-A713-FA163EE4DD06.root')
    )

process.load('HLTrigger.HLTcore.hltEventAnalyzerAOD_cfi')

process.run = cms.Path(process.hltEventAnalyzerAOD
)

The original problematic case in https://hypernews.cern.ch/HyperNews/CMS/get/physTools/3647.html is similarly connected to instantiating HLTPrescaleProvider.
Somehow call to a constructor of HLTPrescaleProvider leads to materialization of the "ghost" branches in the input file.

@Dr15Jones what's a good way to debug?

There is a straightforward solution to make a dummy dictionary. Still, it would be good to understand what triggers the problem.

[slava77]

catch throw in gdb gives:

#1  0x00007ffff78acf50 in edm::TypeWithDict::typeInfo() const () from /cvmfs/cms.cern.ch/slc6_amd64_gcc700/cms/cmssw/CMSSW_10_2_10/lib/slc6_amd64_gcc700/libFWCoreUtilities.so
#2  0x00007fffbcb65a20 in L1GtUtilsHelper::operator()(edm::BranchDescription const&) ()
   from /cvmfs/cms.cern.ch/slc6_amd64_gcc700/cms/cmssw/CMSSW_10_2_10/lib/slc6_amd64_gcc700/libL1TriggerGlobalTriggerAnalyzer.so
#3  0x00007ffff7d3f8a1 in edm::stream::EDAnalyzerBase::registerProductsAndCallbacks(edm::stream::EDAnalyzerBase const*, edm::ProductRegistry*) ()
   from /cvmfs/cms.cern.ch/slc6_amd64_gcc700/cms/cmssw/CMSSW_10_2_10/lib/slc6_amd64_gcc700/libFWCoreFramework.so
#4  0x00007ffff7d41332 in edm::stream::EDAnalyzerAdaptorBase::registerProductsAndCallbacks(edm::stream::EDAnalyzerAdaptorBase const*, edm::ProductRegistry*) ()
   from /cvmfs/cms.cern.ch/slc6_amd64_gcc700/cms/cmssw/CMSSW_10_2_10/lib/slc6_amd64_gcc700/libFWCoreFramework.so

[slava77]

with linenumbers (this is CMSSW_10_2_10)

#2  0x00007fffbc9cc638 in edm::BranchDescription::unwrappedTypeID (this=0x7fffd362f0a0)
    at DataFormats/Provenance/interface/BranchDescription.h:98
#3  l1t::L1TGlobalUtilHelper::operator() (this=0x7fffd3992880, branchDescription=...) at L1Trigger/L1TGlobal/src/L1TGlobalUtilHelper.cc:65

The same problem is present in CMSSW_10_6_0_pre3

[rekovic]

Hi @slava77devel and @Dr15Jones
Is there any further insight on the reason why HLTPrescaleProvider give rise to "ghost" branches in the input file ?

[slava77]

Hi @slava77devel and @Dr15Jones
Is there any further insight on the reason why HLTPrescaleProvider give rise to "ghost" branches in the input file ?

the branch info is present in the file (ROOT or our EDM design).
The point for the update was not to check details for the branches that do not exist as saved data in the file.