Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XeXe collision era and relval workflow #20749

Merged
merged 18 commits into from Oct 9, 2017

Conversation

mandrenguyen
Copy link
Contributor

Customizes the pp reconstruction to keep timing in check.
To be used for XeXe data taking on October 12th (92X version).
Adds a relVal worklow to test (148)
Supersedes #20715

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 5, 2017

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 5, 2017

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/PR-20749/1160

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 5, 2017

A new Pull Request was created by @mandrenguyen (Matthew Nguyen) for master.

It involves the following packages:

Configuration/Eras
Configuration/Generator
Configuration/PyReleaseValidation
Configuration/StandardSequences
DQMOffline/Configuration
HLTriggerOffline/Common
RecoEcal/Configuration
RecoEgamma/Configuration
RecoEgamma/EgammaPhotonProducers
RecoJets/Configuration
RecoParticleFlow/Configuration
RecoParticleFlow/PFTracking
RecoPixelVertexing/PixelTriplets
RecoTauTag/Configuration
RecoTracker/ConversionSeedGenerators
RecoTracker/IterativeTracking
RecoTracker/TkSeedGenerator
RecoVertex/AdaptiveVertexFinder
RecoVertex/Configuration
Validation/Configuration

@perrotta, @prebello, @vazzolini, @dmitrijus, @kmaeshima, @civanch, @perrozzi, @efeyazgan, @kpedro88, @fabozzi, @cmsbuild, @GurpreetSinghChahal, @franzoni, @thuer, @slava77, @mdhildreth, @vanbesien, @govoni, @davidlange6 can you please review it and eventually sign? Thanks.
@ghellwig, @TaiSakuma, @felicepantaleo, @jainshilpi, @rappoccio, @argiro, @Martin-Grunewald, @ahinzmann, @threus, @varuns23, @seemasharmafnal, @mmarionncern, @imarches, @makortel, @acaudron, @lgray, @jdolen, @ferencek, @rociovilar, @Sam-Harper, @GiacomoSguazzoni, @rovere, @VinInn, @jdamgov, @nhanvtran, @gkasieczka, @schoef, @mschrode, @ebrondol, @mtosi, @dgulhan, @swertz, @JyothsnaKomaragiri, @mverzett, @cbernet, @gpetruc, @mariadalfonso, @pvmulder, @bachtis this is something you requested to watch as well.
@davidlange6, @slava77 you are the release manager for this.

cms-bot commands are listed here

peripheralPbPb.toModify(PixelTripletLargeTipGenerator, maxElement = 1000000)
from Configuration.Eras.Modifier_pp_on_XeXe_2017_cff import pp_on_XeXe_2017
for e in [peripheralPbPb, pp_on_XeXe_2017]:
e.toModify(PixelTripletLargeTipGenerator, maxElement = 1000000)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Modifications in this file have no effect for pp reco (though consistency doesn't hurt until this file gets cleaned up).

useFoundVertices = True,
originRadius = 1.5
))
)
Copy link
Contributor

@makortel makortel Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This block (or most of it) is copy-pasted along the concerned files. Would it be possible to have one definition somewhere and use that in toReplaceWith() calls?

useFoundVertices = True,
originRadius = 1.5
))
)
Copy link
Contributor

@makortel makortel Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mostly copy-paste

ptMin = 0.6,
useFoundVertices = True,
originRadius = 0.02
))
Copy link
Contributor

@makortel makortel Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mostly copy-paste

)
)

pp_on_XeXe_2017.toReplaceWith(firstStepPrimaryVerticesUnsorted.TkClusParameters, _pp_on_XeXe_2017_TkClusParameters)
Copy link
Contributor

@makortel makortel Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please change to

pp_on_XeXe_2017.toModify(firstStepPrimaryVerticesUnsorted,
    TkFilterParameters = dict(maxD0Significance = 3.0),
    TkClusParameters = cms.PSet(
        algorithm = cms.string("gap"),
        TkGapClusParameters = cms.PSet(
            zSeparation = cms.double(1.0)        
        )
    )
)

