Trigger Paths for Alignment and Calibration for LHC Run 2 - 2017

Introduction

List of mandatory streams // datasets // paths

Stream	Dataset	Path	Notes
ALCALUMIPIXELS	AlCaLumiPixels	AlCa_LumiPixels_Random
ALCALUMIPIXELS	AlCaLumiPixels	AlCa_LumiPixels_ZeroBias
ALCAPHISYM	AlCaPhiSym	AlCa_EcalPhiSym
Calibration	TestEnablesEcalHcal	HLT_EcalCalibration	Will change name soon, see https://hypernews.cern.ch/HyperNews/CMS/get/tier0-Ops/1623/1.html
Calibration	TestEnablesEcalHcal	HLT_HcalCalibration	Will change name soon, see https://hypernews.cern.ch/HyperNews/CMS/get/tier0-Ops/1623/1.html
DQMCalibration	TestEnablesEcalHcalDQM	HLT_EcalCalibration
DQMCalibration	TestEnablesEcalHcalDQM	HLT_HcalCalibration
EcalCalibration	EcalLaser	HLT_EcalCalibration
Express	Express	HLT_Random
Express	Express	HLT_ZeroBias
Express	Express	HLT_ZeroBias_FirstCollisionAfterAbortGap
ExpressAlignment	ExpressAlignment	HLT_HT300_Beamspot
ExpressAlignment	ExpressAlignment	HLT_HT450_Beamspot
RPCMON	RPCMonitor	AlCa_RPCMuonNormalisation

Rate of ZeroBias events

Rate of L1_Random accepts

Definition of the Express Dataset

For 2017 we also have the ExpressAlignment dataset:

JIRA tickets

• This filter should let you see all AlCa tickets: https://its.cern.ch/jira/issues/?filter=21701

Spectacular events

Not added in 2017 for the time being.

Trigger paths in CondDB

See https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideAlCaRecoTriggerBits

Input from DPG/s POGs

Beamspot

• From now will use the highest sum pT vertex in JetHT events; apply further (sum pT and number of tracks) quality requirements.
• A benchmark: 2000 vertices for the measurement, every LS. Using JetHT this turns out to be approx ~ 100 Hz.
• Alternative idea: create a separate stream/dataset
  • This was implemented in the ExpressAlignment dataset, see above.
• Complementary idea: integrate over > 1 LS
  • (To follow up if this was implemented)

• Reference: https://indico.cern.ch/event/592618/contributions/2473614/attachments/1419851/2175472/beamspot_alca_workshop_28_2_2017.pdf

Last updated: 2017-06-26

Tracker

• TkAl is still unclear, single slide about it. Will provisionally copy 2016 information
• Pixel doesn't use AlCaReco, but they use MuOnia for LA and Template/GenErr studies and ZeroBias RAW dataset for Timing/HV/SiPixelQuality
• Possibly want larger mass window in Upsilon ALCARECO
• Possibly revive BeamHalo ALCARECOs
• * SiStripCalMinBias needs to be run on the ZeroBias PD in Prompt Reco instead that HLTPhysics * (M.M. 2017-04-11)

Last updated: 2017-03-31
Reference: https://indico.cern.ch/event/592618/contributions/2473569/attachments/1419628/2174996/Alcaworks_PCLAlcareco_GB.pdf

ECAL

ALCARECO	Primary Dataset	Paths	ALCARECO rate	Data-taking phase	Notes
EcalUncalElectron	SingleElectron, DoubleElectron	EGM reconstruction is not ready yet. Should be the usual "isolated electron" paths and something special for the ZSC	As per the PD	Always	Used for ECAL fast rerecos (ECALELF) for validation of conditions
EcalESAlign	SingleElectron	See above	What rate?	Always	Used for ES alignment and ES MIP calibration
EcalTrg	AlCaPhiSym	AlCa_EcalPhiSym	(see below)	On demand of few runs (5-6)	Used for trigger studies
N/A	AlCaPhiSym	CMSHLT-1245	10 kHz	Startup	Simone Pigazzini
N/A	AlCaPhiSym	CMSHLT-1245	3 kHz	Reg. Ops	Simone Pigazzini
N/A	AlCaPi0, AlCaPiEta	CMSHLT-1246	15 kHz per path	Startup	Marco Cipriani
N/A	AlCaPi0, AlCaPiEta	CMSHLT-1246	7 kHz per path	Reg. Ops	Marco Cipriani
N/A	TestEnablesEcalHcal, TestEnablesEcalHcalDQM, EcalLaser	HLT_EcalCalibration	100 Hz	Always	Always in
EcalUncalZSCElectron	DoubleEG	HLT_Ele28_HighEta_SC20_Mass55	1 Hz	Always	Sean Kalafut, CMSHLT-1310

