[12.2.X] fix the cms EDModule type of GenParticleMatchMerger

[mmusich]

backport of #37613

PR description:

It appears that CollectionAdder

cmssw/CommonTools/UtilAlgos/interface/CollectionAdder.h

Line 17 in 837fd56

class CollectionAdder : public edm::global::EDProducer<> {

which is the underlying module type of

cmssw/PhysicsTools/HepMCCandAlgos/plugins/GenParticleMatchMerger.cc

Line 4 in 6d2f660

typedef CollectionAdder<reco::GenParticleMatch> GenParticleMatchMerger;

is an EDProducer, but it was declared in the configuration as an EDFilter:

cmssw/SimTracker/TrackAssociation/python/allTrackMCMatch_cfi.py

Line 3 in 837fd56

allTrackMCMatch = cms.EDFilter("GenParticleMatchMerger",

leading to runtime errors of the type:

----- Begin Fatal Exception 19-Apr-2022 00:54:18 CEST-----------------------
An exception of category 'Configuration' occurred while
   [0] Constructing the EventProcessor
   [1] Validating configuration of module: class=GenParticleMatchMerger label='allTrackMCMatch'
Exception Message:
The base type in the python configuration is EDFilter, but the base type
for the module's C++ class is EDProducer. Please fix the configuration.
It must use the same base type as the C++ class.
----- End Fatal Exception -------------------------------------------------

this is trivially fixed here.
In addition in commit f68a4df, I take care of some other mismatched types in the configuration.
The parameter associator of MCTrackMatcher should be a cms.string and not a cms.InputTag:

cmssw/SimTracker/TrackAssociation/plugins/MCTrackMatcher.cc

Line 44 in 9583b99

: associator_(consumes<reco::TrackToTrackingParticleAssociator>(p.getParameter<string>("associator"))),

Finally in the same commit, the value of the variable associator in Tracker/TrackAssociation/python/trackMCMatch_cfi.py is corrected such that it is trackAssociatorByHits and not TrackAssociatorByHits

PR validation:

Private scripts.

if this PR is a backport please specify the original PR and why you need to backport that PR:

verbatim backport of #37613.

[cmsbuild]

A new Pull Request was created by @mmusich (Marco Musich) for CMSSW_12_2_X.

It involves the following packages:

• SimTracker/TrackAssociation (simulation)

@cmsbuild, @civanch, @mdhildreth can you please review it and eventually sign? Thanks.
@mtosi, @abbiendi, @GiacomoSguazzoni, @JanFSchulte, @rovere, @VinInn, @jhgoh, @mmusich, @threus, @dgulhan this is something you requested to watch as well.
@perrotta, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

• Backported from fix the cms EDModule type of GenParticleMatchMerger #37613

[mmusich]

type bug-fix

[mmusich]

please test

[cmsbuild]

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-ecfee3/24122/summary.html
COMMIT: 84d848d
CMSSW: CMSSW_12_2_X_2022-04-21-2300/slc7_amd64_gcc900
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week1/cms-sw/cmssw/37653/24122/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

• No significant changes to the logs found
• Reco comparison results: 2 differences found in the comparisons
• DQMHistoTests: Total files compared: 42
• DQMHistoTests: Total histograms compared: 3251324
• DQMHistoTests: Total failures: 6
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 3251296
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 41 files compared)
• Checked 177 log files, 37 edm output root files, 42 DQM output files
• TriggerResults: no differences found

[civanch]

+1

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_12_2_X IBs (tests are also fine) and once validation in the development release cycle CMSSW_12_4_X is complete. This pull request will now be reviewed by the release team before it's merged. @perrotta, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2)

[perrotta]

+1

• Verbatim backport of fix the cms EDModule type of GenParticleMatchMerger #37613
• Merge and let it there, just in case a new release for this cycle gets requested

[Martin-Grunewald]

Since CMSSW_12_2_X_2022-04-22-2300 some of the HLT validation tests fail with error message:

----- Begin Fatal Exception 22-Apr-2022 22:57:40 UTC-----------------------
An exception of category 'ConditionDatabase' occurred while
   [0] Processing Event run: 346304 lumi: 378 event: 367545818
   [1] Running path 'Flag_trkPOG_logErrorTooManyClusters'
Exception Message:
Payload of type LHCInfo with id 9939e472f6e68b00b311feba047f6f55bd5b0979 could not be loaded. An exception of category 'ConditionDatabase' occurred.
Exception Message:
De-serialization failed: the current boost version (1_75) is unable to read the payload. Data might have been serialized with an incompatible version. Payload serialization info:  {
"CMSSW_version": "CMSSW_12_3_0",
"architecture": "slc7_amd64_gcc10",
"technology": "boost/serialization",
"tech_version": "1_78"
 }
 from default_deserialize 
 from Session::fetchPayload 
----- End Fatal Exception -------------------------------------------------

The only PR integrated is this one, @mmusich could you please have a look?
See also https://cmssdt.cern.ch/SDT/jenkins-artifacts/HLT-Validation/CMSSW_12_2_X_2022-04-24-0000/slc7_amd64_gcc900/RelVal_RECO_GRun_DATA.log as most recent.

The workflow is:

# Auto generated configuration file
# using: 
# Revision: 1.19 
# Source: /local/reps/CMSSW/CMSSW/Configuration/Applications/python/ConfigBuilder.py,v 
# with command line options: RelVal --step=RAW2DIGI,L1Reco,RECO,EI,PAT,DQM --conditions=auto:run3_data_GRun --filein=file:RelVal_HLT_GRun_DATA.root --custom_conditions= --fileout=RelVal_RECO_GRun_DATA.root --number=100 --data --no_exec --datatier RECO,MINIAOD,DQMIO --eventcontent=RECO,MINIAOD,DQM --customise=HLTrigger/Configuration/CustomConfigs.Base --era=Run3 --customise= --scenario=pp --python_filename=RelVal_RECO_GRun_DATA.py --processName=RECO1

[mmusich]

@Martin-Grunewald this has absolutely nothing to do with this PR.

[mmusich]

@Martin-Grunewald this is due to the change of the underlying boost version for CMSSW_12_3_0, bring the discussion elsewhere.

[Martin-Grunewald]

So I assume with the new boost in 12_3 someone has written a new record now also consumed within 12_2 ?

[mmusich]

@Martin-Grunewald

So I assume with the new boost in 12_3 someone has written a new record now also consumed within 12_2 ?

What is happening here is that you are trying to read a payload written with boost 1.78 (so presumably written only recently) with a version that only supports up to 1.75.
This is what happens when you run an IB workflow with an open-ended Global Tag, something that I have warned numerous times @cms-sw/alca-l2 about...

[Martin-Grunewald]

OK, thanks. Moved the discussion here:
https://cms-talk.web.cern.ch/t/exception-of-category-conditiondatabase/9659