useFoundVertices = True,
originRadius = 0.02
))
)
Copy link
Contributor

@makortel makortel Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mostly copy-paste

useFoundVertices = True,
originRadius = 0.02
))
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mostly copy-paste

@davidlange6
Copy link
Contributor

please test

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2017

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-20749/23548/summary.html

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 0 differences found in the comparisons
  • DQMHistoTests: Total files compared: 26
  • DQMHistoTests: Total histograms compared: 2761427
  • DQMHistoTests: Total failures: 231
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2761009
  • DQMHistoTests: Total skipped: 187
  • DQMHistoTests: Total Missing objects: 0
  • Checked 107 log files, 10 edm output root files, 26 DQM output files

@civanch
Copy link
Contributor

civanch commented Oct 8, 2017

+1

@davidlange6
Copy link
Contributor

hi @slava77 @perrotta @mandrenguyen - is this and its 92x back port nearly ready to go?

@mandrenguyen
Copy link
Contributor Author

mandrenguyen commented Oct 8, 2017 via email

@perrotta
Copy link
Contributor

perrotta commented Oct 8, 2017

@davidlange6 : this is ok for me, as well as the 92X backport

@davidlange6
Copy link
Contributor

merge

@cmsbuild cmsbuild merged commit 980a7c7 into cms-sw:master Oct 9, 2017
@mandrenguyen
Copy link
Contributor Author

@slava77 I ran 100 events starting from GEN-SIM in 9_2_13. On a 2 GHz machine I'm only clocking in at 20 sec/event. We'll have to create a huge number of PDs to accomodate the 60 sec/evt, so it's important to understand which is more accurate. Is there something missing from my approach?
I simply ran the following driver, adding only process.Timing = cms.Service("Timing")

step3 --runUnscheduled --conditions auto:phase1_2017_realistic -s RAW2DIGI,L1Reco,RECO,EI,PAT --datatier GEN-SIM-RECO,MINIAODSIM -n 2 --era Run2_2017_pp_on_XeXe --eventcontent RECOSIM,MINIAODSIM --filein /store/user/mnguyen//hydjetDrum5_XeXe_MB_921p12/hydjetDrum5_XeXe_MB_921p12/crab_Hydjet_Quenched_MB_XeXe_5442GeV_DIGI_9212p1/171009_174655/0000step2_DIGI_L1_DIGI2RAW_HLT_1.root --no_exec

@davidlange6
Copy link
Contributor

davidlange6 commented Oct 10, 2017 via email

@davidlange6
Copy link
Contributor

davidlange6 commented Oct 10, 2017 via email

@mtosi
Copy link
Contributor

mtosi commented Oct 10, 2017 via email

@mandrenguyen
Copy link
Contributor Author

@davidlange6 So you removed the PAT step? I initially had that removed, but then we put back mini-AOD and the associated DQM in case it's being produced. You can see that I have that in my driver, and i'm still getting timing close to yours.

@davidlange6
Copy link
Contributor

davidlange6 commented Oct 10, 2017 via email

@davidlange6
Copy link
Contributor

davidlange6 commented Oct 10, 2017 via email

@slava77
Copy link
Contributor

slava77 commented Oct 10, 2017 via email

@mandrenguyen
Copy link
Contributor Author

@slava77 I processed every one of those events, and those were all that were GS'd. So there is no "smaller files finish first" issue.

@slava77
Copy link
Contributor

slava77 commented Oct 10, 2017 via email

@slava77
Copy link
Contributor

slava77 commented Oct 10, 2017

I see that the recent checks were made in CMSSW_9_2_13.
My tests were in 9_4_0_pre2.
Could differences in generator lead to some change in output particle occupancies?

@mandrenguyen
Copy link
Contributor Author

I still see slightly more than a factor of 2 larger CPU time compared to wf 10224.0, which is just north of 20 sec/event on my 2 GHz machine. I see no large difference running in the 94X IB, compared to 9213. I have confirmed that I see events with reconstructed tracks up to O(10000), the highest being about 7,000 tracks in my sample.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants