LHCb merge requestshttps://gitlab.cern.ch/lhcb/LHCb/-/merge_requests2023-07-06T17:41:44+02:00https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2984Draft: Decommission COOL2023-07-06T17:41:44+02:00Marco CattaneoDraft: Decommission COOLhttps://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/2993Introduced infrastructure to read ROOT files in algorithms (allowing MT)2024-03-27T16:09:58+01:00Sebastien PonceIntroduced infrastructure to read ROOT files in algorithms (allowing MT)Part of set of MR LHCb!2993 Rec!2735 Allen!1370 Moore!927 DaVinci!1002 Panoptes!304 Alignment!439 MooreOnline!325 lhcb-datapkg/PRConfig!388
Depends on gaudi/Gaudi!1197 gaudi/Gaudi!1523 gaudi/Gaudi!1526
This also allows to get rid of th...Part of set of MR LHCb!2993 Rec!2735 Allen!1370 Moore!927 DaVinci!1002 Panoptes!304 Alignment!439 MooreOnline!325 lhcb-datapkg/PRConfig!388
Depends on gaudi/Gaudi!1197 gaudi/Gaudi!1523 gaudi/Gaudi!1526
This also allows to get rid of the ancient Gaudi way of reading input in
favor of Producer algorithms and introduces multithreading reads for all
ROOT files (MDF case was already tackled)
The new algorithm, RootIOAlg, can handle any number of outputs, dynamically
creating them from the list of branches to be read from the orignal file.
For each branch, the name of the associated property has to be given so
that consumer algorithms of these data can name them.
One can find a fully working example in the test rootioalg, where RootIOAlg
is directly used. This is not the way it should be handled by end users though.
For the impatient ones, the code to read a single item, namely here the
RawEvent looks like this :
```python
qualifiers = test_file_db['MiniBrunel_2018_MinBias_FTv4_DIGI']
raw_event_location = '/Event/DAQ/RawEvent'
ioalg = RootIOAlg("RootIOAlg",
EventBufferLocation=raw_event_location + "Banks",
Input=qualifiers.filenames,
EventBranches=[("RawEventLocation", raw_event_location)],
BufferNbEvents=20,
NSkip=20)
countalg = CountBanks("CountBanks", RawEventLocation=raw_event_location)
```
There are two mising features with this approach :
- you need to give all EventBranches in one go when creating RootIOAlg
this would mean collecting the needed inputs from the whole set of
algorithms ran before creating the RootIOAlg
- the returned ioalg does not have the expected output DataHandles
namely you cannot use ioalg.RawEventLocation in Countbanks
These problems have been dealt with at the PyConf level and end users should
use `input_from_root_file` helper to deal with input. This method takes
a property name and a location and returns the DataHandle to be used
to address the associated output of the RootIOAlg algorithm in the
back.
PyConf will take care of instantiating a single RootIOAlg and collecting
the different inputs.
The configuration of the RootIOAlg can be handled via the PyConf options,
namely :
- ioalg_buffer_nb_events : number of events in each buffer, defaults to 20
- input_files : list of input files
- first_evt : number of events to skip at start, defaults to 0
- mdf_ioalg_name: in case of MDF input, allows to choose between IOAlgFileRead
(default) and IOAlgMemoryMap (or any user supplied one)
- root_ioalg_name: in case of ROOT input, allows to choose between RootIOAlg
(default) and RootIOAlgExt which will read all branches of the input file
automatically. Do not use RootIOAlgExt unless needed, e.g. when CopyInputStream
is used
- root_ioalg_opts: allows to pass extra options to the RootIOAlg, e.g. IgnorePaths
when using RootIOAlgExt. See properties of RootIOAlg for more details
On top method set_input_and_conds_from_testfiledb still exist to help
in case testfiledb is used and it will deal with the input_files
Here is a code sample :
```python
options = ApplicationOptions()
options.set_input_and_conds_from_testfiledb('MiniBrunel_2018_MinBias_FTv4_DIGI')
options.first_evt = 20
options.evt_max = 40
config = configure_input(options)
raw_event_location = input_from_root_file("RawEventLocation", "_Event_DAQ_RawEvent.")
countalg = CountBanks("CountBanks", RawEventLocation=raw_event_location)
```Rosen MatevRosen Matevhttps://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/4285Draft: Fix raw event corruption and add more checks in RawEvent::MapView2024-02-05T17:28:30+01:00Rosen MatevDraft: Fix raw event corruption and add more checks in RawEvent::MapView1. The number of banks can't be more than 65535
2. The banks in `RawEvent::m_banks` must be grouped by bank type
(i.e. there cannot be banks of a different type in between the
first and the last bank of a given type).
This was un...1. The number of banks can't be more than 65535
2. The banks in `RawEvent::m_banks` must be grouped by bank type
(i.e. there cannot be banks of a different type in between the
first and the last bank of a given type).
This was uncovered in https://gitlab.cern.ch/lhcb/Moore/-/merge_requests/2436 where due to a problem in the python configuration we were trying to save too many banks (and in the wrong order).
In turn, the extra checks uncovered #330. This MR fixes #330 by extending the lifetime of the raw event memory. A memory leak is also fixed.
/cc @msaur @sesen @jonrobRosen MatevRosen Matevhttps://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/4342Draft: Add BCID plot to HltLumiSummaryMonitor2024-02-05T13:59:12+01:00Rosen MatevDraft: Add BCID plot to HltLumiSummaryMonitorThe majority of the original MR was absorbed in !4130
To be seen if this extra commit is actually necessary (or it can be replaced by including ODINMonitor)
See also https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3747 https://gitlab....The majority of the original MR was absorbed in !4130
To be seen if this extra commit is actually necessary (or it can be replaced by including ODINMonitor)
See also https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3747 https://gitlab.cern.ch/lhcb/MooreOnline/-/merge_requests/321
/cc @edalloccRosen MatevRosen Matevhttps://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/4429Streamline available states for track types2024-03-25T11:53:17+01:00Andre GuntherStreamline available states for track typesObjectives:
- specialise the available states for each track type according to their fit history. This is useful because tracks out of the pattern recognition have different states than their fitted counterparts. Defining this centrally...Objectives:
- specialise the available states for each track type according to their fit history. This is useful because tracks out of the pattern recognition have different states than their fitted counterparts. Defining this centrally in `States.h` avoids mistakes when converting among the different track implementations Pr <-> v3 <-> v1, see Rec#519.
- with centrally defined available states, the Pr track containers now statically map state locations to the index in the SOA state field such that state quantities are accessed by location, not index, which is more readable
- move state-related SOACollections from PrTracksTag.h and Track_v3.h to States.h header
- implement zip-compatible constructors for RelationTable1D/2D and provide `weight` function for ExtraTags access (foreseen access via Weight functor) ~"new feature"
Goes with Rec!3738 and Allen!1433 and Moore!3045Andre GuntherAnfeng LiAndre Guntherhttps://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/4458consistently use LHCb::span instead of gsl::span2024-03-24T16:30:15+01:00Gerhard Ravenconsistently use LHCb::span instead of gsl::spanavoid mixing LHCb::span (which defers to gsl::span) and direct use of gsl::span, as LHCb::span makes sure several macros are defined to avoid bounds checking in non-debug builds, and ensures that `span<byte>` uses `std::byte` instead of ...avoid mixing LHCb::span (which defers to gsl::span) and direct use of gsl::span, as LHCb::span makes sure several macros are defined to avoid bounds checking in non-debug builds, and ensures that `span<byte>` uses `std::byte` instead of `gsl::byte`, and we don't want to have two 'variants' of gsl::span being used simultaneously which are configured differently...
(and it will make a future migration to C++20 `std::span` easier as well)Gerhard RavenGerhard Ravenhttps://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/4469Draft: [TCK Infra] The official tck_repo has 'master' instead of 'main', need...2024-03-26T15:10:44+01:00Luke GrazetteDraft: [TCK Infra] The official tck_repo has 'master' instead of 'main', needs patching.cc @rmatev
In the tck generation stage: with the new [official tck repository](https://gitlab.cern.ch/lhcb/tcks) instead of the [unofficial tck repository](https://gitlab.cern.ch/lhcb-rta/tcks) used last year, we receive the following ...cc @rmatev
In the tck generation stage: with the new [official tck repository](https://gitlab.cern.ch/lhcb/tcks) instead of the [unofficial tck repository](https://gitlab.cern.ch/lhcb-rta/tcks) used last year, we receive the following error.
```
terminate called after throwing an instance of 'std::runtime_error'
what(): Git error -34: reference 'refs/heads/main' not found
Failed to convert sequence to git repo
```
I believe this is due to `master` over `main` being chosen when the new tck repo was being set up.
- This has now been changed so that the new tck repo is compatible with the old.
### ToDo:
- [ ] It's preferable to use a 'root commit', i.e. a branch without a parent, instead of using either `main` or `master`Rosen MatevLuke GrazetteRosen Matevhttps://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/4485decayLength rename in ParticleParams2024-03-27T20:52:38+01:00Andrea Villaandrea.villa@cern.chdecayLength rename in ParticleParamsRenaming the `decayLength` attribute of the `ParticleParams` module to make it consistent with the DaVinci functor that computes the flight distance.
Corresponding changes are put in place in https://gitlab.cern.ch/lhcb/Rec/-/merge_requ...Renaming the `decayLength` attribute of the `ParticleParams` module to make it consistent with the DaVinci functor that computes the flight distance.
Corresponding changes are put in place in https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3815 and https://gitlab.cern.ch/lhcb/DaVinci/-/merge_requests/1057Anfeng LiAnfeng Lihttps://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/4501prefer `DataHandle::setKey` over `DataHandle::updateKey`2024-03-28T08:53:37+01:00Gerhard Ravenprefer `DataHandle::setKey` over `DataHandle::updateKey`both `DataHandle::setKey` and `DataHandle::updateKey` do the exact same thing, so standardize on one of them (so that the other can be removed subsequently)both `DataHandle::setKey` and `DataHandle::updateKey` do the exact same thing, so standardize on one of them (so that the other can be removed subsequently)