Incoming: PromptCalibProdEcalPedestals (check https://hypernews.cern.ch/HyperNews/CMS/get/tier0-Ops/1623.html )

Last updated: 2017-07-19
Reference: https://indico.cern.ch/event/592618/contributions/2473575/attachments/1419263/2174916/20170228_ECAL_ALCA_ALCARECO.pdf
(but what is meant by last line of table of slide 7? L1SingleEG (tbd) | all available | Electron stream | 120 kB | 100 Hz )
Reference: https://indico.cern.ch/event/636116/contributions/2578755/attachments/1453281/2241758/03-05-17_TSG_slides.pdf
Reference: https://indico.cern.ch/event/636116/contributions/2578757/attachments/1453326/2242013/Pi0Stream_TSGmeeting_03May2017_v2.pdf
Reference (trackless electron): https://its.cern.ch/jira/secure/attachment/122191/122191_rate_and_efficiency_estimate_trackless_doubleEle_HLT_May_2017_v2.pdf

* Still to be discussed: Electron stream W path, to collect at least as many Ws as in 2916

HCAL

Last updated: 2017-07-17
Reference: https://docs.google.com/spreadsheets/d/1UoxkH2QrpSAEkmLvEtkI1JvcVFy4gkDV-_k4roKllTY/edit#gid=0
Reference: https://indico.cern.ch/event/592618/contributions/2473577/attachments/1419368/2174373/hcal270217.pdf
Reference: https://indico.cern.ch/event/647309/contributions/2633231/attachments/1479768/2295645/IsoTrackN36.pdf

Muon

• Contacts
  • Muon Alignment: Luca Pernie (outgoing), Daniel Marley
  • CSC: Tim Cox, Indara Suarez (CSC DPG)
  • DT: Francesca Romana Cavallo (DT DPG)
  • RPC: Roumyana Mileva Hadjiiska (RPC DPG)
  • GEM: Cesare Calabria

Free-form information for the time being, to be updated

• DT

In order to effectively monitor the DT performance we need (as in the past) > 3Hz of good barrel muons (>15 GeV) to be recorded in the Express Stream. For standard pp collisions last year we had: HLT_IsoMu20(24) + HLT_Mu17_TrkIsoVVL_Mu8_TrkIsoVVL_DZ whose total rate was computed to be ~10 Hz and was perfectly OK. With 0 bias or Min Bias, a SingleMuon eta restricted could help to increase our statistics but I don't know which rates can be expected and therefore which thresholds should be set.

Note: the same data used for monitoring are also good for calibration, with a similar time scale (few hours).

• CSC

• RPC

We would need to have any SingleMuon or DoubleMuon path included in the Express Streams during the pp collisions. Clearly the paths should be unprescaled and with the lowest pT threshold as possibile. A 3Hz rate (better 5Hz ) would be enough for us for monitoring purposes, so if the startup condition are the same as last year, you can just copy/paste the HLT_SingleMu and HLT_DoubleMu paths used in 2016 menu.

Obviously, in addition, we would like to have also the RPCMon stream included.

ThiagoTomei - 2017-05-16

LUMI and BRIL

Need more feedback from them!

ALCARECO	Primary Dataset	Paths	ALCARECO rate	Data-taking phase	Notes
ALCALUMIPIXELS	ALCALUMIPIXELS	AlCa_LumiPixels_ZeroBias_v5 , AlCa_LumiPixels_Random_v2	1700 Hz, 400 Hz	Always	https://its.cern.ch/jira/browse/CMSHLT-1393
AlCaPCCZeroBias	ALCALUMIPIXELS	AlCa_LumiPixels_ZeroBias_v5	1700 Hz	Always	https://its.cern.ch/jira/browse/CMSHLT-1393
AlCaPCCRandom	ALCALUMIPIXELS	AlCa_LumiPixels_Random_v2	400 Hz	Always	https://its.cern.ch/jira/browse/CMSHLT-1393

Last updated: 2017-06-20
https://github.com/cms-sw/cmssw/pull/18813
Reference: https://indico.cern.ch/event/592618/contributions/2473613/attachments/1419773/2175174/PCCAutomation_3.pdf
Reference: https://indico.cern.ch/event/592618/contributions/2482915/attachments/1419846/2175297/2017_02_28_AlCaDB_Workhsop_Z_Counting.pdf
Reference: https://indico.cern.ch/event/626461/contributions/2549759/attachments/1442712/2221775/PCCAuto_10042017.pdf

TSG documentation for L1/HLT menus

L1 menus

• https://twiki.cern.ch/twiki/bin/viewauth/CMS/GlobalTriggerMenu_L1Menu_Dev2017_v1

Tier-0 information

• Versioned configuration: https://github.com/dmwm/T0/blob/master/etc/ProdOfflineConfiguration.py
• Live configuration: http://cmst1.web.cern.ch/CMST1/tier0/ProdOfflineConfiguration.py
• First Conditions Safe Run: https://cmsweb.cern.ch/t0wmadatasvc/prod/firstconditionsaferun
• Tier-0 policies: https://twiki.cern.ch/twiki/bin/view/CMSPublic/CompOpsTier0Policies

Preliminary monitoring page (TODO)

Summary of Conditions Change at HLT

Moved to: https://twiki.cern.ch/twiki/bin/view/CMS/TriggerStudiesConditionsInDataTaking2017

Rerun HLT on data with updated condition(s) with respect to online GT

Updated beamspot on run 300806

Updated beamspot on run 300806 Hide

process.GlobalTag.toGet.append(
  cms.PSet(
    record = cms.string("BeamSpotObjectsRcd"),
    tag = cms.string("BeamSpotObjects_byLS_031c09_TEST"),
    connect = cms.string("frontier://FrontierPrep/CMS_CONDITIONS")
  )
)

Tracker alignment using week 32 update

Tracker alignment using week 32 update Hide

List of conditions touched by each step

Unformatted material

Hi Giovanni,
the module is the PoolDBESSource, and this feature is activated by setting:
DumpStat = cms.untracked.bool(True)
In cmsDriver, this translates into:
--customise_commands='process.GlobalTag.DumpStat = cms.untracked.bool(True)

There is also another couple of modules that can help you:
process.escontent = cms.EDAnalyzer( "PrintEventSetupContent",
                                    compact = cms.untracked.bool( True ),
                                    printProviders = cms.untracked.bool( True )
                                   )

process.esretrieval = cms.EDAnalyzer( "PrintEventSetupDataRetrieval",
                                      printProviders = cms.untracked.bool( True )
                                     )
You can put them in the end path in order to inspect the ES contents:
process.esout = cms.EndPath(process.escontent + process.esretrieval)
if process.schedule_() is not None:
    process.schedule_().append(process.esout)

for name, module in process.es_sources_().iteritems():
    print "ESModules> provider:%s '%s'" % (name, module.type_())
for name, module in process.es_producers_().iteritems():
    print "ESModules> provider:%s '%s'" % (name, module.type_())


This was set-up by Andrea, Javier and I some time ago.

HTH

S.

• AlCaTSGContactsMandate

Conditions used for each TSG MonteCarlo production:

• https://twiki.cern.ch/twiki/bin/viewauth/CMS/TriggerStudiesPhaseIFall16DR
• https://twiki.cern.ch/twiki/bin/viewauth/CMS/TriggerStudiesRunIISummer16DR80
• https://twiki.cern.ch/twiki/bin/viewauth/CMS/SpecialGlobalTagsForTSG2017
• https://twiki.cern.ch/twiki/bin/viewauth/CMS/SpecialGlobalTagsForTSG

Initial considerations

ECAL alignment

If you want the full explanation of the ECAL alignment procedure, I would suggest to have a look at the DN 2015/026 [1]. Old, but still valid in terms of methodology.

The problem now is that we opened the Endcaps during EYETS2016, as we did in EYTS2015. From last year experience the Barrel is not affected, and that is why we think that also this year the Barrel startup conditions that we put online are a good approximation of what we will measure after ~500/pb of data.
For the Endcap, since it was opened, the business remains: when you open and close, you are not 100% sure you will end up in the same position, due to mechanical stress. The alignment there is very needed.
As a proxy to understand what is the level of disagreement we expect, we can take the difference between the tag at the end of 2015 and the aligned tag of 2016 (what I called "after we aligned in July 2016"). However, to be more conservative, we can use as a proxy the tag of 2016 itself, meaning the difference between the ideal position and the "2016 position". It seemed to me we were in a hurry to have an estimation of possible effects on objects reconstruction at HLT, and this is what we could provide in few hours promptly. If you need for example the difference between 2015 and 2016, it may take some more time (also given the holiday period ...).
However, we are talking about order of magnitude here, in order to test the effect on HLT you need to have the bulk effect of the mis-alignment, you cannot optimize any path selections on a misaligned scenario (you can only relax cuts not to be affected). In addition, we changed pixels too this year ...I wouldn't go too tight on the selections (but I have not been following pixel/tracker operations in P5).
Maybe one of the confusions here is that ECAL is an almost rigid body (differently from the tracker), and while for tracker one effect is the relative alignment of the layers, then it can be mimicked by a smearing, for ECAL the effect is a systematic bias due to a shift.

I hope this explains and sheds some light on the procedure and why I think the "data 2016 tag" is a good proxy of "how much we don't know at startup" in terms of position.

One additional thing, we will probably have sooner the Preshower alignment (since it relies on simple tracks) and this could give us a new "order of magnitude" about how much the position changed between 2015 and 2016.

Pixel

As the first large production of MC samples for 81x is being finalized [1], we've realized that one upgraded pixel condition, 
the Pixel FED cabling map, (as included in the presently available and validated phase-I MC Global Tag) doesn't reflect the 
state-of-the-art of the knowledge of the detector being assembled. A newer more realistic version has been made available 
but unfortunately not included in time to be validated for the (long awaited) 810 release.
Now, since we don't have contingency to re-validate the new conditions, it seems likely that GEN-SIM-RAW samples with this version of the conditions will be produced.
This - per se - is not a problem, since the same map is consistently applied back and forth in the digi2raw and raw2digi steps, so within a given campaign the effect is null.
Nonetheless, across campaigns and across releases, one might need to be careful with digitization of these RAW samples, since we foresee to move soon in 90x to use the newer more updated version.
Having this being said, I don't know what plans the TSG group has with the RAW data produced now with 810, but you should keep in mind that if TSG plans to re-digitize them later on, 
we'll need a compatibility Global Tag, very much as we did this year for the 76x to 80x transition.
Since the 81X samples are not yet injected, I am not yet asking you to build the compatibility queue and advertise the situation at TSG coordination meeting, but please keep this heads-up in mind.
We'll keep you in the loop if/when further actions will be needed.

[1] https://hypernews.cern.ch/HyperNews/CMS/get/prep-ops/3475.html

One additional note: it may be very well possible the L1T content will change in 80x with respect to 90x.
We'll find this out in the coming weeks, once 90x will get closer to closing. If that'll be the case, there'll be a second and 
easier-to-remember reason why the compatibility queue Marco refers to will be needed.

ALCA tests

git cms-addpkg CondTools/HLT
git clone git@github.com:cms-AlCaDB/AlCaTools.git
hltGetConfiguration /dev/CMSSW_9_2_0/GRun/V131 > hlt.py
Get l1prescales.xml from TSG tools

ThiagoTomei - 2017-12-15