IFT: Sprucing Lines for Ξ and Ω in SMOG2
Sprucing lines for Ξ -> Λπ and Ω -> ΛK. The following retention where found for pAr 2023 SMOG1 Sim:
Line | Retention |
---|---|
SpruceIFT_SMOG2Xi2Lambda0pi_lllDecisionWithOutput | (0.1020211 +- 0.00627576)% |
SpruceIFT_SMOG2Xi2Lambda0pi_ddlDecisionWithOutput | (0.05796653 +- 0.00473158)% |
SpruceIFT_SMOG2Xi2Lambda0pi_dddDecisionWithOutput | (0.05719365 +- 0.00469994)% |
SpruceIFT_SMOG2Omega2Lambda0K_lllDecisionWithOutput | (0.08347181 +- 0.00567717)% |
SpruceIFT_SMOG2Omega2Lambda0K_ddlDecisionWithOutput | (0.03671214 +- 0.00376589)% |
SpruceIFT_SMOG2Omega2Lambda0K_dddDecisionWithOutput | (0.02859682 +- 0.00332384)% |
Merge request reports
Activity
requested review from @oboenteg
assigned to @lakolk
added RTA label
added Spruce_SMOG label
requested review from @kmattiol
- Resolved by Jamie Gooding
Hi @nskidmor @abertoli these are lines that we would like to include (if possible) in the 2023 sprucing campaign for the pp reference run data that we will take later this month (not for the 2023 campaigns you have already prepared).
Edited by Kara Mattioli- Resolved by Lars Kolk
@lakolk @kmattiol (cc @nskidmor):
- in general in LHCb the
throughput
is the number of events per second Hlt2 or Spruce can process, see: https://lhcbpr-hlt.web.cern.ch/PerfTests/UpgradeThroughput/
could it be that the
%
above are the retentions ? i.e. the fraction of the input file events saved by that line ?- does the proposed lines depends on any Hlt2 line writing to the FULL stream not yet in master ?
- does these lines have ZERO rate, because of a vertex cut for example, in pp simulated events ?
- for the final green light we will need an estimate of the bandwidth from pAr simulated events as @kmattiol gave us in the past
Edited by Alessandro Bertolin - in general in LHCb the
- Resolved by Lars Kolk
let me point out that what I read in these two places:
_MASSWINDOW_LAMBDA0 = [(1115.683 - 25) * MeV, (1115.683 + 25) * MeV] _MASSWINDOW_OMEGA = [(1672 - 25) * MeV, (1672 + 25) * MeV]
_MASSWINDOW_LAMBDA0 = [(1115.683 - 25) * MeV, (1115.683 + 25) * MeV] _MASSWINDOW_XI = [(1321.71 - 25) * MeV, (1321.71 + 25) * MeV]
is by far not ideal: please let's avoid hardwired mass values in the code
in B2OC we have been doing so for some time but now we are using, for example,
F.PDG_MASS("D_s+")
so 1115.683 is
F.PDG_MASS("Lambda_0")
and so on
- Resolved by Lars Kolk
added ci-test-triggered label
- [2023-09-08 10:20] Validation started with lhcb-master-mr#9166
assigned to @nskidmor
- Resolved by Alessandro Bertolin
@lakolk @oboenteg @kmattiol (cc @kmattiol), let me try to summarize the different therads above and tell me if I am wrong and where:
- the hlt2 lines these sprucing line depend on are already merged into master
- the retentions on pAr are in the description, I am assuming these retentions have been obtained using a Moore/Hlt2 version that contains the Hlt2 lines of the point above
- largest retention is 0.1 % (or 0.1 = 10 % ?)
- there is no real rush at the moment to get this in master, about 1 week left
- the 1 week left is still not sufficient to fix the hardwired masses ? you could fix them in this MR / in the Spruce first and then later propagate to the Hlt2
- if retention are < 0.1 % then we do not absolutely need the GB/sec
mentioned in issue #659 (closed)
added 1 commit
- 38066342 - replaced hardcoded masses with thor functors
mentioned in commit 933d84ee