Rec issueshttps://gitlab.cern.ch/lhcb/Rec/-/issues2024-03-26T20:45:57+01:00https://gitlab.cern.ch/lhcb/Rec/-/issues/544Remove (now) redundant addInfo from jet making2024-03-26T20:45:57+01:00Gerhard RavenRemove (now) redundant addInfo from jet makingThe following discussion from !3834 should be addressed:
- [ ] @graven started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3834#note_7786134):
> given that on L468 the vertex is added to the jet, all the `addIn...The following discussion from !3834 should be addressed:
- [ ] @graven started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3834#note_7786134):
> given that on L468 the vertex is added to the jet, all the `addInfo` calls could be removed as they now just duplicate the information.
> ```suggestion:-8+0
> ```Murilo Santana RangelMurilo Santana Rangelhttps://gitlab.cern.ch/lhcb/Rec/-/issues/543Follow-up from "Add velo lumi counters to HLT2"2024-03-15T21:12:35+01:00Andre GuntherFollow-up from "Add velo lumi counters to HLT2"This comment https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3757#note_7645246 and
The following discussion from !3757 should be addressed:
- [ ] @graven started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3757#not...This comment https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3757#note_7645246 and
The following discussion from !3757 should be addressed:
- [ ] @graven started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3757#note_7645245): (+4 comments)
> Let's avoid unnecessary string operations (which are _not_ cheap, as they involve heap memory allocations when the strings become more than O(20) characters long):
> ```suggestion:-32+0
> // create a map of counter names to hits vector
> std::map<std::string, double> counterMap;
> // assign as keys the counter names and init the values to 0
> for ( auto i = 0u; i < m_counterNames.size(); ++i ) { counterMap[ m_counterNames[i]] = 0; }
>
> counterMap["Vertices"] = vertices.size();
>
> auto vertexIndex{0u};
>
> for ( auto vertex : vertices ) {
> auto pos = vertex.position();
> auto rho = std::sqrt( pos.x() * pos.x() + pos.y() * pos.y() );
> auto absz = std::abs( pos.z() );
> if ( absz < 300.f * Gaudi::Units::mm && rho < 3.f * Gaudi::Units::mm ) {
> ++counterMap["FiducialVertices"];
> }
> // use the sum of vertex Z co-ordinates modulo the number of vertices to pseudo-randomly choose a vertex to record
> vertexIndex += static_cast<int>( absz );
> }
>
> if ( vertices.size() > 0u ) {
> auto vtx = vertices[vertexIndex % vertices.size()].position();
> counterMap["VertexX"] = vtx.x();
> counterMap["VertexY"] = vtx.y();
> counterMap["VertexZ"] = vtx.z();
> }
>
> LHCb::HltLumiSummary summary{};
>
> for ( auto i = 0u; i < m_counterNames.size(); ++i ) {
> summary.addInfo( m_counterBaseName + m_counterNames[i], counterMap[m_counterNames[i]] );
> }
> ```
>
> Now, when combined with the change below where the `m_counterNames` is instead a vector of enums, it becomes possible to avoid the string operations all together:
> ```suggestion:-32+0
> // create a map of counter names to hits vector
> std::map<CounterNames, double> counterMap;
> // assign as keys the counter names and init the values to 0
> for ( auto i = 0u; i < m_counterNames.size(); ++i ) { counterMap[ m_counterNames[i]] = 0; }
>
> counterMap[CounterNames::Vertices] = vertices.size();
>
> auto vertexIndex{0u};
>
> for ( auto vertex : vertices ) {
> auto pos = vertex.position();
> auto rho = std::sqrt( pos.x() * pos.x() + pos.y() * pos.y() );
> auto absz = std::abs( pos.z() );
> if ( absz < 300.f * Gaudi::Units::mm && rho < 3.f * Gaudi::Units::mm ) {
> ++counterMap[CounterNames::FiducialVertices];
> }
> // use the sum of vertex Z co-ordinates modulo the number of vertices to pseudo-randomly choose a vertex to record
> vertexIndex += static_cast<int>( absz );
> }
>
> if ( vertices.size() > 0u ) {
> auto vtx = vertices[vertexIndex % vertices.size()].position();
> counterMap[CounterNames::VertexX] = vtx.x();
> counterMap[CounterNames::VertexY] = vtx.y();
> counterMap[CounterNames::VertexZ] = vtx.z();
> }
>
> LHCb::HltLumiSummary summary{};
>
> for ( auto i = 0u; i < m_counterNames.size(); ++i ) {
> summary.addInfo( m_counterBaseName + toString(m_counterNames[i]), counterMap[m_counterNames[i]] );
> }
> ```
>
> Given that at this point, the map has as key a small, dense set of small integer values, the `std::map` is overkill, but replacing that is left as an exercise to the author ;-)Daniel Charles CraikDaniel Charles Craikhttps://gitlab.cern.ch/lhcb/Rec/-/issues/542Proper handling of nullpointer arguments in functors2024-03-28T09:31:52+01:00Wouter Hulsbergenwouterh@nikhef.nlProper handling of nullpointer arguments in functorsThe discussion from !3665 should be addressed: essentially this means that (on the C++ side) functors should return an optional if they accept a pointer as argument, such that they can properly deal with nullptr.
@graven, @sesen, @gunth...The discussion from !3665 should be addressed: essentially this means that (on the C++ side) functors should return an optional if they accept a pointer as argument, such that they can properly deal with nullptr.
@graven, @sesen, @gunther, @ldufour, @amathadhttps://gitlab.cern.ch/lhcb/Rec/-/issues/541PV fit in TBLV converges poorly2024-03-14T15:44:29+01:00Wouter Hulsbergenwouterh@nikhef.nlPV fit in TBLV converges poorlyWhen debugging a problem with failed fits in TBLV I noticed that the fraction of poorly converging fits (more than 10 iterations to each abs(delta-z)<1 micron) is large, about 50%. I don't remember that it was like this when the code was...When debugging a problem with failed fits in TBLV I noticed that the fraction of poorly converging fits (more than 10 iterations to each abs(delta-z)<1 micron) is large, about 50%. I don't remember that it was like this when the code was first implemented. This possibly affects the resolution, which is why we need to worry about it.
This observation was made in the `hlt2_test_duplicate_filters` test, which processes 2022 data. One may wonder if there is a difference between data and MC.
I added counters to TBLV for the fraction of failed and unconverged fits to allow further study.
@gunther, @sesenhttps://gitlab.cern.ch/lhcb/Rec/-/issues/540Simplify implementation of DTF in FunTuple2024-03-14T12:54:07+01:00Wouter Hulsbergenwouterh@nikhef.nlSimplify implementation of DTF in FunTupleTo store the output of DTF in FunTuple we now call DecayTreeFitterAlg, which stores a number of quantities from the fit (particleparams, number of fit iterations) in the event store with relation tables linking them to the input particle...To store the output of DTF in FunTuple we now call DecayTreeFitterAlg, which stores a number of quantities from the fit (particleparams, number of fit iterations) in the event store with relation tables linking them to the input particles. It seems simpler to store the 'Fitter' object itself: That requires only a single relation table and would give access to more information, such as status codes, chisquares and the head of the decay tree (the PV in case of a PV-constrained fit).
There may even be a simpler solution: At one time DecayTreeFitter could be called directly from python, see this old twiki page:
https://twiki.cern.ch/twiki/bin/view/LHCbBackup/DecayTreeFitter
The dictionary is still processed, so I think that this functionality still exists. If FunTuple calls DecayTreeFitter like this, then perhaps no C++ Alg is needed at all.
@pkoppenb, @jzhuo, @amathadhttps://gitlab.cern.ch/lhcb/Rec/-/issues/539Replace LoKi distance calculator?2024-03-21T14:23:17+01:00Wouter Hulsbergenwouterh@nikhef.nlReplace LoKi distance calculator?As can be seen in this flame graph
https://lhcbpr-hlt.web.cern.ch/PerfTests/UpgradeThroughput/Throughput_lhcb-master-mr.10989_Moore_spruce_all_lines_x86_64_v3-el9-gcc13+detdesc-opt+g_2024-03-12_02:26:08_+0100/
the sprucing spends a lot...As can be seen in this flame graph
https://lhcbpr-hlt.web.cern.ch/PerfTests/UpgradeThroughput/Throughput_lhcb-master-mr.10989_Moore_spruce_all_lines_x86_64_v3-el9-gcc13+detdesc-opt+g_2024-03-12_02:26:08_+0100/
the sprucing spends a lot of time (25%?) in LoKi::DistanceCalculator. It should be possible to get this down by using simpler functions that do not rely on particle extraoplators (such as in the Thor functors).https://gitlab.cern.ch/lhcb/Rec/-/issues/538Open points for PV <-> particle association (Moore MR #2658)2024-03-26T20:54:24+01:00Maarten Van VeghelOpen points for PV <-> particle association (Moore MR #2658)For discussing how to handle different PV associations offline
The following discussion from !3665 should be addressed:
- [ ] @ldufour started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3665#note_7701230): (+34 co...For discussing how to handle different PV associations offline
The following discussion from !3665 should be addressed:
- [ ] @ldufour started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3665#note_7701230): (+34 comments)
> This will copy the particles to a new keyedcontainer... are we sure the relation tables of the old particles still work on these new ones?
- [ ] An LHCbIntegration test needs to be provided showing that the persistency indeed works across the chain LHCbIntegrationTests!61
- [ ] A way to access the HLT2 PV *and* the unbiased PV in the same nTuple needs to be provided
- [ ] A way to access the unbiased PV information of the daughters
- [ ] A documentation of the particle unbiasing in DaVinci needs to be added
- [ ] The 'mass constraint' in the vertex fit needs a test, this is currently untested code
- [ ] The PV functors need to be able to take explicit relations, as we want to be able to use other PV associations offline (and mix them)https://gitlab.cern.ch/lhcb/Rec/-/issues/537Track Converters are currently allowed to add GhostProb2024-02-28T14:34:22+01:00Andre GuntherTrack Converters are currently allowed to add GhostProbConverters should do nothing but converting and not add information which was previously not there
The following discussion from !3729 should be addressed:
- [ ] @gunther started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_r...Converters should do nothing but converting and not add information which was previously not there
The following discussion from !3729 should be addressed:
- [ ] @gunther started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3729#note_7648489): (+2 comments)
> I never noticed that this converter can add GhostProb and I would argue that it should not because it is a converter. In which sequence does this happen?https://gitlab.cern.ch/lhcb/Rec/-/issues/536TrackIPResolutionCheckerNT throws exception on x86_64_v2-el9-clang16+detdesc-opt2024-03-20T17:21:19+01:00Andre GuntherTrackIPResolutionCheckerNT throws exception on x86_64_v2-el9-clang16+detdesc-optSee for example [this test](https://lhcb-nightlies.web.cern.ch/nightly/lhcb-master/2309/Moore/x86_64_v2-el9-clang16+detdesc-opt/tests#RecoConf_performance_hlt1_reco_IPresolution). The exception lives in [TrackEnums.h](https://gitlab.cern...See for example [this test](https://lhcb-nightlies.web.cern.ch/nightly/lhcb-master/2309/Moore/x86_64_v2-el9-clang16+detdesc-opt/tests#RecoConf_performance_hlt1_reco_IPresolution). The exception lives in [TrackEnums.h](https://gitlab.cern.ch/lhcb/LHCb/-/blob/1faed36ed08b6206dc5224ba89f97b816e5e3398/Event/TrackEvent/include/Event/TrackEnums.h#L176), so apparently the code - only on this platform - asks for a track type that is not in the enum.Wouter Hulsbergenwouterh@nikhef.nlWouter Hulsbergenwouterh@nikhef.nlhttps://gitlab.cern.ch/lhcb/Rec/-/issues/535Histograms in PrHitCheckers contain meaningless Gaudi property variables2024-02-09T14:36:19+01:00Hangyi WuHistograms in PrHitCheckers contain meaningless Gaudi property variablesWhen dealing with https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3559, it's pointed out that the definition of histograms (in Gaudi::Accumulators:Histograms style) contains Gaudi property variables. However, properties are ONLY configu...When dealing with https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3559, it's pointed out that the definition of histograms (in Gaudi::Accumulators:Histograms style) contains Gaudi property variables. However, properties are ONLY configured during initialization, i.e. _after_ the construction of the algorithm while the histograms are created during construction -- hence the histograms as currently coded, will only ever use the default values of these properties.
It seems that not only PrUTHitsChecker, but all PrHitsCheckers have the same problem, and this has to be fixed eventually.https://gitlab.cern.ch/lhcb/Rec/-/issues/534Follow-up sorting of cluster pairs in PatPV3DFuture2024-01-25T14:45:14+01:00Andre GuntherFollow-up sorting of cluster pairs in PatPV3DFutureThe following discussion from !3612 should be addressed:
- [ ] @gunther started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3612#note_7502627): (+10 comments)
> why is this more efficient? because of the `erase...The following discussion from !3612 should be addressed:
- [ ] @gunther started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3612#note_7502627): (+10 comments)
> why is this more efficient? because of the `erase` + `remove_if` later?Agnieszka DziurdaAgnieszka Dziurdahttps://gitlab.cern.ch/lhcb/Rec/-/issues/533PrKalmanFilterTool use std::optional to deal with fit failures2024-02-08T17:09:09+01:00Andre GuntherPrKalmanFilterTool use std::optional to deal with fit failuresThe following discussion from !3726 should be addressed:
- [ ] @gunther started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3726#note_7516130):
> instead of relying on flagging tracks as invalid like this, it w...The following discussion from !3726 should be addressed:
- [ ] @gunther started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3726#note_7516130):
> instead of relying on flagging tracks as invalid like this, it would be better to return `std::optional`https://gitlab.cern.ch/lhcb/Rec/-/issues/532Clean up and factorize functor code2024-01-21T11:49:35+01:00Maarten Van VeghelClean up and factorize functor codeThe following discussion from !3718 should be addressed:
- [ ] @graven started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3718#note_7504650): (+3 comments)
> All these functors like `MuonCatBoost` and `MuonLLB...The following discussion from !3718 should be addressed:
- [ ] @graven started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3718#note_7504650): (+3 comments)
> All these functors like `MuonCatBoost` and `MuonLLBg` repeat a lot of 'scaffolding' -- when the only difference is which `MuonPid` member function is invoked at the end. So they can all be instances on a _single_ template implementation, where the template argument is the member function to invoke.
>
> Basically, one can (should!) implement a `GenericMuonPidFunctor` such that one can write:
> ```
> using MuonCatBoost = GenericMuonPidFunctor< &MuonPid::muonMVA2>;
> using MuonLLBg = GenericMuonPidFunctor< &MuonPid::MuonLLBg >;
> using MuonChi2Corr = GenericMuonPidFunctor< &MuonPid::chi2Corr >;
> ```
> see eg [this demonstrator on godbolt](https://godbolt.org/z/Wa6GTszzx)https://gitlab.cern.ch/lhcb/Rec/-/issues/531Verify check for small determinant in PatPV3DFuture xPointParameters2024-01-19T15:06:07+01:00Andre GuntherVerify check for small determinant in PatPV3DFuture xPointParametersUsually the determinant is checked for consistency with zero as this means that the matrix has no inverse. https://gitlab.cern.ch/lhcb/Rec/-/blob/6c5b74f8751f8d2ccca1c86abf98e045bb7a9e5f/Tr/PatPV/src/PatPV3DFuture.cpp#L343 checks for an ...Usually the determinant is checked for consistency with zero as this means that the matrix has no inverse. https://gitlab.cern.ch/lhcb/Rec/-/blob/6c5b74f8751f8d2ccca1c86abf98e045bb7a9e5f/Tr/PatPV/src/PatPV3DFuture.cpp#L343 checks for an arbitrary value of smaller than 10e-6.
The following discussion from !3612 should be addressed:
- [ ] @gunther started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3612#note_7215314): (+8 comments)
> is this correct? usually you only need to test if the determinant is zeroAgnieszka DziurdaMaciej Artur GizaAgnieszka Dziurdahttps://gitlab.cern.ch/lhcb/Rec/-/issues/530Revist necessity of std::map as container for Muon tracks in NNMuonTrack2024-01-18T20:35:28+01:00Andre GuntherRevist necessity of std::map as container for Muon tracks in NNMuonTrackThe following discussion from !3484 should be addressed:
- [ ] @gunther started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3484#note_7409700): (+16 comments)
> is there any reason to fill the pointers to muon ...The following discussion from !3484 should be addressed:
- [ ] @gunther started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3484#note_7409700): (+16 comments)
> is there any reason to fill the pointers to muon clusters into an (ordered) map starting with an arbitrary key? why not push them into a vector?https://gitlab.cern.ch/lhcb/Rec/-/issues/527Assert fail in PrResidualSciFiHits2024-01-18T18:34:24+01:00Rosen MatevAssert fail in PrResidualSciFiHitshttps://gitlab.cern.ch/lhcb/LHCb/-/blob/1b815ab008bf2f7e47a64df440c1944909449afb/Event/TrackEvent/include/Event/PrSciFiHits.h#L186 fails on PbPb data
```
./LHCb/InstallArea/x86_64_v2-el9-gcc12-dbg/include/Event/PrSciFiHits.h:186: size_t...https://gitlab.cern.ch/lhcb/LHCb/-/blob/1b815ab008bf2f7e47a64df440c1944909449afb/Event/TrackEvent/include/Event/PrSciFiHits.h#L186 fails on PbPb data
```
./LHCb/InstallArea/x86_64_v2-el9-gcc12-dbg/include/Event/PrSciFiHits.h:186: size_t LHCb::Pr::FT::details::Hits::size() const: Assertion `m_x.size() == m_coldHitPart.size()' failed.
libc.so.6!__pthread_kill_implementation (Unknown Source:0)
libc.so.6!raise (Unknown Source:0)
libc.so.6!abort (Unknown Source:0)
libc.so.6!__assert_fail_base.cold (Unknown Source:0)
libc.so.6!__assert_fail (Unknown Source:0)
libPrAlgorithms.so!LHCb::Pr::FT::details::Hits::size(const LHCb::Pr::FT::details::Hits * const this) (/home/rmatev/stack/LHCb/InstallArea/x86_64_v2-el9-gcc12-dbg/include/Event/PrSciFiHits.h:186)
libPrAlgorithms.so!LHCb::Pr::FT::ResidualHits::operator()(const LHCb::Pr::FT::ResidualHits * const this, evtCtx, tracks, const LHCb::Pr::FT::Hits & fthits) (/home/rmatev/stack/Rec/Pr/PrAlgorithms/src/PrResidualSciFiHits.cpp:89)
[Unknown/Just-In-Time compiled code] (Unknown Source:0)
libPrAlgorithms.so!Gaudi::Functional::details::put<LHCb::Pr::Long::Tracks, LHCb::Pr::Long::Tracks, void>( out_handle, out) (/home/rmatev/stack/Gaudi/InstallArea/x86_64_v2-el9-gcc12-dbg/include/GaudiAlg/FunctionalDetails.h:179)
libPrAlgorithms.so!LHCb::Pr::Long::Tracks::~Tracks(LHCb::Pr::Long::Tracks * const this) (/home/rmatev/stack/LHCb/InstallArea/x86_64_v2-el9-gcc12-dbg/include/Event/PrLongTracks.h:53)
libPrAlgorithms.so!Gaudi::Functional::details::Transformer<LHCb::Pr::Long::Tracks (LHCb::Pr::Velo::Tracks const&, LHCb::Pr::Seeding::Tracks const&, IPrAddUTHitsTool const&, LHCb::Detector::DeMagnet const&), Gaudi::Functional::Traits::use_<LHCb::Det::LbDD4hep::useConditionHandleFor<LHCb::Detector::DeMagnet>, Gaudi::Functional::Traits::BaseClass_t<LHCb::Det::LbDD4hep::ConditionAccessorHolder<FixTESPath<Gaudi::Algorithm> > > >, false>::execute(EventContext const&) const(const Gaudi::Functional::details::Transformer<LHCb::Pr::Long::Tracks(const LHCb::Pr::Velo::Tracks&, const LHCb::Pr::Seeding::Tracks&, const IPrAddUTHitsTool&, const LHCb::Detector::DeMagnet&), Gaudi::Functional::Traits::use_<LHCb::Det::LbDD4hep::useConditionHandleFor<LHCb::Detector::DeMagnet>, Gaudi::Functional::Traits::BaseClass_t<LHCb::Det::LbDD4hep::ConditionAccessorHolder<FixTESPath<Gaudi::Algorithm> > > >, false> * const this, ctx) (/home/rmatev/stack/Gaudi/InstallArea/x86_64_v2-el9-gcc12-dbg/include/GaudiAlg/Transformer.h:74)
libAlgflowManagerComp.so!Online::AlgWrapper::execute(const Online::AlgWrapper * const this, EventContext & evtCtx, gsl::span<LHCb::Interfaces::ISchedulerConfiguration::State::AlgState, 18446744073709551615> AlgoStates) (/home/rmatev/stack/Online/Online/AlgFlowManager/components/ControlFlowNode.h:184)
libAlgflowManagerComp.so!Online::BasicNode::execute(const Online::BasicNode * const this, gsl::span<LHCb::Interfaces::ISchedulerConfiguration::State::NodeState, 18446744073709551615> NodeStates, gsl::span<LHCb::Interfaces::ISchedulerConfiguration::State::AlgState, 18446744073709551615> AlgStates, EventContext & evtCtx, IAlgExecStateSvc * aess, SmartIF<IProperty> & appmgr) (/home/rmatev/stack/Online/Online/AlgFlowManager/components/ControlFlowNode.cpp:126)
libAlgflowManagerComp.so!Online::AlgFlowManager::processEvent(Online::AlgFlowManager * const this, EventContext & evtContext) (/home/rmatev/stack/Online/Online/AlgFlowManager/components/AlgFlowManager.cpp:249)
libAlgflowManagerComp.so!operator()(const struct {...} * const __closure, EventContext & ctx) (/home/rmatev/stack/Online/Online/AlgFlowManager/components/AlgFlowManager.cpp:638)
libAlgflowManagerComp.so!(anonymous namespace)::EventTask<Online::AlgFlowManager::push(EventContext&&)::<lambda(EventContext&)> >::operator()(const (anonymous namespace)::EventTask<Online::AlgFlowManager::push(EventContext&&)::<lambda(EventContext&)> > * const this) (/home/rmatev/stack/Online/Online/AlgFlowManager/components/AlgFlowManager.cpp:59)
libAlgflowManagerComp.so!tbb::internal::function_task<(anonymous namespace)::EventTask<Online::AlgFlowManager::push(EventContext&&)::<lambda(EventContext&)> > >::execute(void)(tbb::internal::function_task<(anonymous namespace)::EventTask<Online::AlgFlowManager::push(EventContext&&)::<lambda(EventContext&)> > > * const this) (/cvmfs/lhcb.cern.ch/lib/lcg/releases/tbb/2020_U2-adcbe/x86_64-centos9-gcc12-dbg/include/tbb/task.h:1059)
libtbb.so.2!tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::process_bypass_loop(tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits> * const this, tbb::internal::context_guard_helper<false> & context_guard, tbb::task * t, tbb::internal::isolation_tag isolation) (/build/jenkins/workspace/lcg_release_pipeline/build/externals/tbb-2020_U2/src/tbb/2020_U2/src/tbb/custom_scheduler.h:474)
libtbb.so.2!tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits> * const this, tbb::task & parent, tbb::task * child) (/build/jenkins/workspace/lcg_release_pipeline/build/externals/tbb-2020_U2/src/tbb/2020_U2/src/tbb/custom_scheduler.h:636)
libtbb.so.2!tbb::internal::arena::process(tbb::internal::arena * const this, tbb::internal::generic_scheduler & s) (/build/jenkins/workspace/lcg_release_pipeline/build/externals/tbb-2020_U2/src/tbb/2020_U2/src/tbb/arena.cpp:196)
```
## To reproduce
Create `my_input.py`
```
from Moore import options
from glob import glob
options.simulation = False
options.geometry_version = "run3/trunk"
options.conditions_version = "master"
options.input_type = "RAW"
options.input_files = list(glob("/scratch/hlt_oper/errors/0000279xxx-0000281xxx/*.mdf"))
```
Run
```
Moore/run gaudirun.py my_input.py Moore/Hlt/Hlt2Conf/options/hlt2_PbPb_default.py
```Andre GuntherAndre Guntherhttps://gitlab.cern.ch/lhcb/Rec/-/issues/526Assign charges of velo tracks randomly2024-03-04T21:03:52+01:00Laurent DufourAssign charges of velo tracks randomlyCurrently, the charge of a VELO track in the conversion of `PrVeloTrack` to `v1::Track` is defined through its ChannelID:
```
const int firstRow = outTr->lhcbIDs()[0].channelID();
const int charge = ( firstRow % 2 == 0 ? -1 : 1...Currently, the charge of a VELO track in the conversion of `PrVeloTrack` to `v1::Track` is defined through its ChannelID:
```
const int firstRow = outTr->lhcbIDs()[0].channelID();
const int charge = ( firstRow % 2 == 0 ? -1 : 1 );
```
However, this could give us non-deterministic behaviour in tests where we only swap the magnetic field, as pointed out by Marco: https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3680#note_7403853
In addition, it's probably best to not have something random (charge) assigned by something physical (channelID).
Related: https://gitlab.cern.ch/lhcb/Rec/-/issues/524https://gitlab.cern.ch/lhcb/Rec/-/issues/524Initialise random number generator in Moore, DaVinci2023-12-13T17:06:53+01:00Laurent DufourInitialise random number generator in Moore, DaVinciAs part of a cleanup of code, see !3680, we noticed that we are no longer calling the `LbAppInit::initRndm` function as part of the initialisation of our reconstruction application. This means that we are not setting any seed for random ...As part of a cleanup of code, see !3680, we noticed that we are no longer calling the `LbAppInit::initRndm` function as part of the initialisation of our reconstruction application. This means that we are not setting any seed for random number generators. Random number generators have been used in the past to assign the charge to velo tracks, and some instances of Rndm::Flat are currently present in VPDAQ code related to clusters. In principle, we probably should expect that some random numbers are being used somewhere, in some scenarios.
To make our applications more deterministic, we should make sure we initialise the seed of the random number generator in the initialisation phase of the application. Before this was done by the RecInit algorithm, which no longer runs. It must be guaranteed that this initialisation happens very early in the application. This issue is mostly to identify how we can best implement this.
As it involves PyConf, also @sstahl's input is also much appreciated, and feel free to tag other experts on this matter.https://gitlab.cern.ch/lhcb/Rec/-/issues/523PrVELO (v1) tracks do not have their chi2 or ndf filled2023-12-11T15:57:08+01:00Laurent DufourPrVELO (v1) tracks do not have their chi2 or ndf filledAll velo tracks should have had a Kalman filter applied to them, assuming pT = 400 MeV.
While this fit is a bit premature, the result of this is still a chi2, in addition to the state. However, this chi2 does not seem to be propagated ...All velo tracks should have had a Kalman filter applied to them, assuming pT = 400 MeV.
While this fit is a bit premature, the result of this is still a chi2, in addition to the state. However, this chi2 does not seem to be propagated to the track itself, nor the v1 VELO tracks available for analyses.
(This could have been done on purpose to save space for the velo tracks, if so, this issue can be a 'not fix' @ahennequ )Maarten Van VeghelArthur Marius HennequinMaarten Van Veghelhttps://gitlab.cern.ch/lhcb/Rec/-/issues/521Can v2 tracks be cleaned up?2023-12-11T16:05:10+01:00Andre GuntherCan v2 tracks be cleaned up?The following discussion from !3644 should be addressed:
- [ ] @gunther started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3644#note_7342219): (+4 comments)
> is there any place where the v2 tracks are still u...The following discussion from !3644 should be addressed:
- [ ] @gunther started a [discussion](https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3644#note_7342219): (+4 comments)
> is there any place where the v2 tracks are still used?Michel De CianMaarten Van VeghelMichel De Cian