Run2Support issueshttps://gitlab.cern.ch/lhcb/Run2Support/-/issues2023-08-24T11:24:21+02:00https://gitlab.cern.ch/lhcb/Run2Support/-/issues/13VPDet Test failing in DD4HEP slots2023-08-24T11:24:21+02:00Christopher Rob Jonesjonesc@hep.phy.cam.ac.ukVPDet Test failing in DD4HEP slotsSee e.g.
https://lhcb-nightlies.web.cern.ch/nightly/lhcb-master/2135/Run2Support/x86_64_v2-centos7-gcc12-dbg/tests#VPDet_veloaligncond_updates_yaml_pyconf
Appears to be related to when support for the BeamSpot condition was recently ad...See e.g.
https://lhcb-nightlies.web.cern.ch/nightly/lhcb-master/2135/Run2Support/x86_64_v2-centos7-gcc12-dbg/tests#VPDet_veloaligncond_updates_yaml_pyconf
Appears to be related to when support for the BeamSpot condition was recently added.
```
VeloAlignCond VERBOSE Making transformation matrix for '/VPRight' Correcting for motion system position.
LHCb__DetDesc__TestBeamSpot_11d9... ERROR Wrong DataObjectType : The type expected for /Event/IOVLock is AnyDataWrapper<std::shared_ptr<dd4hep::cond::ConditionsSlice> > and is different from the one of the object in the store which is ICondIOVResource::IOVLock.
LHCb__DetDesc__TestBeamSpot_11d9... ERROR Maximum number of errors ( 'ErrorMax':1) reached.
HLTControlFlowMgr FATAL Event failed in Node LHCb__DetDesc__TestBeamSpot/LHCb__DetDesc__TestBeamSpot_11d983b1 : Error in algorithm execute
```
In an effort to clean in the test results in the nightlies it would be good to address this.
FYI @cattanem @gcorti @rmatev @raaijhttps://gitlab.cern.ch/lhcb/Run2Support/-/issues/12Move Event Model to Run2 namespace for Lamarr use2023-10-20T19:17:51+02:00Adam DavisMove Event Model to Run2 namespace for Lamarr useTo use Lamarr with both Run12 and Run3 event models, must be able to compile and talk to both. This means the porting of
Kernel/LHCbKernel
Event/TrackEvent
Event/DigiEvent
Event/RecEvent
Event/PhysEvent
from LHCb run2-patches to Ru...To use Lamarr with both Run12 and Run3 event models, must be able to compile and talk to both. This means the porting of
Kernel/LHCbKernel
Event/TrackEvent
Event/DigiEvent
Event/RecEvent
Event/PhysEvent
from LHCb run2-patches to Run2Support into the Run2 namespace.
MRs which do this:
- [Run2Support!37 : LHCbKernel and TrackEvent](https://gitlab.cern.ch/lhcb/Run2Support/-/merge_requests/37)
- [Run2Support!38 : DigiEvent](https://gitlab.cern.ch/lhcb/Run2Support/-/merge_requests/38)
- [Run2Support!40 : RecEvent](https://gitlab.cern.ch/lhcb/Run2Support/-/merge_requests/40)
- [Run2Support!41 : PhysEvent](https://gitlab.cern.ch/lhcb/Run2Support/-/merge_requests/41)
- [Run2Support!42 : Top level CMakeLists](https://gitlab.cern.ch/lhcb/Run2Support/-/merge_requests/42)
- [Run2Support!44 : Add Event Packer for Run2 namespace wrapped EDM](https://gitlab.cern.ch/lhcb/Run2Support/-/merge_requests/44)
Already note that LHCb::ParticleID is not ported as there is no difference between master and current. Should this change, it will also need to be ported.
To ensure that the data written with this can be read by older versions of DaVinci (which do not know about the Run2 namespace), one should write the packed event model to DST, at which point downstream software does not need to know about namespacing (@clemenci 's idea).Gloria CortiMichal KrepsAdam DavisLucio AnderliniGloria Corti2023-04-14https://gitlab.cern.ch/lhcb/Run2Support/-/issues/7Review unification of CaloCellID when branching off for Sim102023-10-20T19:19:00+02:00Gloria CortiReview unification of CaloCellID when branching off for Sim10Need to verify if CaloChannelID for Run3 as used here from Detector::Calo is fully compatible with the one needed for Run1&Run2Need to verify if CaloChannelID for Run3 as used here from Detector::Calo is fully compatible with the one needed for Run1&Run2https://gitlab.cern.ch/lhcb/Run2Support/-/issues/5Port CaloUtils and CaloInterfaces from LHCb as for Run3 they are replaced by ...2022-08-29T19:19:36+02:00Gloria CortiPort CaloUtils and CaloInterfaces from LHCb as for Run3 they are replaced by CaloFutureXXXThe following discussion from lhcb/Gauss!861 should be addressed:
- [ ] @gcorti started a [discussion](https://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/861#note_5658416): (+4 comments)
> Something like this will be needed to tar...The following discussion from lhcb/Gauss!861 should be addressed:
- [ ] @gcorti started a [discussion](https://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/861#note_5658416): (+4 comments)
> Something like this will be needed to target `Futurev4` for Gauss-on-Gaussino.
>
> Determining now if Gauss will be released on LHCb v53r8p1, so we may not pick this up if it depends on lhcb/LHCb!3860
>
> cc: @kreps, @adavis, @mimazure
These are needed only by Lamarr