Open RSalvatico opened 8 months ago
cms-bot internal usage
A new Issue was created by @RSalvatico Riccardo Salvatico.
@Dr15Jones, @rappoccio, @sextonkennedy, @antoniovilela, @smuzaffar, @makortel can you please review it and eventually sign/assign? Thanks.
cms-bot commands are listed here
assign upgrade, pdmv
New categories assigned: upgrade,pdmv
@AdrianoDee,@sunilUIET,@miquork,@srimanob,@subirsarkar you have been requested to review this Pull request/Issue and eventually sign? Thanks
Hi @RSalvatico
We have .101 (e.g. 24834.101 for ttbar nopu D88 with aging) to apply for 1000 fb-1.
This issue was brought to the discussion in the SIM meeting on 2022-02-11, see https://indico.cern.ch/event/1127757/contributions/4733494/attachments/2389568/4085879/20220211-Phase2SWPlan.pdf (slide 9)
The conclusion from that time was to keep 0 fb-1 for .0 and keep relvals with aging 1000 fb-1. For sure, we can bring back the discussion. It seems there are 2 possible ways, (1) Move PR test as config as relvals (i.e. move .0 to aging, or call .101 on PR test). I prefer we choose one (0 fb-1, or 1000 fb-1) for PR test, to avoid the overload of testing scenario. (2) Call .101 test when related PR comes. If I remember correctly, if you call additional workflow, we will have comparison of that workflow also (i.e. ref = w/o PR, new = ref + PR).
Please let us know if you would like to discuss. This can be a topic in SIM meeting. FYI @civanch
Hi @srimanob,
Thanks for the explanation and for the archeology :)
Option 1) does not seem completely satisfactory to me, since in any case there will be ageing scenarios that will be covered by the relvals and not by the PR tests. My understanding is that relvals run both 0 fb-1 (for noPU) and 1000 fb-1 (for PU200) scenarios.
Option 2) seems better. I'm not sure what the technicalities would be though.
Hi, we run the 1000 $fb^{-1}$ for both noPU and PU RelVals for Phase2 (D98).
As we briefly discussed at last SIM meeting, on my side I would be in favor of moving the baseline to the the aging scenario, given this is not only what we use for RelVals but also what has been used everywhere for the latest public results (e.g. the HLT AR). As @rovere was suggesting (during the meeting) this could also help to put some pressure on the DPGs to deliver a more reliable aging setup.
Then we could have the no radiation setup as a special case and I imagine this is on us (PdmV).
@cms-sw/pdmv-l2 Do we switch already, or we plan to switch? Thx.
@srimanob we plan to. It's trickier than I thought to have the customization everywhere. I hope to converge soon.
In Phase2, a series of HCAL PF thresholds depend on the HCAL SiPM ageing scenario (see examples 1, 2). When no ageing is specified, the framework picks the "0 fb-1" thresholds (as in the example 1), which correspond to the Run3 ones.
What we noticed is that the current PR testing workflows for Phase2 do not specify any ageing, hence thresholds different from the "0 fb-1" ones are never tested. This is far from ideal, as for instance some Phase2 RelVals used in validation campaigns for PU 200 scenario do utilize "1000 fb-1" thresholds (whereas for example
25034.999_TTbar_14TeV+2026D98PU
has PU != 0 but ageing = 0 fb-1).My understanding is that it should be as easy as adding, e.g.,
--customise SLHCUpgradeSimulations/Configuration/aging.customise_aging_1000
to the relevant cmsDriver commands (both for trigger and offline reconstruction). I let HCAL experts comment on which ones it would be best to do so, and using which lumi scenarios. Possibly all of them in different workflows?FYI @abdoulline