cmssw: Simulation-Reconstruction chains not working for Run3 scenario using dd4hep

None of the steps SIM-DIGI-RECO is functional currently with dd4hep geometry definition. The area SimG4Core/Configuration/test is equipped with 7 cfg files which can help to resolve the issue: dd4hep_ZMM_Run3_StepN_cfg.py provides the configurations for Run3 with dd4hep for SIM (N=1), DIGI (N=2), RECO (N=3) Since none of these steps are completing satisfactorily, the corresponding cfg’s with DDD are also provided as ddd_ZMM_Run3_StepN_cfg.py The seventh cfg is for step1 of a Phase2 run scenario

Error message from Step1: %MSG-w TkAccumulatingSensitiveDetector::createHit: OscarMTProducer:g4SimHits 04-Aug-2020 14:45:25 CEST Run: 1 Event: 1 theDetUnitId is not valid for TrackerHitsTEC %MSG ----- Begin Fatal Exception 04-Aug-2020 14:45:25 CEST----------------------- An exception of category ‘TkAccumulatingSensitiveDetector::createHit’ occurred while [0] Processing Event run: 1 lumi: 1 event: 1 stream: 0 [1] Running path ‘FEVTDEBUGoutput_step’ [2] Prefetching for module PoolOutputModule/‘FEVTDEBUGoutput’ [3] Calling method for module OscarMTProducer/‘g4SimHits’ Exception Message: cannot get theDetUnitId for G4Track 5262 ----- End Fatal Exception -------------------------------------------------

Error message from Step2: ----- Begin Fatal Exception 04-Aug-2020 15:03:30 CEST----------------------- An exception of category ‘NoProxyException’ occurred while [0] Running EventSetup component DTGeometryESModule/’ Exception Message: No data of type “DDCompactView” with label “” in record “IdealGeometryRecord” Please add an ESSource or ESProducer to your job which can deliver this data. ----- End Fatal Exception -------------------------------------------------

Error message from Step3: cmsRun: /data/cmsbld/jenkins/workspace/build-any-ib/w/tmp/BUILDROOT/1d6ef0028b473072ff15e3d6bc5122f8/opt/cmssw/slc7_amd64_gcc820/cms/cmssw/CMSSW_11_2_X_2020-08-03-2300/src/Geometry/TrackerGeometryBuilder/src/TrackerGeometry.cc:67: TrackerGeometry::TrackerGeometry(const GeometricDet*): Assertion `subdetgd[i]->geographicalId().subdetId() > 0 && subdetgd[i]->geographicalId().subdetId() < 7’ failed.

Please note: (1) The job fails on encountering the first error. Till these are resolved we may not find other hidden errors (2) Inputs for testing step2 or step3 are produced using the DDD examples

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 31 (31 by maintainers)

Most upvoted comments

@vargasa @mmusich The looping over fv’s are totally different between DDD and DD4Hep. The best way to loop over fv’s in dd4hep is to use the loop while (fv.firstChild()) { } and not to use any other operation on fv by going up/down/next. I had to take care of this for some muon detectors. If you want I can take a look into this.

Hi all, from a previous private discussion:

@ghugo83 pointed out that these errors may be seen because of overlaps still present in CMS geometry (not necessarily in the tracker, the remaining overlap issues with the tracker were solved back in April).

From the same discussion @bsunanda commented:

A large fraction of those 1330 overlaps - 990 are due to overlap of the volume elements (SFBX/SFBY) of preshower detector extruded from teir mother volume. These elements are mother of the sensitive detectors (SFSX/SFSY).

From @rchatter:

The last time we checked this our understanding was that there was no overlap in any of the active elements. Then related to the PreShower in the context of the Boolean solids we agreed not to re-look at the code largely due to the fact that this subdetector would be replaced for HL-LHC.

@bsunanda , @rchatter, @cvuosalo, @civanch, from that discussion it is not clear to me if those issues were addressed. Can you please briefly comment/confirm the present issue is not related with that anymore?