Tags: eic/EICrecon
Tags
fix: don't persist without ID decoder in CalorimeterHitsMerger.cc (#1900 ) ### Briefly, what does this PR introduce? This PR fixes a stream of warnings (1 per event), for e.g. https://github.com/eic/EICrecon/actions/runs/15450609700/job/43493287707#step:7:1041: ``` Warning: HCAL:HcalBarrelMergedHits] [warning] Failed to load ID decoder for HcalBarrelHits IDDescriptor ERROR dd4hep: Attempt to access an invalid IDDescriptor object. ``` This occurs for craterlake_tracking_only, or any geometry without HCalBarrel. Instead of merely not throwing, we should return if the ID decoder cannot be found. ### What kind of change does this PR introduce? - [x] Bug fix (issue: excessive warnings) - [ ] New feature (issue #__) - [ ] Documentation update - [ ] Other: __ ### Please check if this PR fulfills the following: - [ ] Tests for the changes have been added - [ ] Documentation has been added / updated - [ ] Changes have been communicated to collaborators ### Does this PR introduce breaking changes? What changes might users need to make to their code? No. ### Does this PR change default behavior? No.
fix(ci): prevent uncontrolled ccache growth with 7d eviction (#1855) ### Briefly, what does this PR introduce? It is my suspicion that the ccache is larger than needed, and it results in evictions from the github actions cache. By doing some eviction inside the ccache, we will hopefully limit this. As an example, the incoming 1036 MB cache in https://github.com/eic/EICrecon/actions/runs/14887400044/job/41810570776?pr=1855#step:4:39 is reduced to 533 MB in https://github.com/eic/EICrecon/actions/runs/14887400044/job/41810570776?pr=1855#step:25:5. ### What kind of change does this PR introduce? - [x] Bug fix (issue: ccache grow too large) - [ ] New feature (issue #__) - [ ] Documentation update - [ ] Other: __ ### Please check if this PR fulfills the following: - [ ] Tests for the changes have been added - [ ] Documentation has been added / updated - [ ] Changes have been communicated to collaborators ### Does this PR introduce breaking changes? What changes might users need to make to their code? No. ### Does this PR change default behavior? No.
[Backport v1.24] Use pixel-style MPDG readout for tracking until effi… …ciency issues are resolved (#1819) (#1820) As presented in the tracking WG meeting ([https://indico.bnl.gov/event/27589/contributions/105659/attachments/60986/104773/tracking1_040325.pdf](https://indico.bnl.gov/event/27589/contributions/105659/attachments/60986/104773/tracking1_040325.pdf)), the updated 2D MPGD digitization leads to inefficiencies for the Barrel MPGD. This PR restores the previous digitization scheme as the default, where the hits are used in the track reconstruction with high efficiency. Once the 2D readout can demonstrate comparable results, we will switch over. Results with 2D digitization: <img width="647" alt="image1" src="https://github.com/user-attachments/assets/5785ed7a-faa3-44d7-a8ba-b566edde82b8" /> Results with pixel-style (SVT-like) digitization: <img width="653" alt="image2" src="https://github.com/user-attachments/assets/217d8ae4-7d7f-4a65-9b49-ce1b6a5bc4a7" /> - [ ] Bug fix (issue #__) - [ ] New feature (issue #__) - [ ] Documentation update - [ ] Other: __ - [x] Tests for the changes have been added - [ ] Documentation has been added / updated - [x] Changes have been communicated to collaborators @ShujieL @ybedfer need to make to their code? No Yes, it restores previous barrel MPGD digitization scheme as default. (cherry picked from commit b2d0890) Co-authored-by: Barak Schmookler <bschmookler1@gmail.com>
LGADPulseGeneration -> SiliconPulseGeneration, LGADPulseDigitization … …-> EICROCDigitization (#1778) ### Briefly, what does this PR introduce? ### What kind of change does this PR introduce? - [ ] Bug fix (issue #__) - [x] New feature (issue #__) - [ ] Documentation update - [ ] Other: __ ### Please check if this PR fulfills the following: - [ ] Tests for the changes have been added - [ ] Documentation has been added / updated - [ ] Changes have been communicated to collaborators ### Does this PR introduce breaking changes? What changes might users need to make to their code? LGADPulseGeneration class is removed in favor of SiliconPulseGeneration class. Added a SiliconPulseDiscretization class to convert the smooth pulse from SiliconPulseGeneration to it's discretized form with size of time bin set to be equal to that of BTOF LGAD clock cycle. LGADPulseDigitization is renamed to SiliconPulseDigitization for a unified naming scheme. ### Does this PR change default behavior? BTOF now uses Silic FB0D onPulseGeneration. --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
feat: support CartesianStripZ in CalorimeterHitReco (#1717) ### Briefly, what does this PR introduce? This PR adds support for CartesianStripZ (EcalBarrelScFiHits) in CalorimeterHitReco writing of hit dimensions. This therefore resolves the warning that there is no support. ### What kind of change does this PR introduce? - [ ] Bug fix (issue #__) - [x] New feature (issue: CartesianStripZ suport in CalorimeterHitReco for EcalBarrelScFiHits) - [ ] Documentation update - [ ] Other: __ ### Please check if this PR fulfills the following: - [ ] Tests for the changes have been added - [ ] Documentation has been added / updated - [ ] Changes have been communicated to collaborators ### Does this PR introduce breaking changes? What changes might users need to make to their code? No. ### Does this PR change default behavior? No. --------- Co-authored-by: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
Enable calorimeter hit merging by functions (#1668) ### Briefly, what does this PR introduce? This PR extends the functionality of the `CalorimeterHitsMerger` algorithm. Previously, reconstructed hits could only be merged across a given field of the readout of a calorimeter. This presents a challenge for calorimeters such as the Barrel HCal where 1. our readout has no segmentation beyond just eta & phi, and 2. it could be useful to study the response of the detector as a function of how many readout channels we gang together after reconstruction. This PR addresses this point by utilizing the `EvaluatorSvc` in a manner similar to the `adjacencyMatrix`, `peakNeighbourhoodMatrix` of the `CalorimeterIslandClustering` and the `sampFrac` of `CalorimeterHitReco`. Now the user has the ability to specify an (almost) arbitrarily complex transformation for a specific field of the readout via the `fieldTransformations` parameter, which defines both the field to transform and the function to map the indices of that field onto the desired reference indices. For example: ``` app->Add(new JOmniFactoryGeneratorT<CalorimeterHitsMerger_factory>( "HcalBarrelMergedHits", {"HcalBarrelRecHits"}, {"HcalBarrelMergedHits"}, { .readout = "HcalBarrelHits", .fieldTransformations = {"phi:phi-(5*((phi/5)-floor(phi/5)))"} }, app // TODO: Remove me once fixed )); ``` Here, the `HcalBarrelMergedHits` collection will merge 5 hits (i.e. scintillator tiles for the BHCal) adjacent in phi into a one with the position and cellID of the 1st of the 5, and no hits will be merged along eta. The previous behavior of the algorithm can be recovered by simply specifying the index to be mapped onto. For example: ``` app->Add(new JOmniFactoryGeneratorT<CalorimeterHitsMerger_factory>( "HcalEndcapNMergedHits", {"HcalEndcapNRecHits"}, {"HcalEndcapNMergedHits"}, { .readout = "HcalEndcapNHits", .fieldTransformations = {"layer:4", "slice:0"} }, app // TODO: Remove me once fixed )); ``` An example script of to change a transformation (and how to update the adjacency matrix accordingly) from the command-line is provided in the snippets repo [here](https://github.com/eic/snippets/blob/main/Calorimetery/CaloDebugTools/UtilityScripts/RunEICReconWithTileMerging.rb). ### What kind of change does this PR introduce? - [ ] Bug fix (issue #__) - [x] New feature (issue #1669 ) - [ ] Documentation update - [ ] Other: __ ### Please check if this PR fulfills the following: - [ ] Tests for the changes have been added - [ ] Documentation has been added / updated - [x] Changes have been communicated to collaborators ### Does this PR introduce breaking changes? What changes might users need to make to their code? No. ### Does this PR change default behavior? No. --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
PreviousNext