Allen merge requestshttps://gitlab.cern.ch/lhcb/Allen/-/merge_requests2023-12-16T11:53:04+01:00https://gitlab.cern.ch/lhcb/Allen/-/merge_requests/1362Fixes for gcc 13, clang 16 and C++202023-12-16T11:53:04+01:00Marco Clemencicmarco.clemencic@cern.chFixes for gcc 13, clang 16 and C++20- Avoid use of deprecated `is_pod`
- Fix implicit capture of this (deprecated in C++20)
- Remove unused variables
Note that implicit capture of `this` via `[=]` causes a warning in C++20, but the new way `[=,this]` causes a warning in C...- Avoid use of deprecated `is_pod`
- Fix implicit capture of this (deprecated in C++20)
- Remove unused variables
Note that implicit capture of `this` via `[=]` causes a warning in C++20, but the new way `[=,this]` causes a warning in C++17, so we hide the C++17 warning (at some point we will stop supporting C++17).Sebastien PonceSebastien Poncehttps://gitlab.cern.ch/lhcb/Allen/-/merge_requests/1103Force test validator to take into account stderr exclusions2023-02-14T02:08:25+01:00Marco Clemencicmarco.clemencic@cern.chForce test validator to take into account stderr exclusionsThis is needed to take into account a new `Info` message from ROOT 6.26 (LCG 102).
See lhcb/LHCb!3925This is needed to take into account a new `Info` message from ROOT 6.26 (LCG 102).
See lhcb/LHCb!3925https://gitlab.cern.ch/lhcb/Allen/-/merge_requests/1097lumi counters implementation: Velo tracks in fiducial volume and eta bins, PV...2023-03-24T12:45:12+01:00Shu Xianlumi counters implementation: Velo tracks in fiducial volume and eta bins, PVs in fiducial volum, total ECal Elumi counters implemented:
* Velo tracks in fiducial volume and eta bins
* PVs in fiducial volume
* total ECal E
Change the names of the ECal ET in different regions from `ECalE{region}` to `ECalET{region}`lumi counters implemented:
* Velo tracks in fiducial volume and eta bins
* PVs in fiducial volume
* total ECal E
Change the names of the ECal ET in different regions from `ECalE{region}` to `ECalET{region}`Sebastien PonceSebastien Poncehttps://gitlab.cern.ch/lhcb/Allen/-/merge_requests/1039Plume decoding esp merge2023-01-13T14:22:11+01:00Eugenia SpedicatoPlume decoding esp mergeAdding Plume decoding in Allen device
Goes with MooreAnalysis!94Adding Plume decoding in Allen device
Goes with MooreAnalysis!94https://gitlab.cern.ch/lhcb/Allen/-/merge_requests/1031Preparation for beam gas imaging data collection2022-11-02T16:26:12+01:00Patrick SpradlinPreparation for beam gas imaging data collection## Summary
This MR adds components and lines intended to support event selection for
beam gas imaging (BGI) analysis for luminosity calibration. It also adds
detector activity lines for ghost charge analysis. These new lines are
colle...## Summary
This MR adds components and lines intended to support event selection for
beam gas imaging (BGI) analysis for luminosity calibration. It also adds
detector activity lines for ghost charge analysis. These new lines are
collected in a new Allen configuration sequence.
## Requirements
The lines for BGI that are implemented in this MR are intended to reproduce
the Run2 Hlt selections that were used for this purpose. The requirements
and deisgn of the detector activity lines for ghost charge analysis emerged
from discussions within the luminosity group.
### BGI requirements
The BGI lines should accept events based on the bunch crossing type and on
following properties of reconstructed PVs:
- number of tracks composing the PV
- PV location in cylindrical coordinates, i.e., in $z$ and cylindrical radius $\rho$
A minimum number of tracks requirement is necessary for the analysis, which
includes a split-vertex determination of the vertex reconstruction resolution.
It can also be used as a proxy for a vertex quality cuts and a scale factor
(see discussion in the Implementation section).
The $z$ positions of PVs are used to partition the fiducial volume into luminous
and non-luminous regions. Primarily, this is useful to control the rate of
events from the luminous region in beam-beam events.
An upper limit on the $\rho$ positions of the PVs allows exclusion of secondary
vertexes from material interactions.
### Ghost charge requirements
The ghost charge measurement relies on detecting activity in the detector in the
absence of beams. In addition to event selection based on bunch crossing type,
ideally, we would use activity metrics from three subdetectors:
1. VELO
2. CALO
3. PLUME (*not implemented in this MR*)
For VELO activity, a minimum number of VELO clusters is required. Preferably,
we would have the ability to select events that contain a minimum number of
VELO clusters within a specified range of $z$ or set of sensor planes.
(This latter feature is not implemented in this MR.) It should accept events
with bunch crossing types ee, be, and eb that satisfy the VELO cluster
requirements.
The CALO activity line is specifically for studying ghost charge of Beam1,
so it must trigger on bunch crossing for which Beam1 is absent: ee and eb.
The CALO activity selection should accept events with a minimum amount of
deposited energy in the calorimeters.
The PLUME activity line is specifically for studying ghost charge of Beam2,
so it must trigger on bunch crossing for which Beam1 is absent: ee and be.
The quantity to serve as the activity metric is not yet defined, and *no
PLUME activity line is implemented in this MR.*
## Implementation
### Thresholds
All of the thresholds implemented in this MR are preliminary. They are
based on Run2 BGI selections and on algorithm defaults. We should plan
to adjust them based on the characteristics of real data, when available.
### BGI lines
No combination of previously existing filters and line algorithms was found
to apply the desired selections. A combination of
[CheckPV](https://gitlab.cern.ch/lhcb/Allen/-/blob/master/device/selections/filters/include/CheckPV.cuh)
filters and
[BeamCrossingLine](https://gitlab.cern.ch/lhcb/Allen/-/blob/master/device/selections/lines/monitoring/include/BeamCrossingLine.cuh)
line algorithm would be close---it could select events for a given bunch crossing
type based on presence of a PV within a specified $z$ range. However, it
would not allow us filter out PVs that lie outside of a specified cylindrical
radius or that have too few tracks to be useful.
This MR creates a new filter algorithm to meet our requirements, which is
currently called CheckCylPV. It is a copy-mod of CheckPV that adds checks on the
PV `nTracks` and on its $\rho^2 = x^2 + y^2$.
#### Lines for non-bb events
The current implementation is composed of three lines---one for each non-bb bunch
crossing type---that select every event with a reconstructed PV that has
- nTracks >= 10
- -2000 mm <= z < 2000 mm
- $\rho^2 < (3 \text{mm})^2$
Depending on SMOG2 operations and event rates, this structure may need to be
modified to scale events with PVs in the target cell.
```mermaid
flowchart TD
F["BGIPVsCylAll (CheckCylPV filter)"] --> EE["Hlt1BGIPVsCylNoBeam<br/>(BeamCrossingLine)<br/>Empty-Empty events"]
F --> EB["Hlt1BGIPVsCylBeamOne<br/>(BeamCrossingLine)<br/>Beam-Empty events"]
F --> BE["Hlt1BGIPVsCylBeamTwo<br/>(BeamCrossingLine)<br/>Empty-Beam events"]
```
#### Lines for bb events
Experience from Run2 indicates that beam-beam collisions can easily overwhelm
BGI samples. We need to be able to control the rate of bb-events with PVs in
the luminous region. In this MR, this is implemented by using three instances
of CheckCylPV to partition the $z$-range. In order to control the rate in the
luminous region, this MR includes a greater lower-limit on PV nTracks for
the CheckCylPV instance for the luminous region. As a byproduct of the increased
threshold, we expect the vertexes that are retained from this region to have a
better resolution.
```mermaid
flowchart TD
FUP["BGIPVsCylUp (CheckCylPV filter)<br/>nTracks >= 10<br/>-2000 < z <= -250 mm"] --> LUP["Hlt1BGIPVsCylUpBeamBeam<br/>(BeamCrossingLine)<br/>Beam-Beam events"]
FIR["BGIPVsCylIR (CheckCylPV filter)<br/>nTracks >= 28<br/>-250 < z <= 250 mm"] --> LIR["Hlt1BGIPVsCylIRBeamBeam<br/>(BeamCrossingLine)<br/>Beam-Beam events"]
FDW["BGIPVsCylDown (CheckCylPV filter)<br/>nTracks >= 10<br/>250 < z <= 2000 mm"] --> LDW["Hlt1BGIPVsCylDownBeamBeam<br/>(BeamCrossingLine)<br/>Beam-Beam events"]
```
### Activity Lines
#### VELO
No known combination of preexisting filters and line algorithms satisfied the
requirements of selecting events based on VELO clusters. This MR implements a
new line algorithm, VeloClustersMicroBiasLine, that selects events based on the
presence of a minimum number of VELO clusters. *Note that it does not yet
implement the desired refinement to select based on specific z regions or set
of sensor planes.* This new line algorithm was developed from scratch. However,
the structure is patterned after the line algorithm `VeloMicroBiasLine`, and the
computation of the number of VELO clusters is based on those in the function
`print_velo_clusters` and in the algorithm `velo_sort_by_phi_t`.
This new algorithm is combined with an `ODINBeamCrossingType` to select non-bb
crossings with VELO activity.
The current implementation sets a lower limit threshold of >= 1 VELO cluster for
accepting the event.
#### CALO
This is currently implemented as an `ODINBeamCrossingType` filter to select
non-bb crossings and a `CaloDigitsMinADCLine` line algorithm to accept events
with a minimum ADC in the ECAL. Of the pre-existing line algorithms surveyed,
this seemed best suited to the task.
*The current threshold is the default value of >= 500.*
#### Activity line diagram
```mermaid
flowchart TD
BX["BX_BeamBeam (ODINBeamCrossingType filter)<br/>beam-beam crossings"] --> NB["BX_NoBeamBeam (event_list_inversion_t)<br/>Inverts previous step<br/>non-beam-beam crossings"]
NB --> VELO["Hlt1BGIVeloClustersMicroBias<br/>(VeloClustersMicroBiasLine)<br/>n VELO clusters >=1"]
NB --> CALO["Hlt1BGICaloDigits<br/>(CaloDigitsMinADCLine)<br/>ecal_digits.adc >= 500"]
```
Partially addresses #223.
Attn: @edallocc @balagura @agomezmo @dmilanes @nmchugh @psolerhttps://gitlab.cern.ch/lhcb/Allen/-/merge_requests/911add encoding key to DecReport raw bank2024-01-26T16:18:15+01:00Gerhard Ravenadd encoding key to DecReport raw bankfollow changes in LHCb!3528 to add an explicit encoding key into the DecReports raw bank (and increase its version number).
NOTE: requires LHCb!3528 in order to have a decoder which can decode this version of the rawbank -- and LHCb!352...follow changes in LHCb!3528 to add an explicit encoding key into the DecReports raw bank (and increase its version number).
NOTE: requires LHCb!3528 in order to have a decoder which can decode this version of the rawbank -- and LHCb!3528 also requires Moore!1529 which in turn uses functionality from this MR -- so this MR must be applied in conjunction with LHCb!3528 and Moore!1529Christopher Rob Jonesjonesc@hep.phy.cam.ac.ukChristopher Rob Jonesjonesc@hep.phy.cam.ac.ukhttps://gitlab.cern.ch/lhcb/Allen/-/merge_requests/856Adapt HLT1 TwoKsLine to new event model2022-11-15T16:40:46+01:00Lorenzo PicaAdapt HLT1 TwoKsLine to new event modelThe MR adapts the HLT1 TwoKsLine to the new event model.
Two new algorithms are added: `FilterSvs` and `SvsPairCandidate`. These create a `CompositeParticle` candidate made of two other `CompositeParticle`s, hence the two KS. In `Filter...The MR adapts the HLT1 TwoKsLine to the new event model.
Two new algorithms are added: `FilterSvs` and `SvsPairCandidate`. These create a `CompositeParticle` candidate made of two other `CompositeParticle`s, hence the two KS. In `FilterSvs` selections are applied to the SV candidates.
FYI @thboettc @mvesteri @poluekt @eshields @dcampora @dovombruRosen MatevRosen Matevhttps://gitlab.cern.ch/lhcb/Allen/-/merge_requests/718Follow up !687 (fix warning)2021-12-06T12:44:47+01:00Rosen MatevFollow up !687 (fix warning)Rosen MatevRosen Matevhttps://gitlab.cern.ch/lhcb/Allen/-/merge_requests/707Use std::deque instead of std::vector for counters2021-12-02T11:09:22+01:00Marco Clemencicmarco.clemencic@cern.chUse std::deque instead of std::vector for countersThis is a minor backward compatible fix needed to be able to compile with gaudi/Gaudi!1258This is a minor backward compatible fix needed to be able to compile with gaudi/Gaudi!1258https://gitlab.cern.ch/lhcb/Allen/-/merge_requests/662Make SEQUENCES regex be used for an exact match instead of a search2021-09-21T08:58:57+02:00Daniel Campora PerezMake SEQUENCES regex be used for an exact match instead of a searchThe option `-DSEQUENCES` is used as a regex to select which sequences to build based on their name (without the `.py` extension).
Previously, setting `-DSEQUENCES=velo` would also pick up `veloUT`, since the underlying `string(REGEX MAT...The option `-DSEQUENCES` is used as a regex to select which sequences to build based on their name (without the `.py` extension).
Previously, setting `-DSEQUENCES=velo` would also pick up `veloUT`, since the underlying `string(REGEX MATCH ...)` matches any substring. This MR changes that to require an exact match. It is still possible to trigger the previous behaviour with a wildcard character (Kleene closure) `.*`Miroslav Saurmiroslav.saur@cern.chMiroslav Saurmiroslav.saur@cern.chhttps://gitlab.cern.ch/lhcb/Allen/-/merge_requests/661Default allen.py to python32021-09-25T18:31:00+02:00Daniel Campora PerezDefault allen.py to python3Tiny fix to point to `python3` in `allen.py` instead of `python2`.Tiny fix to point to `python3` in `allen.py` instead of `python2`.Miroslav Saurmiroslav.saur@cern.chMiroslav Saurmiroslav.saur@cern.chhttps://gitlab.cern.ch/lhcb/Allen/-/merge_requests/659Fix Sbt contract where ID was being assigned to Phi.2021-09-25T18:31:00+02:00Daniel Campora PerezFix Sbt contract where ID was being assigned to Phi.This MR fixes an Sbt contract.
More worrying is the fact that I saw this one failing locally in my computer. Therefore, how the contracts are running should also be investigated.This MR fixes an Sbt contract.
More worrying is the fact that I saw this one failing locally in my computer. Therefore, how the contracts are running should also be investigated.Miroslav Saurmiroslav.saur@cern.chMiroslav Saurmiroslav.saur@cern.chhttps://gitlab.cern.ch/lhcb/Allen/-/merge_requests/580Adapt to drop of StatusCode check via StatusCodeSvc2021-06-20T16:26:37+02:00Marco Clemencicmarco.clemencic@cern.chAdapt to drop of StatusCode check via StatusCodeSvcWith gaudi/Gaudi!989 we are enforcing the check of returned `StatusCode` instances only via the `[[nodiscard]]` attribute and compiler warnings, so the constructor `StatusCode::StatusCode(code, checked)` is deprecated.
This MR fixes all...With gaudi/Gaudi!989 we are enforcing the check of returned `StatusCode` instances only via the `[[nodiscard]]` attribute and compiler warnings, so the constructor `StatusCode::StatusCode(code, checked)` is deprecated.
This MR fixes all the warnings resulting from the new `StatusCode` policy.Xiaoyu ZhuXiaoyu Zhuhttps://gitlab.cern.ch/lhcb/Allen/-/merge_requests/557Report the rate without requiring MC information2021-09-25T18:31:01+02:00Roel AaijReport the rate without requiring MC informationThe (line) rate reporter does not need MC information, so it has now been added to the HLT1 sequence, i.e. it runs also when not using MC information.
This makes it significantly easier to run on a large sample of minbias events to get...The (line) rate reporter does not need MC information, so it has now been added to the HLT1 sequence, i.e. it runs also when not using MC information.
This makes it significantly easier to run on a large sample of minbias events to get a better estimate of the line rates.
The JSON output when writing the configuration to a file has also been made more readable.
Pregenerated sequences have been updated.
Example output running on nearly 100k minbias events in 8 seconds:
```console
rate_validator validation:
Hlt1KsToPiPi: 1963/ 97799, ( 602.15 +/- 13.45) kHz
Hlt1TrackMVA: 1297/ 97799, ( 397.86 +/- 10.97) kHz
Hlt1TwoTrackMVA: 1721/ 97799, ( 527.92 +/- 12.61) kHz
Hlt1TwoTrackCatBoost: 1769/ 97799, ( 542.64 +/- 12.78) kHz
Hlt1SingleHighPtMuon: 28/ 97799, ( 8.59 +/- 1.62) kHz
Hlt1LowPtMuon: 7146/ 97799, ( 2192.05 +/- 24.97) kHz
Hlt1D2KK: 252/ 97799, ( 77.30 +/- 4.86) kHz
Hlt1D2KPi: 322/ 97799, ( 98.77 +/- 5.50) kHz
Hlt1D2PiPi: 132/ 97799, ( 40.49 +/- 3.52) kHz
Hlt1DiMuonHighMass: 402/ 97799, ( 123.31 +/- 6.14) kHz
Hlt1DiMuonLowMass: 526/ 97799, ( 161.35 +/- 7.02) kHz
Hlt1DiMuonSoft: 16/ 97799, ( 4.91 +/- 1.23) kHz
Hlt1LowPtDiMuon: 1181/ 97799, ( 362.27 +/- 10.48) kHz
Hlt1TrackMuonMVA: 75/ 97799, ( 23.01 +/- 2.66) kHz
Hlt1GECPassthrough: 90837/ 97799, (27864.40 +/- 24.67) kHz
Hlt1NoBeam: 0/ 97799, ( 0.00 +/- 0.00) kHz
Hlt1BeamOne: 0/ 97799, ( 0.00 +/- 0.00) kHz
Hlt1BeamTwo: 0/ 97799, ( 0.00 +/- 0.00) kHz
Hlt1BothBeams: 99/ 97799, ( 30.37 +/- 3.05) kHz
Hlt1VeloMicroBias: 90/ 97799, ( 27.61 +/- 2.91) kHz
Hlt1ODINLumi: 0/ 97799, ( 0.00 +/- 0.00) kHz
Hlt1ODINNoBias: 0/ 97799, ( 0.00 +/- 0.00) kHz
Hlt1Passthrough: 97799/ 97799, (30000.00 +/- 0.00) kHz
Inclusive: 97799/ 97799, (30000.00 +/- 0.00) kHz
```Roel AaijChristoph HasseMiroslav Saurmiroslav.saur@cern.chRoel Aaijhttps://gitlab.cern.ch/lhcb/Allen/-/merge_requests/551Ks-Line2021-12-09T19:07:27+01:00Lorenzo PicaKs-LineThe MR introduces a new line in Allen. This lines selects Ks already at first HLT level.
These are defined inside .cuh and .cu files and they have been added to the Allen default lines, in order to test them with other lines (and determ...The MR introduces a new line in Allen. This lines selects Ks already at first HLT level.
These are defined inside .cuh and .cu files and they have been added to the Allen default lines, in order to test them with other lines (and determine inclusive rates).
This MR was implementing another line, aimed to Lambda0 collection as done for Ks.
The implementation of the Lambda0 line is now in https://gitlab.cern.ch/lhcb/Allen/-/merge_requests/614. The two lines have been put in different MRs to do not slow down the merging of this MR, since the Lambda0 needs additional work before being ready.
Selections of the TwoTrackKsLine are:
- chi2trk/ndof (pi) < 2.5
- p_t(pi) > 470 MeV/c
- p(pi) > 5000 MeV/c
- IPchi2 (pi) > 50
- chi2_vtx (KS) < 20
- 2 < eta(KS) < 4.2
- |m(pi pi) - m(KS)| < 45 MeV/c2
- p_t(KS) > 2500 MeV/c
- cos(theta_DIRA) > 0.99
- cos(theta(pi pi)) > 0.99
- IP(pi+) x IP(pi-) / IP(KS) > 0.72 mm
Rate is computed through HltEfficiencyChecker, exploiting 100k events of the
`MiniBrunel_2018_MinBias_FTv4_DIGI` MinBias sample.
Rate Ks-Line (exclusive) = (63.9 +- 4.3) kHz
Rate (TrackMVA OR TwoTrackMVA) = (811 +- 15) kHz
Rate (TrackMVA OR TwoTrackMVA or Ks-Line) = (851 +- 16) kHz
Ks-Line adds 40 kHz to the rate of TrackMVA and TwoTrackMVA.
Efficiencies are estimated exploiting HltEfficiencyChecker on some significant samples.
Efficiencies are computed for both Ks-Line, TrackMVA and TwoTrackMVA lines, as reference.
NOTICE: these are Decision efficiencies and not TOS efficiencies, therefore also particles not coming from the considered decay can trigger the lines. This probably enhances the eff. of lines of large rate more than the one of the Ks-Line, due to its lower acceptance. Decision efficiencies are shown since TOS efficiencies are not available at the moment for Allen in HltEfficiencyChecker.
```
D0->KsKs:
eff(TrackMVA) = (7.4 +- 1.3)%
eff(TwoTrackMVA) = (8.9 +- 1.5)%
eff(Ks-Line) = (8.9 +- 1.5)%
B0->KsKs:
eff(TrackMVA) = (59 +- 6)%
eff(TwoTrackMVA) = (38 +- 6)%
eff(Ks-Line) = (49 +- 6)%
D0->KsPiPi:
eff(TrackMVA) = (5.4 +- 0.7)%
eff(TwoTrackMVA) = (9.8 +- 0.9)%
eff(Ks-Line) = (3.1 +- 0.5)%
B0->KsPi0:
eff(TrackMVA) = (20.5 +- 0.8)%
eff(TwoTrackMVA) = (17.1 +- 0.8)%
eff(Ks-Line) = (15.0 +- 0.7)%
B0->KsPiPi:
eff(TrackMVA) = (47.3 +- 1.6)%
eff(TwoTrackMVA) = (47.7 +- 1.6)%
eff(Ks-Line) = (9.1 +- 0.9)%
D+->KsPi+:
eff(TrackMVA) = (7.2 +- 0.6)%
eff(TwoTrackMVA) = (8.0 +- 0.6)%
eff(Ks-Line) = (3.0 +- 0.4)%
Ds+->KsK+:
eff(TrackMVA) = (5.3 +- 0.5)%
eff(TwoTrackMVA) = (6.9 +- 0.5)%
eff(Ks-Line) = (2.1 +- 0.3)%
B+->D0(->KsPiPi)K+:
eff(TrackMVA) = (32.9 +- 1.3)%
eff(TwoTrackMVA) = (35.3 +- 1.3)%
eff(Ks-Line) = (3.7 +- 0.5)%
```
FYI: @mstahl, @sstahl, @vlisovsk, @adeoyang, @msaur, @mcharles, @valukash, @gpunzi, @gtuci.Rosen MatevRosen Matevhttps://gitlab.cern.ch/lhcb/Allen/-/merge_requests/540Fix unit test discovery2021-03-11T21:21:26+01:00Roel AaijFix unit test discoveryPrefix the unit test discovery with xenv.
Fixes #230 (sanitizer builds)Prefix the unit test discovery with xenv.
Fixes #230 (sanitizer builds)