Detector merge requestshttps://gitlab.cern.ch/lhcb/Detector/-/merge_requests2024-03-26T15:53:47+01:00https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/524Add SMOG2 (again)2024-03-26T15:53:47+01:00Marco SantimariaAdd SMOG2 (again)Opening a new MR to add SMOG2 due to several changes since https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/280Opening a new MR to add SMOG2 due to several changes since https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/280Gloria CortiGloria Cortihttps://gitlab.cern.ch/lhcb/Detector/-/merge_requests/471Draft: Multiple scattering in dd4hep2024-03-27T11:38:52+01:00Andrii UsachovDraft: Multiple scattering in dd4hepCompute material parameters that are needed for multiple scattering corrections.
Not yet ready, for discussion
Next steps
- [x] make a test returning the list of materials from dd4hep
- [x] compare the spread of particles from the part...Compute material parameters that are needed for multiple scattering corrections.
Not yet ready, for discussion
Next steps
- [x] make a test returning the list of materials from dd4hep
- [x] compare the spread of particles from the particle gun with what the extrapolator computes, and see what happens
@bcouturi @mveghel @dovombru @decianm
Goes with Rec!3686, related to https://gitlab.cern.ch/lhcb/Rec/-/issues/429
---
Validated by
- [ ] Core Software
- [ ] RTA
- [ ] Simulationhttps://gitlab.cern.ch/lhcb/Detector/-/merge_requests/410Add missing include in DeMuonRegion2023-11-27T10:50:31+01:00Wouter Hulsbergenwouterh@nikhef.nlAdd missing include in DeMuonRegionAdd missing include in DeMuonRegion.
Needed by muon alignment (e.g. https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3484)
@svecchi, @sattaAdd missing include in DeMuonRegion.
Needed by muon alignment (e.g. https://gitlab.cern.ch/lhcb/Rec/-/merge_requests/3484)
@svecchi, @sattaChristopher Rob Jonesjonesc@hep.phy.cam.ac.ukChristopher Rob Jonesjonesc@hep.phy.cam.ac.ukhttps://gitlab.cern.ch/lhcb/Detector/-/merge_requests/395Fix UT geometry and tracking2023-10-13T14:45:10+02:00Hangyi WuFix UT geometry and trackingWorks with following MRs
- https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/368
- https://gitlab.cern.ch/lhcb/Boole/-/merge_requests/501
- https://gitlab.cern.ch/lhcb-datapkg/PRConfig/-/merge_requests/335
- lhcb-conddb/DDDB!79 and l...Works with following MRs
- https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/368
- https://gitlab.cern.ch/lhcb/Boole/-/merge_requests/501
- https://gitlab.cern.ch/lhcb-datapkg/PRConfig/-/merge_requests/335
- lhcb-conddb/DDDB!79 and lhcb-conddb/SIMCOND!143 , to be able to produce samples (Gauss+Boole) consistent with this
This MR is to correct UT geometry flaws, including
- fix wrong stave staggering and positioning (swap X corrections between two sides, reverse staggering)
- fix overlaps
- adding UTEpsilon (1μm) between volumes to avoid surface sharing
- removing Air from UT volumes to avoid overlaps (except lvSectorHole)
- splitting lvUTPipeHeater into two "InUT" and "InMagnet" segments
- fix tracking issues
- fix `DeUT::getLayerGeom`
- fix assignment of stereo angle issue
- fix localU and localUToStrip
- other improvements
- fix End-of-stave structure
- fix UTBox dimension
- validated correspondence of stave new nickname (with new ChannelID, C/A sides) and old name (old ChannelID, a/b stations)
- improving visualization
---
Validated by
- [x] Core Software
- [x] RTA
- [x] SimulationRosen MatevBasem Khanjibasem.khanji@cern.chHangyi WuRosen Matevhttps://gitlab.cern.ch/lhcb/Detector/-/merge_requests/368DeUT implementation2023-08-07T15:40:10+02:00Hangyi WuDeUT implementationPart of the set Detector!368 LHCb!4159 Lbcom!668 Rec!3458 Boole!476 https://gitlab.cern.ch/lhcb/DaVinci/-/merge_requests/921
My dev environment is set up using [`lb-stack-setup`](https://gitlab.cern.ch/rmatev/lb-stack-setup). Below are ...Part of the set Detector!368 LHCb!4159 Lbcom!668 Rec!3458 Boole!476 https://gitlab.cern.ch/lhcb/DaVinci/-/merge_requests/921
My dev environment is set up using [`lb-stack-setup`](https://gitlab.cern.ch/rmatev/lb-stack-setup). Below are my `config.json` file contents
```json
{
"binaryTag": "x86_64_v2-centos7-gcc11-opt",
"gitBase": "ssh://git@gitlab.cern.ch:7999",
"gitBranch": {
"Detector": "ut-dd4hep",
"default": "master"
},
"lcgVersion": "103",
"useDistcc": true,
"localPoolDepth": 20,
"ccacheHostsKey": null,
"distccLocalslots": 10,
"distccLocalslotsCpp": 20,
"functorJitNJobs": 4,
"useDocker": false
}
```Basem Khanjibasem.khanji@cern.chHangyi WuBasem Khanjibasem.khanji@cern.chhttps://gitlab.cern.ch/lhcb/Detector/-/merge_requests/315Attach CALO Reconstruction conditions to Ecal2022-11-14T17:44:58+01:00Carla Marin Benitocarla.marin.benito@cern.chAttach CALO Reconstruction conditions to EcalAttach Reco conditions to Ecal
Needs https://gitlab.cern.ch/lhcb-conddb/lhcb-conditions-database/-/merge_requests/41
Addresses https://gitlab.cern.ch/lhcb/Detector/-/issues/39
- [x] Test it
FYI @jonrob @chenjiaAttach Reco conditions to Ecal
Needs https://gitlab.cern.ch/lhcb-conddb/lhcb-conditions-database/-/merge_requests/41
Addresses https://gitlab.cern.ch/lhcb/Detector/-/issues/39
- [x] Test it
FYI @jonrob @chenjiaCarla Marin Benitocarla.marin.benito@cern.chCarla Marin Benitocarla.marin.benito@cern.chhttps://gitlab.cern.ch/lhcb/Detector/-/merge_requests/286Use nlohmann::json instead of YAML::Node for in-memory condition format2022-11-08T13:52:09+01:00Marco Clemencicmarco.clemencic@cern.chUse nlohmann::json instead of YAML::Node for in-memory condition formatAs discussed in lhcb/LHCb#241 and lhcb/LHCb!3768, `YAML::Node` uses a lot of memory for relatively simple data.
With a relatively simple test I managed to dump all conditions we load in LoadDDDB as a single YAML file of 57MB and loading...As discussed in lhcb/LHCb#241 and lhcb/LHCb!3768, `YAML::Node` uses a lot of memory for relatively simple data.
With a relatively simple test I managed to dump all conditions we load in LoadDDDB as a single YAML file of 57MB and loading all 16919 entries required 2.3GB of RSS. The same kind of exercise with `nlohmann::json` requires a much more reasonable 80MB.
This MR aims to change the way we keep conditions in memory from `YAML::Node` instances to `nlohmann::json` objects. For ConditionsOverlay I replaced `YAML::Node` with its string representation.
A couple of helper functions (taken from lhcb/LHCb!3768) are used to convert between the two formats.
Note that the on-disk format of the conditions stays as YAML, which is more practical (for humans) to read and write than JSON.
YAML::Node is still used in a few places:
- to construct some objects from conditions (JSON converted to YAML on the fly)
- conditions overrides (it acts before YAML data is converted to JSON)
- both JSON and YAML are supported in couple of cases
It must be merged at the same time as lhcb/LHCb!3768.https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/285Use the correct Magnet current/polarity condition name2022-09-23T12:07:19+02:00Marco Clemencicmarco.clemencic@cern.chUse the correct Magnet current/polarity condition nameThe name of the magnet condition (with current and polarity) is different from what originally expected (see lhcb-conddb/lhcb-conditions-database!36).
This MR fixes the code (and test data) to use the name found in the conditions database.The name of the magnet condition (with current and polarity) is different from what originally expected (see lhcb-conddb/lhcb-conditions-database!36).
This MR fixes the code (and test data) to use the name found in the conditions database.Ben CouturierBen Couturierhttps://gitlab.cern.ch/lhcb/Detector/-/merge_requests/279Fix bug in FT module addressing2022-09-16T17:11:55+02:00Roel AaijFix bug in FT module addressing`id.mat()` was used instead of `id.module()`
With this the HLT1 tracking efficiencies start to look much better:
```
long_validator validation:
TrackChecker output : 865/ 10981 7.88% ghosts
for P...`id.mat()` was used instead of `id.module()`
With this the HLT1 tracking efficiencies start to look much better:
```
long_validator validation:
TrackChecker output : 865/ 10981 7.88% ghosts
for P>3GeV,Pt>0.5GeV : 865/ 10981 7.88% ghosts
01_long : 9259/ 57970 15.97% ( 15.40%), 535 ( 5.46%) clones, pur 99.71%, hit eff 96.92%
02_long_P>5GeV : 9172/ 37115 24.71% ( 23.80%), 533 ( 5.49%) clones, pur 99.71%, hit eff 96.94%
03_long_strange : 181/ 2940 6.16% ( 6.21%), 4 ( 2.16%) clones, pur 99.76%, hit eff 96.55%
04_long_strange_P>5GeV : 180/ 1401 12.85% ( 13.55%), 4 ( 2.17%) clones, pur 99.76%, hit eff 96.53%
05_long_fromB : 10/ 53 18.87% ( 19.37%), 0 ( 0.00%) clones, pur 100.00%, hit eff 97.50%
06_long_fromB_P>5GeV : 10/ 29 34.48% ( 38.19%), 0 ( 0.00%) clones, pur 100.00%, hit eff 97.50%
07_long_electrons : 92/ 4393 2.09% ( 1.84%), 4 ( 4.17%) clones, pur 98.85%, hit eff 96.00%
08_long_electrons_P>5GeV : 92/ 2190 4.20% ( 4.44%), 4 ( 4.17%) clones, pur 98.85%, hit eff 96.00%
09_long_fromB_electrons : 1/ 11 9.09% ( 3.57%), 0 ( 0.00%) clones, pur 100.00%, hit eff 100.00%
10_long_fromB_electrons_P>5GeV : 1/ 6 16.67% ( 10.00%), 0 ( 0.00%) clones, pur 100.00%, hit eff 100.00%
long_P>5GeV_AND_Pt>1GeV : 6847/ 8057 84.98% ( 87.77%), 423 ( 5.82%) clones, pur 99.71%, hit eff 97.52%
long_fromB_P>5GeV_AND_Pt>1GeV : 9/ 11 81.82% ( 85.00%), 0 ( 0.00%) clones, pur 100.00%, hit eff 98.15%
11_noVelo_UT : 0/ 6777 0.00% ( 0.00%), 0 ( 0.00%) clones, pur -nan%, hit eff -nan%
12_noVelo_UT_P>5GeV : 0/ 2776 0.00% ( 0.00%), 0 ( 0.00%) clones, pur -nan%, hit eff -nan%
13_long_PT>2GeV : 1375/ 1538 89.40% ( 90.41%), 83 ( 5.69%) clones, pur 99.71%, hit eff 97.74%
14_long_from_B_PT>2GeV : 2/ 2 100.00% (100.00%), 0 ( 0.00%) clones, pur 100.00%, hit eff 100.00%
15_long_strange_P>5GeV : 180/ 1401 12.85% ( 13.55%), 4 ( 2.17%) clones, pur 99.76%, hit eff 96.53%
16_long_strange_P>5GeV_PT>500MeV : 180/ 530 33.96% ( 34.21%), 4 ( 2.17%) clones, pur 99.76%, hit eff 96.53%
```
/cc @ldufour @gligorov @jonrobBen CouturierThomas LathamBen Couturierhttps://gitlab.cern.ch/lhcb/Detector/-/merge_requests/274Fix path for Ecal and Hcal2022-09-22T21:15:31+02:00Chenjia ZhangFix path for Ecal and HcalFix location strings for Ecal and Hcal for DD4Hep usageFix location strings for Ecal and Hcal for DD4Hep usageChenjia ZhangChenjia Zhanghttps://gitlab.cern.ch/lhcb/Detector/-/merge_requests/271Fixed orientation and other details for FT2022-08-26T16:08:19+02:00Laurent DufourFixed orientation and other details for FTThis MR captures the progress on various fixes in the DD4Hep description of the Fibre Tracker, using DetDesc as a reference to some extend.
Progress is roughly grouped as:
- [x] Fix the quadrant ordering in the first layer
- [x] Fix th...This MR captures the progress on various fixes in the DD4Hep description of the Fibre Tracker, using DetDesc as a reference to some extend.
Progress is roughly grouped as:
- [x] Fix the quadrant ordering in the first layer
- [x] Fix the quadrant ordering in all layers
- [x] Fix the mat ordering in all layers
- [x] Fix the ddx orientation in all layers
- [x] Fix the mirror points for inner most modules (& fibre length)
- [x] Check and fix the m_reversed flag for all modules/layers
- [x] Check the angles of layers wrt detdesc
- [x] Translations: fix beginning/end of sensitive material
- [x] Run Moore tests to see the differences in efficiency
Note that the DetDesc detector has inner mats which are not extending to the end, which I will not copy to DD4Hep. This means that changes in efficiency are expected, where we mostly *gain* in efficiency.
References:
- [T-Stations_light_C-Frameheight.pdf](/uploads/ec5cfbe37c50f32a37bd5f8848e9c432/T-Stations_light_C-Frameheight.pdf)
- [SciFiStation_3m_3.pdf](/uploads/7cf89ac7971428031ac99bd6b5e3571f/SciFiStation_3m_3.pdf)
- [SciFi_3k_beamhole.pdf](/uploads/e0d125e3ef20d2663e2d82fcf23ec7e8/SciFi_3k_beamhole.pdf)
@zexu @lohenry @bleverin @ppais @jonrobLaurent DufourLouis Henrylouis.henry@cern.chZehua XuLaurent Dufourhttps://gitlab.cern.ch/lhcb/Detector/-/merge_requests/267Draft: NOT TO MERGE Fix FT in DD4HEP2022-08-29T16:10:45+02:00Louis Henrylouis.henry@cern.chDraft: NOT TO MERGE Fix FT in DD4HEPGoes with Rec!3065
- It seems the stereoAngle of the layers is not propagated well: in the geometry they seem to be considered vertical.
- The calculation of size using Boxes does not work
- Moved the p.leftHoleSizeY / p..rightHoleSizeY...Goes with Rec!3065
- It seems the stereoAngle of the layers is not propagated well: in the geometry they seem to be considered vertical.
- The calculation of size using Boxes does not work
- Moved the p.leftHoleSizeY / p..rightHoleSizeY out of the 0.5 factor, for no other reason than "it seems to work"Louis Henrylouis.henry@cern.chLouis Henrylouis.henry@cern.chhttps://gitlab.cern.ch/lhcb/Detector/-/merge_requests/265Fix station numbering in findStation to match {1, 2, 3} convention2022-08-22T14:11:16+02:00Roel AaijFix station numbering in findStation to match {1, 2, 3} conventionThe access to stations through `DeFT::findStation(FTChannelID const& id)` needed stations numbered `{0, 1, 2}`, which was inconsistent with the convention used throughout the FT.The access to stations through `DeFT::findStation(FTChannelID const& id)` needed stations numbered `{0, 1, 2}`, which was inconsistent with the convention used throughout the FT.https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/263Fix layerID method in FT DD4HEP by using layerIdx2022-08-08T09:58:38+02:00Louis Henrylouis.henry@cern.chFix layerID method in FT DD4HEP by using layerIdxSee Rec#382 (@jonrob @gligorov )
Should fix properly the "layer starting from 4" issue.
For note, an even more proper fix would overhaul how IDs are inconsistent between DetDesc and DD4HEP, and how DetDesc IDs are inconsistent between ...See Rec#382 (@jonrob @gligorov )
Should fix properly the "layer starting from 4" issue.
For note, an even more proper fix would overhaul how IDs are inconsistent between DetDesc and DD4HEP, and how DetDesc IDs are inconsistent between themselves (some are indices, some are local, some are global, from what I see). I do not think this is warranted for now.
Should be merged with Rec!3055https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/261Fix test value for VP ladders position2022-08-08T09:58:33+02:00Ben CouturierFix test value for VP ladders positionFix test value for VP ladders positionFix test value for VP ladders positionhttps://gitlab.cern.ch/lhcb/Detector/-/merge_requests/259Fixes to DeVPSensor and DeVPSensorObject2022-08-08T09:58:33+02:00Thomas LathamFixes to DeVPSensor and DeVPSensorObject- Properly initialise DeVPSensorObject::zpos
- Fix DeVPSensor::getGlobalMatrixDecomposition following !209
- Add tests for the sensor positions
- [x] Need to add some more sensors and their calculated positions to the tests- Properly initialise DeVPSensorObject::zpos
- Fix DeVPSensor::getGlobalMatrixDecomposition following !209
- Add tests for the sensor positions
- [x] Need to add some more sensors and their calculated positions to the testshttps://gitlab.cern.ch/lhcb/Detector/-/merge_requests/258Avoid one string copy in RICH init_param call2022-08-08T09:58:29+02:00Christopher Rob Jonesjonesc@hep.phy.cam.ac.ukAvoid one string copy in RICH init_param callMinor cleanup..Minor cleanup..https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/249Avoid temporaries in unit transforms when not required2022-07-26T04:29:39+02:00Christopher Rob Jonesjonesc@hep.phy.cam.ac.ukAvoid temporaries in unit transforms when not requiredChristopher Rob Jonesjonesc@hep.phy.cam.ac.ukChristopher Rob Jonesjonesc@hep.phy.cam.ac.ukhttps://gitlab.cern.ch/lhcb/Detector/-/merge_requests/247Fix configuration of test_vp_ladder_position test_vp_motion tests2022-07-24T09:07:40+02:00Marco Clemencicmarco.clemencic@cern.chFix configuration of test_vp_ladder_position test_vp_motion testsThis MR fixes the way test_vp_ladder_position and test_vp_motion are run so that they actually test what they are supposed to test (see !245).
On top of that the tests where comparing quantities without taking into account the units, so...This MR fixes the way test_vp_ladder_position and test_vp_motion are run so that they actually test what they are supposed to test (see !245).
On top of that the tests where comparing quantities without taking into account the units, so they were failing when using a DD4hep built with Geant4 units.https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/246Various fixes in DeIOV concerning alignment and units2022-07-21T10:28:24+02:00Sebastien PonceVarious fixes in DeIOV concerning alignment and unitsNamely :
- fixed implementation of isInside(). Current implementation was not correct
- fixed implementation of delta(). Overcomplicated and buggy implementation was there
- introduced proper conversion of units in isInside, where ...Namely :
- fixed implementation of isInside(). Current implementation was not correct
- fixed implementation of delta(). Overcomplicated and buggy implementation was there
- introduced proper conversion of units in isInside, where we call a DD4hep method from LHCb codeSebastien PonceSebastien Ponce