-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HGCAL end of life DIGITISATION update #30422
HGCAL end of life DIGITISATION update #30422
Conversation
. deprecated radiiVec to give more freedom for different parameterizations (needed for the latest fluka map) - HGcalSciNoiseMap and HGCHEbackSignalScalerAnalyzer . propagation of the depcreation of radiiVec - HGCalSiNoiseMap . adding method to get Si operation characteristics independently of the DetId . adding the split of the noise components
…t for reference on purpose
. propagating deprecation of radiiVec
. removing HGCROCv2 backward compatibility . introducing a cache to avoild re-evaluating radius, fluence and all the parameters for Si
- added a core struct with the minimal set of variables used in the digitizer - added method to use the cache based on +z DetIds . HGCSiNoiseMapAnalyzer and HGCDigitizerBase - propagated the change in api introduced above
. introducing gain-dependent pulse shapes according to tables from D. Thienpont . adding two additional bits to dose algo to disable gain-dependent pulse shape and usage of cache - HGCFEElectronics . adding method to retrieve default ADC pulse shape configured via phyton . adding optional adcPulse argument to run shaper methods - HGCDigitizerBase . propagation of the changes above
setGeometry method now takes care of filling the operation cache cache filled from the list of valid DetIds from geometry insted of dynamically from DetIds received. This avoids having to query if DetId is already existing in the cache. Given there is no need to have a fast query on the cache, switched from unordered_map to a standard map to reduce memory footprint - HGCDigitizerBase propagation of the changes above
Hgcal eol pulse update 112 x bis
- disable cached op by default
. update pad area for latest sensor specs
. update surface of pads . modify logic of auto-gain
please test |
please test |
The tests are being triggered in jenkins.
|
Pull request #30422 was updated. @cmsbuild, @civanch, @kpedro88, @mdhildreth can you please check and sign again. |
+1 |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
+1 @franzoni , I agree with Kevin, that this type of data should not be inside sub-directory but is an external data (but definition - it come our of external source and has non-negligible size). |
hello @kpedro88 @civanch , what is the policy for files to go to external ? If appears a little bit of an overkill to us, it's a few kB. However, if the policy is this file ought to go to external, we will do that. In which case, It would be very helpful for us if this PR could make pre2. |
9kB is definitely not a huge penalty in terms of space. Space that, in any case, we have to pay through the externals anyway. So, I'm really questioning what the added value is to have it in a separate repository? |
+upgrade |
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @silviodonato, @dpiparo (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
We've documented in detail the content of this PR in yesterday's HGCAL DPG meeting https://indico.cern.ch/event/931566/
1 . Electronics specifications updated from HGCROCV2 to V3
2 . Leakage of amplitude from BX-1 updated and made gain specific
3 . fluence updated to latest maps from bril
4 . logic to detect optimal HGCROCv3 gain slightly modified to favor the MIP peak in the [8-15] ADC range
All these changes won't affect the HGCAL DIGI in startup.
They all affect only DIGI the end-of-life configuration (
SLHCUpgradeSimulations/Configuration/aging.customise_aging_3000
).PR validation:
We've run workflow 23434 w/ and w/o customisation for ageing at 3000/fg. No significant changes in the startup. CPU time per event decreases in the 3000/fb scenario by a few seconds, driven by the reduction in hit occupancy