TWiki> Main Web>HSCPMigrationTo123X (revision 16)EditAttachPDF

Warning: this migration was performed in february 2022 (from CMSSW_10_6_28 to CMSSW_12_3_X)


Files: AOD format are needed in order to go through steps 0 and 1 of the HSCP Analyzer :

You can find the whole process of generating your GEN-SIM for run 3, up to AOD format with a custom Hlt menu ( :

This whole twiki was made for the sub-package HSCP. Changes were not made on the Analyzer/Calibration side, but the way to go will be documented.

Expect whole package to be 12_3_X ready on the 18/03/2022


All concerned files

This table shows every file that is directly impacting the migration. All these files have been modified, and further details are available for each of those in the following sections. I am focusing on the HSCParticleProducer, and all its related files.

Important files

Main changes

In ESProducer

NOTE: Registration of products in ESProducers has been enforced since 11_0_0_pre12

The setWhatProduced() call returns an edm::ESConsumesCollector (the type REC is the Record type that the producing function given to setWhatProduced() takes as an argument). The collector is then used to register all the data products that may be accessed by the producing function. If the ESProducer registers multiple producing functions, the data access needs to be registered separately for each of them.

Some examples

class Producer: public edm::ESProducer {
  std::unique_ptr<AnyProduct> produce(SomeRecord const& iRecord);
  edm::ESGetToken<AnyProduct, SomeOrDependentRecord> token1_;
  edm::ESGetToken<SomeProduct, SomeRecord> token2_;
  edm::ESGetToken<AnotherProduct, DependentRecord> token3_;


Producer::Producer(edm::ParameterSet const& iConfig) {
  auto cc = setWhatProduced(this);

  // Register data access with type deduction (available since 11_2_0_pre6, earlier one could do cc.setConsumes(token1_))
  token1_ = cc.consumes();

  // Register data access with explicit types from the same record as the produce() argument
  token2_ = cc.consumes<SomeProduct>();

  // Register data access with explicit types from a dependent record of the produce() argument
  token3_ = cc.consumesFrom<SomeProduct, DependentRecord>();

All of the functions above (consumes(), consumesFrom()) take also an edm::ESInputTag as an optional argument.

NOTE: the proper way to migrate from iRecord.get(handle, label) is edm::ESInputTag{"", label}.

Paths Changes

The following header files have different paths in release 12_3_X. The paths changes have been implemented in every file listed in the table above, but not every file uses evey header.

Header files New path
PixelBarrelName.h /DataFormats/TrackerCommon/interface/
SiStripSubStructure.h /DataFormats/TrackerCommon/interface/
PixelBarrelName.h /DataFormats/TrackerCommon/interface/
PixelEndcapName.h /DataFormats/TrackerCommon/interface/
PixelGeomDetUnit.h /Geometry/CommonTopologies/interface/
CaloTopologyRecord.h /Geometry/Records/interface/
​EcalDetIdAssociator.h TrackingTools/​TrackAssociator/​plugins/​

Code Changes

The main problem in the migration between CMSSW_10_6_X to 12_3_X comes when you take a condition from the event setup

This passes the iSetup to different functions, that must all be changed accordingly.

Files modified

File ESHandles changed
Green led tkGeom,DtGeom,CscGeom,RpcGeom
Green led CaloTopology
Green led Propagator
Red led Propagator,theDTGeom
Green led DtGeom,CscGeom
Green led tkGeom
Green led RPCGeomToken
Green led ecalDetIdAssociator_,bFieldToken_,theCaloGeometry_,CaloTopologyToken_
Green led tTopoToken
Green led bFieldToken_
Green led details below
Red led changes ?
Green led tTopoToken_,tkGeomToken_,pixelCPEToken_
Green led rpcGeoToken_
Green led tTopoToken_,tkGeomToken_,pixelCPEToken_
Green led -
Green led -
Green led -
Green led -
Green led -
Green led -
Green led -

Example of changes (on the ESHandle theCaloGeometry_ from :

Old version


data members

edm::ESHandle<CaloGeometry> theCaloGeometry_;

addInfoToCandidate function

const CaloGeometry* theGeometry = theCaloGeometry_.product();

New version


data members

edm::ESGetToken<CaloGeometry, CaloGeometryRecord> theCaloGeometry_;


theCaloGeometry_(iC.esConsumes<CaloGeometry, CaloGeometryRecord>())

addInfoToCandidate function

auto const theGeometry = &iSetup.getData(theCaloGeometry_);

Modification of each file

-> Changes in the constructor : added tokens and consumes before bool isInitialized

-> Why is the private data members declared like const CaloTopology* CaloTopology; and then in the .cc aswell ?

To change all

-> Fixed

-> To change

->dtGeomToken and cscGeomToken were switched to ESGetToken

-> Fixed -> Line 97 : fillTiming function to investigate

-> The rest is functionnal under 12_3_X

-> trackAssociator_.associate function in line 157 to investigate :

No ESHandle in both following BetaCalculators, everything is commented -> what is it used for ?*

Commented Files

Green led This .cc file is calling a given function from different classes


The funtion addInfoToCandidate takes multiple input as following. The 4 classes are used with separate conditions, and iSetup is passed to all of them

beta_calculator_TK->addInfoToCandidate(*hscpcandidate,  iEvent,iSetup);
beta_calculator_MUON->addInfoToCandidate(*hscpcandidate,  iEvent,iSetup);
beta_calculator_RPC->addInfoToCandidate(*hscpcandidate,  iEvent,iSetup);
beta_calculator_ECAL->addInfoToCandidate(*hscpcandidate,  iEvent,iSetup);

-> Here we have some L1 trigger part, to save to get Eff L1 with selection

-> changed multiple, but some handles don't use _product() (like tkGeom ?)

-> No product aswell for RPC Geom ? rpcGeom used in multiple functions, redeclaration of rpcGeo using the token, or declaring it as private member ? (risk of non initialization ? )

Fix -> Redeclaration using the same cstrct token

Changes : Passing iSetup to makeSimDigiPlotsRPC, since we consume the token even pre-constructor, and he Handle is no longer in the data members (the token it though)

-> Problems with tTopoToken, same change as before but different error

In file included from /grid_mnt/opt__sbg__cms__ui5_data1/rhaeberl/CMSSW_12_3_0_pre4/src/SUSYBSMAnalysis/Analyzer/plugins/
/grid_mnt/opt__sbg__cms__ui5_data1/rhaeberl/CMSSW_12_3_0_pre4/src/SUSYBSMAnalysis/Analyzer/plugins/Analyzer.h:203:62: error:   'const edm::ESGetToken<TrackerTopology, TrackerTopologyRcd> Analyzer::tTopoToken_' [-Werror=reorder]
  203 |   const edm::ESGetToken<TrackerTopology, TrackerTopologyRcd> tTopoToken_;

Fixed -> Problem occured due to the lack of esConsumes declaration prior to this (dissapeared when ConsumesCollector.h + ic.esConsumes were changed)


Big changes

1.Red led GenEvent.h is missing, should be replaced

Fact : The whole hepMC was rewritten for the new release. A lot of changes are expected, see sub-section HepMC (not needed for step 0/1 I think, for now..)

We see here every link between GenEvent.h and other classes >

Checking the HepMCPRoduct.h from different releases, noticing a few differences

10_6_20 : 12_3_X :

Contacted Joanna Weng and Filip Moortgat.

Error code :

In file included from /cvmfs/,
                 from /grid_mnt/opt__sbg__cms__ui5_data1/rhaeberl/CMSSW_12_3_0_pre4/src/SUSYBSMAnalysis/CalibNtuplizer/plugins/
/cvmfs/ fatal error: HepMC/GenEvent.h: No such file or directory
   11 | #include <HepMC/GenEvent.h>

2.Green led When scram b -j8 : Warning, Invalid tool SimTrackers/Records. Please fix src/SUSYBSMAnakysis/MuonTiming/BuildFile.xml

Solution remove the following line from BuildFile.xml

<use   name="SimTracker/Records"/> 

3.Yellow led esConsumes() not declared ?

Solution : esConsumes was added in release 11_0_X, but the way it was done in the PR ( ) might be different. The definition must be somewhere, but didn't find it yet

FIX IN PROGRESS : BuildFile.xml has the FWCore included, and ConsumesCollector.h comes directly from FWCore/interface. Add the subdirectories in here once found

Need help for fixing that

/grid_mnt/opt__sbg__cms__ui5_data1/rhaeberl/CMSSW_12_3_0_pre4/src/SUSYBSMAnalysis/HSCP/src/ In constructor 'BetaCalculatorECAL::BetaCalculatorECAL(const edm::ParameterSet&, edm::ConsumesCollector&&)':
/grid_mnt/opt__sbg__cms__ui5_data1/rhaeberl/CMSSW_12_3_0_pre4/src/SUSYBSMAnalysis/HSCP/src/ error: 'esConsumes' was not declared in this scope
   25 |   bFieldToken_(esConsumes<MagneticField, IdealMagneticFieldRecord>()),

Solution Yellow led Tried many things, what works well is the following :

CaloTopologyToken_(iC.esConsumes<CaloTopology, CaloTopologyRecord>())

4.Green led error: no matching function for call to 'TrackDetectorAssociator::getFreeTrajectoryState(const edm::EventSetup&, reco::Track&) trackAssociator_.getFreeTrajectoryState(iSetup, track)

not wrong (changed but would work) here we see the 3 ways we can call getFreeTrajectoryState, none takes iSetup as an input ?

FIX > between release 10_6_X and 12_3_X, getFreeTrajectoryState was modified and the input parameters it took before were changed. This function is called in for instance. See the chain call

In (156)

Also uses the function, but magnetic field is not available there. Addition of classes/includes/tokens to make it work


Change file HSCP/plugins/ line 206 :


TrackDetMatchInfo info = trackAssociator_.associate(iEvent, iSetup, trackAssociator_.getFreeTrajectoryState(iSetup, *itTrack), parameters_);


TrackDetMatchInfo info = trackAssociator_.associate(iEvent, iSetup, trackAssociator_.getFreeTrajectoryState(&iSetup.getData(bFieldToken_), *itTrack), parameters_);

5.Yellow led -> need to replace for run 3 ?

6.Yellow led SiStripModuleGeometry but not concerned for HSCParticle Producer. Might want to check this out if we want the Analyzer on 12_3_X

/grid_mnt/opt__sbg__cms__ui5_data1/rhaeberl/CMSSW_12_3_0_pre4/src/SUSYBSMAnalysis/Analyzer/interface/CommonFunction.h:992:46: error: cannot convert 'SiStripModuleGeometry' to 'int' in initialization
  992 |   int moduleGeometry = SSdetId.moduleGeometry();
      |                        ~~~~~~~~~~~~~~~~~~~~~~^~
      |                                              |
      |                                              SiStripModuleGeometry

After fixing initial issues

1.Yellow led LaunchOnCondor

*** Error compiling 'src/SUSYBSMAnalysis/HSCP/python/'...
  File "src/SUSYBSMAnalysis/HSCP/python/", line 60
    print 'LaunchOnCondor [options]'
SyntaxError: Missing parentheses in call to 'print'. Did you mean print('LaunchOnCondor [options]')?

This script was made by Loic a long time ago, hide it and everything compiles fine (renamed LaunchOnCondor.pynocomp)

Running Step 0 and Step 1

Changes to

1)FrontierConditions GT

Green led

ModuleNotFoundError: No module named 'Configuration.StandardSequences.FrontierConditions_GlobalTag_condDBv2_cff'

  /cvmfs/ load <module>

-> Fix : Find the right module :

Inspired from >

changed L52 :


and L74-75

from Configuration.AlCa.GlobalTag_condDBv2 import GlobalTag
process.GlobalTag = GlobalTag(process.GlobalTag, options.GTAG, '')
from Configuration.AlCa.GlobalTag import GlobalTag
process.GlobalTag = GlobalTag(process.GlobalTag, '123X_mcRun3_2021_realistic_v4')

2)itervalues (no idea why it is here)

Yellow led

----- Begin Fatal Exception 18-Feb-2022 16:21:54 CET-----------------------
An exception of category 'ConfigFileReadError' occurred while
   [0] Processing the python configuration file named
Exception Message:
 unknown python problem occurred.
AttributeError: 'FixedKeysDict' object has no attribute 'itervalues'

At: <module>

Fix :

-> Changes in the config file (

dict.itervalues() was removed from Python3, use instead dict.values()

#187 and #189

for mod in process.producers_().values():

The migration is complete, and the HSCParticleProducer compiles

3)Lack of TriggerResults::HLT leads to nonsense results

Yellow led

When running the code, new error to fix

%MSG-e HLTHighLevel:  HLTHighLevel:HSCPTrigger 21-Feb-2022 15:57:17 CET  Run: 1 Event: 500
TriggerResults product TriggerResults::HLT not found - returning result=false!

Wrong Fix (but still important) : -> Added the collections inside

# Input source
process.source = cms.Source("PoolSource",
    fileNames = cms.untracked.vstring('file:mitL1/hltOutput_withL1_DIGIrun3.root'),
    inputCommands = cms.untracked.vstring(
        'keep *'
    secondaryFileNames = cms.untracked.vstring()

The inputCommands (line 4) was not there initially, and that was causing the issue

Right fix

From HLT to HLTX

process.HSCPTrigger.TriggerResultsTag = cms.InputTag( "TriggerResults", "", "HLTX" )


Yellow led

Begin processing the 1st record. Run 1, Event 1, LumiSection 1 on stream 0 at 22-Feb-2022 11:24:11.346 CET
----- Begin Fatal Exception 22-Feb-2022 11:24:22 CET-----------------------
An exception of category 'MustUseESGetToken' occurred while
   [0] Processing  Event run: 1 lumi: 1 event: 1 stream: 0
   [1] Running path 'HSCPTuplePath'
   [2] Calling method for module MuonSegmentProducer/'MuonSegmentProducer'
Exception Message:
Called EventSetupRecord::get without using a ESGetToken.
 While requesting data type:DTGeometry label:''
for instructions how to migrate the calling code
----- End Fatal Exception -------------------------------------------------
Another exception was caught while trying to clean up files after the primary fatal exception.

Fix : -> Changed ESHandle dtGeeom and cscGeom

The whole step 0 was migrated towards CMSW_12_3_X, compiles and results are coherent with expectencies

Related informations I found online (Migrate modules for the use of esConsumes) (general SW framework guide, very dense)


Big thanks to Tamas Almos Vami for answering a lot of my questions and helping out on this

Custom step 1

Once step 0 done, one needs to do the reconstruction on the HSCP candidates, to then access the values of L1 seeds efficiencies aswell as HLT paths, with the given selection (see table 1 below)

Either : Make new EDAnalyzer from scratch, or run step 1 ?

Change 1 > L.22 put HLTX to be consistent with the prior changes

,triggerResults = cms.InputTag("TriggerResults","","HLTX")

Change 2 > L.33-36

,TypeMode        = cms.untracked.uint32(0) # 0:Tk only, 1:Tk+Muon, 2:Tk+TOF, 3:TOF onlypwd, 4:Q>1, 5:Q<1
    ,SampleType      = cms.untracked.uint32(0) # 0:Data, 1:Background, 2:Signal, 3:Signal Systematics
    ,SampleName      = cms.untracked.string("BaseName")
    ,Period          = cms.untracked.string("2016")

Color code

Green led = problem is fixed and I am confident in the fix

Yellow led = problem is fixed but the solution needs review

Red led = problem has no solution yet

Gray led = warning but no errors

-- Main.RaphaelJulienHaberle - 2022-02-13

Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r16 - 2022-02-22 - RaphaelJulienHaberle
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback