Boole issueshttps://gitlab.cern.ch/lhcb/Boole/-/issues2023-11-17T19:29:19+01:00https://gitlab.cern.ch/lhcb/Boole/-/issues/22Remove obsolete Run1 and Run2 datatypes and introduce Run3 and placeholder fo...2023-11-17T19:29:19+01:00Gloria CortiRemove obsolete Run1 and Run2 datatypes and introduce Run3 and placeholder for Run4 and 5Remove datatypes for Run1 and Run2 that are not supported in this version of Boole.
Replace Upgrade datatype that is too generic with 2022, 2023, 2024, and Run3/2026
- introduce control of detectors configuration via 2022 (no UT), 2023 ...Remove datatypes for Run1 and Run2 that are not supported in this version of Boole.
Replace Upgrade datatype that is too generic with 2022, 2023, 2024, and Run3/2026
- introduce control of detectors configuration via 2022 (no UT), 2023 (no UT? but could be added on demand?) and 2024 datatypes
Introduce placeholder for Run4 and Run5
- could it also be used for steering with bypass (Manuel's code) for those detectors that don't have raw banks?
cc: @kreps, @mwhitehe, @edelucia , @zexu, @cattanemhttps://gitlab.cern.ch/lhcb/Boole/-/issues/21introuduce pre-commit checks in CI job for formatting2023-10-20T16:35:13+02:00Gloria Cortiintrouduce pre-commit checks in CI job for formattingThe following discussion from !519 should be addressed:
- [ ] @gcorti started a [discussion](https://gitlab.cern.ch/lhcb/Boole/-/merge_requests/519#note_7167113): (+2 comments)
> Why is this needed?
Introduce the pre-commit check...The following discussion from !519 should be addressed:
- [ ] @gcorti started a [discussion](https://gitlab.cern.ch/lhcb/Boole/-/merge_requests/519#note_7167113): (+2 comments)
> Why is this needed?
Introduce the pre-commit checks like in Gauss, see lhcb/Gauss!864https://gitlab.cern.ch/lhcb/Boole/-/issues/18Boole simulation with DD4hep (Test using dataset produced with DetDesc, Test ...2023-11-17T15:49:55+01:00Zehua XuBoole simulation with DD4hep (Test using dataset produced with DetDesc, Test using dataset produced with DD4hep)related issue in conditions: https://gitlab.cern.ch/lhcb-conddb/lhcb-conditions-database/-/issues/9
**1. Boole with DD4hep, tested using DetDesc samples**
> VP (related issue: https://gitlab.cern.ch/lhcb/Boole/-/issues/17):
- [x] Access...related issue in conditions: https://gitlab.cern.ch/lhcb-conddb/lhcb-conditions-database/-/issues/9
**1. Boole with DD4hep, tested using DetDesc samples**
> VP (related issue: https://gitlab.cern.ch/lhcb/Boole/-/issues/17):
- [x] Access DD4hep geometry (https://gitlab.cern.ch/lhcb/Boole/-/merge_requests/461;)
- [ ] Access YAML conditions (related MR: https://gitlab.cern.ch/lhcb/Boole/-/merge_requests/456;https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/374)
- [ ] Get through the test
- [x] Simulation conditions (related MR: https://gitlab.cern.ch/lhcb-conddb/lhcb-conditions-database/-/merge_requests/60)
> FT:
- [x] Access DD4hep geometry
- [x] Access YAML conditions (related MR: https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/340; https://gitlab.cern.ch/lhcb/Boole/-/merge_requests/444)
- [x] Get through the test
- [ ] Simulation conditions (related MR: https://gitlab.cern.ch/lhcb-conddb/lhcb-conditions-database/-/merge_requests/85,https://gitlab.cern.ch/lhcb-conddb/lhcb-conditions-database/-/merge_requests/92)
> UT (related issue: https://gitlab.cern.ch/lhcb/Boole/-/issues/15):
- [x] Access DD4hep geometry (related MR: https://gitlab.cern.ch/lhcb/Boole/-/merge_requests/476)
- [x] Access YAML conditions (LHCb conditions database)
- [x] Get through the test (https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/395 https://gitlab.cern.ch/lhcb/Lbcom/-/merge_requests/678, https://gitlab.cern.ch/lhcb/Lbcom/-/merge_requests/667;)
- [ ] Simulation conditions
> Rich (related issue: https://gitlab.cern.ch/lhcb/Boole/-/issues/16):
- [x] Access DD4hep geometry (Detector)
- [x] Access YAML conditions (LHCb conditions database)
- [x] Get through the test
- [ ] Simulation conditions
> MUON:
- [x] Access DD4hep geometry (https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/386)
- [x] Access YAML conditions (LHCb conditions database)
- [x] Get through the test
- [ ] Simulation conditions
> Calo:
- [x] Access DD4hep geometry (Detector)
- [x] Access YAML conditions (LHCb conditions database)
- [x] Get through the test
- [ ] Simulation conditions
> Overall:
- [ ] Baseline test
**2. Boole with DD4hep, tested using DD4hep samples**
> VP:
- [ ] Access DD4hep geometry (https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/406 , https://gitlab.cern.ch/lhcb-conddb/DDDB/-/merge_requests/122 , https://gitlab.cern.ch/lhcb/Boole/-/merge_requests/461 )
- [ ] Access YAML conditions (related MR: https://gitlab.cern.ch/lhcb/Boole/-/merge_requests/456 , https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/374 , https://gitlab.cern.ch/lhcb-conddb/lhcb-conditions-database/-/merge_requests/60)
- [ ] Get through the test
- [ ] Simulation conditions
> FT:
- [ ] Access DD4hep geometry (Detector)
- [ ] Access YAML conditions (LHCb conditions database)
- [ ] Get through the test
- [ ] Simulation conditions
> UT:
- [ ] Access DD4hep geometry (Detector)
- [ ] Access YAML conditions (LHCb conditions database)
- [ ] Get through the test
- [ ] Simulation conditions
> Rich:
- [ ] Access DD4hep geometry (Detector)
- [ ] Access YAML conditions (LHCb conditions database)
- [ ] Get through the test
- [ ] Simulation conditions
> MUON:
- [ ] Access DD4hep geometry (https://gitlab.cern.ch/lhcb/Detector/-/merge_requests/386)
- [ ] Access YAML conditions (LHCb conditions database)
- [ ] Get through the test
- [ ] Simulation conditions
> Calo:
- [ ] Access DD4hep geometry (Detector)
- [ ] Access YAML conditions (LHCb conditions database)
- [ ] Get through the test
- [ ] Simulation conditions
> PLUME:
- [ ] Access DD4hep geometry (Detector)
- [ ] Access YAML conditions (LHCb conditions database)
- [ ] Get through the test
- [ ] Simulation conditions
> Overall:
- [ ] Baseline testhttps://gitlab.cern.ch/lhcb/Boole/-/issues/17test-VP with DD4hep failed2023-07-23T11:00:38+02:00Zehua Xutest-VP with DD4hep failedNightly test: https://lhcb-nightlies.web.cern.ch/nightly/lhcb-head/3609/Boole/x86_64_v2-centos7-gcc11-opt/tests#Boole_boole-VPNightly test: https://lhcb-nightlies.web.cern.ch/nightly/lhcb-head/3609/Boole/x86_64_v2-centos7-gcc11-opt/tests#Boole_boole-VPThomas LathamDavid HutchcroftThomas Lathamhttps://gitlab.cern.ch/lhcb/Boole/-/issues/15boole-UT test with DD4hep failed2023-08-31T14:36:57+02:00Zehua Xuboole-UT test with DD4hep failedNightly test: https://lhcb-nightlies.web.cern.ch/nightly/lhcb-head/3609/Boole/x86_64_v2-centos7-gcc11-opt/tests#Boole_boole-UTNightly test: https://lhcb-nightlies.web.cern.ch/nightly/lhcb-head/3609/Boole/x86_64_v2-centos7-gcc11-opt/tests#Boole_boole-UTHangyi WuHangyi Wuhttps://gitlab.cern.ch/lhcb/Boole/-/issues/12Do not use CondDB for UTCommonModeSim cut parameter2022-11-22T10:07:37+01:00Marco Clemencicmarco.clemencic@cern.chDo not use CondDB for UTCommonModeSim cut parameterThe following discussion from !432 should be addressed:
- [ ] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb/Boole/-/merge_requests/432#note_6158965):
> I disabled the possibility of getting cut parameters from condi...The following discussion from !432 should be addressed:
- [ ] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb/Boole/-/merge_requests/432#note_6158965):
> I disabled the possibility of getting cut parameters from conditions in DD4Hep builds because:
> - this kind of settings should only come from options (similar to magnet polarity and Velo opening)
> - to support the use case we need a MR in Detector as in DD4Hep conditions are only accessible as *properties* of a detector element
>
> I think this possibility should be removed for DetDesc too, but I need feedback from UT experts.https://gitlab.cern.ch/lhcb/Boole/-/issues/9MuonLowEnergy - Fix in DD4HEP builds2022-05-16T16:38:40+02:00Christopher Rob Jonesjonesc@hep.phy.cam.ac.ukMuonLowEnergy - Fix in DD4HEP buildsSee discussion in lhcb/LHCb!3510
Following issue needs to be addressed
```
MuonLowEnergy FATAL MuonBackground:: Exception throw: get():: No valid data at '/world/DownstreamRegion/Muon' StatusCode=FAILURE
```See discussion in lhcb/LHCb!3510
Following issue needs to be addressed
```
MuonLowEnergy FATAL MuonBackground:: Exception throw: get():: No valid data at '/world/DownstreamRegion/Muon' StatusCode=FAILURE
```Marco Clemencicmarco.clemencic@cern.chMarco Clemencicmarco.clemencic@cern.chhttps://gitlab.cern.ch/lhcb/Boole/-/issues/8Setting of Detector SourceID in Subdetector Encoding2022-09-09T12:51:37+02:00Adam DavisSetting of Detector SourceID in Subdetector EncodingFrom the discussion on the FEST week (2 Feb 2022), setting of the Source ID of each individual subdetector at the encoding level is (1) necessary for each subdetector and (2) necessary for any future FEST. Will require dedicated MR for e...From the discussion on the FEST week (2 Feb 2022), setting of the Source ID of each individual subdetector at the encoding level is (1) necessary for each subdetector and (2) necessary for any future FEST. Will require dedicated MR for each subdetector.
cc: @rmatev @raaij @sgambett @neufeld @gligorov @mfontana @dovombruhttps://gitlab.cern.ch/lhcb/Boole/-/issues/7Setting VELO HV for run 3 verse integrated luminosity2021-11-10T12:53:01+01:00David HutchcroftSetting VELO HV for run 3 verse integrated luminosityThe HV for the Velo pixel sensors will be kept as low as possible in the data taking to reduce the heat and so rate of radiation damage. As such the default HV is the starting value for 2022 data taking is 105V set in SIMCOND, giving the...The HV for the Velo pixel sensors will be kept as low as possible in the data taking to reduce the heat and so rate of radiation damage. As such the default HV is the starting value for 2022 data taking is 105V set in SIMCOND, giving the full 200 microns depletion depth. As the detector takes damage the HV will be increased module by module as required, so is set from SIMCOND as it will be different for each module after some running time. At 5fb^-1 integrated lumi that means below ~7mm the detector has no sensitivity at 105V, a voltage of 250V for all sensors gives at least 80 microns depletion at 5mm which gives full efficiency.
There are a number of methods to simulate different luminosities:
+ Set 1000V in SIMCOND and always have full sensitivity
+ Make a SIMCOND for each luminosity so Velo and other detectors with radiation damage have consistent parameters
+ Set a SIMCOND overlay in python in the same file that sets the luminosity to simulate [current solution]
```
from Configurables import UpdateManagerSvc
VPSensorHV = 250.0 # Volts
UpdateManagerSvc().ConditionsOverride += \
["Conditions/HardwareProperties/VP/Sensors/VP-Sensor{:03d}-HV := double HV = {}"\
.format(s,VPSensorHV) for s in range(208)]
print("Set VP HV to {} V".format(VPSensorHV))
```
Added to Boole options (from v43r0 onwards) or for earlier Boole versions (set from an option):
```
from Configurables import VPDepositCreator
VPDepositCreator().BiasVoltage = 250.0
```https://gitlab.cern.ch/lhcb/Boole/-/issues/2Enable again VPDepositCreator in DD4hep2021-05-05T15:15:50+02:00Giovanni CavalleroEnable again VPDepositCreator in DD4hepVP digitisation has been temporarily disabled to fix Boole compilation when using the dd4hep flag. It allows Plume developments to continue until DeVP in DD4hep/Boole is integrated. See !338VP digitisation has been temporarily disabled to fix Boole compilation when using the dd4hep flag. It allows Plume developments to continue until DeVP in DD4hep/Boole is integrated. See !338