athena merge requestshttps://gitlab.cern.ch/atlas/athena/-/merge_requests2022-11-30T21:43:40+01:00https://gitlab.cern.ch/atlas/athena/-/merge_requests/58524Tune sTGC simulation charge to data2022-11-30T21:43:40+01:00Alexandre LaurierTune sTGC simulation charge to dataImprove upon the sTGC digitization to better reproduce the charge that are measured within the latest data.
Currently in master, the total charge created per hit is about 4x too high, caused by an incorrect tuning of the sTGC digitizatio...Improve upon the sTGC digitization to better reproduce the charge that are measured within the latest data.
Currently in master, the total charge created per hit is about 4x too high, caused by an incorrect tuning of the sTGC digitization. The simulation uses test beam data running at HV>=2.9kV to tune the digitization and this does not represent current running conditions.
We now decide to make the gas gain due to the electron avalanche a tuneable parameter according to the running conditions of the sTGC HV. The HV parameter must be in units of kV. The gas gain is parameterized from a fit to data and simulation described in ATL-MUON-PUB-2014-001.
The latest distributions of cluster strip multiplicity and channel charge are in much better agreement to data than what master can produce.
Results already presented to the muon SW coordination group and the NSW software integration team. Approach approved by sTGC digitization team.
Tagging @chchau @dpizzihttps://gitlab.cern.ch/atlas/athena/-/merge_requests/58075Improve sTGC simulation of VMM to better handle deadtime and strip neighborOn...2022-11-20T21:42:00+01:00Alexandre LaurierImprove sTGC simulation of VMM to better handle deadtime and strip neighborOn logicGoal is to improve the behaviour of the VMM simulation in the sTGC digitization. Previously, the behaviour of the VMM was taken care of by the VMMSim class which was slow, confusing to read and underperforming in some cases. Previous VMM...Goal is to improve the behaviour of the VMM simulation in the sTGC digitization. Previously, the behaviour of the VMM was taken care of by the VMMSim class which was slow, confusing to read and underperforming in some cases. Previous VMM simulation would track the state of channels through dead/ready/read states for small time steps which could be computationally heavy and the code was very impractical to read. Most importantly, the old VMM simulation was describing the deprecated VMM version 2 instead of the installed VMM3. The deadtime and neighborOn logic changed between VMM2 and VMM3, making the current VMM description deprecated. The current VMM deadtime parameters follow the best estimates from the VMM3 design specifications.
This MR will resolve and close issue outlined in ATLASSIM-3531 by correctly creating 1 SDO per final saved Digit.
Output digit container, RDO container and SDO container are all expected to change and break tests.
We now streamline the whole sTGC DigitizationTool so that the processing of VMM deadtime and strip neighbourOn logic is clear to follow. Some important values for the VMM can now be directly controlled via the python steering scripts instead of having to manually change txt files.
The basic logic for the new VMM simulation is as follows:
1. If two digits are within the VMM merging time window of 30ns, the 2nd digit in time is merged within the 1st one.
2. If a digit is above the VMM charge threshold it triggers the VMM to read the charge (save the digit to final container) and causes all following digits in the VMM deadtime window to be lost due to the VMM being in a dead state.
3. For strips, also apply neighbourOn logic.
The VMM neighbourOn for strips functions by saving strip digits below threshold if an immediate neighbour strip is saved to VMM by having charge above threshold within a reasonable time window. The coded logic follows:
1. Follow the same hit merging and deadtime logic described above.
2. If the current strip digit is below threshold, look at the 2 immediate neighbours for above threshold digits within the time window. This informs the decision of saving the current strip digit to VMM or not. This is the simplest implementation since we process 1 strip at the time instead of 1 + 2 neighbours.
This logic was chosen so that we can keep a neat and simple time-ordering of the saved digits, and so that strips are processed exactly 1 at the time.
Cleaned up and more final version of !57672.
Testing is finished and new logic works as intended. Approval received to merge MR from the sTGC software group and the muon software dev team.
@chchauhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/48161Correct pixel delta ray threshold in pixel digitisation2021-11-24T15:42:26+01:00Anthony MorleyCorrect pixel delta ray threshold in pixel digitisationCorrect pixel delta ray threshold in pixel digitisation and some comments to highlight that there is a link between the range cut in simulation and the energy threshold in the digitisation.
@battagl @stsuno @gfacini @srettie @vcairoCorrect pixel delta ray threshold in pixel digitisation and some comments to highlight that there is a link between the range cut in simulation and the energy threshold in the digitisation.
@battagl @stsuno @gfacini @srettie @vcairohttps://gitlab.cern.ch/atlas/athena/-/merge_requests/46600Fix bug in MergeTruthJetsTool where only the first event from each bunch-cros...2021-09-22T11:01:15+02:00John Derek ChapmanFix bug in MergeTruthJetsTool where only the first event from each bunch-crossing was checked.This one is needed for the Presampled RDO production for the Run-2 Reprocessing.
Thanks to @dandoy for spotting this bug which had been lurking for 3 years!
FYI @tlari, @mduehrss, @tadej, @pberta, @rmazini, @emoyse, @elmsheusThis one is needed for the Presampled RDO production for the Run-2 Reprocessing.
Thanks to @dandoy for spotting this bug which had been lurking for 3 years!
FYI @tlari, @mduehrss, @tadej, @pberta, @rmazini, @emoyse, @elmsheushttps://gitlab.cern.ch/atlas/athena/-/merge_requests/45336Add RNGWrapper::setSeedLegacy methods to support setting the random number se...2021-09-01T17:22:46+02:00John Derek ChapmanAdd RNGWrapper::setSeedLegacy methods to support setting the random number seeds the old wayThese changes make it possible to reproduce the random number seeding from the old-style `AtDSFMTGenSvc` random number service within the `RNGWrapper` for q221. In this merge request `LArPileUpTool` and `LArTTL1Maker` have been adapted t...These changes make it possible to reproduce the random number seeding from the old-style `AtDSFMTGenSvc` random number service within the `RNGWrapper` for q221. In this merge request `LArPileUpTool` and `LArTTL1Maker` have been adapted to use the old approach to setting the seeds. Unclear whether anything else needs to be switched over.
This merge request also includes a small patch to `TRT_Digitization` configuration to ensure consistency between CA-based configuration and old-style configuration. Required after the setting of `ConfigFlags.Digitization.RandomSeedOffset` was altered slightly to match how offsets to random number seeds are applied in ~"21.0".
FYI @wlampl, @tadej, @mduehrss, @zmarshalhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/45049MuonDigitization - insert property to shift t0 values between digitzation and...2021-07-12T17:16:25+02:00Johannes Junggeburthjohannes.josef.junggeburth@cern.chMuonDigitization - insert property to shift t0 values between digitzation and reconstructionHi.
in !44011 we switched on the MdtCalibrationDbTool by default as we thought that the calibration constants should be taken consistently from the database in both reconstruction and digitization. However, this caused a severe drop in ...Hi.
in !44011 we switched on the MdtCalibrationDbTool by default as we thought that the calibration constants should be taken consistently from the database in both reconstruction and digitization. However, this caused a severe drop in the muon reconstruction performance in simulation from `22.0.37` onwards (c.f the screenshot below) and was first reported by the trigger group in ATR-23768 and then mainly discussed in ATLASRECTS-6449. Actually, this development is not the cause of the feature observed in the ticket ATLASRECTS-6449 but definitely a blocker for its solution. We found that in earlier times the t0 in digitization and reconstruction was put to 800 and 817 ns by intention and that this shift actually matters in the reconstruction chain downstream, also (cf. the same screenshot attached below). We do not know what the 17 ns emulate exactly but for the sake of restoring the muon reconstruction performance in simulation, a property is added to the MdtDigitizationTool to shift back the t0 values towards the 800 ns.
![image](/uploads/da1ccff65ae985b1a2ddfca19f5294a2/image.png)
Tests have been performed thus far on 10k dimuon events with pt ranging between 2 and 15 GeV and within abseta<1.05
Tagging @mvanadia, @gartoni, @bernius, @jchapman, @okumura for information.
Also tagging: @sroe, @npetters, @goblirsc, @pgadow for another episode of the philosopher of the day
![image](/uploads/b92fecadf9fff0357375d9695a30e730/image.png)https://gitlab.cern.ch/atlas/athena/-/merge_requests/44011MdtDigitization - Use calibration tool by default2021-07-09T18:00:44+02:00Johannes Junggeburthjohannes.josef.junggeburth@cern.chMdtDigitization - Use calibration tool by defaultHi,
as discussed in ATLASRECTS-6203, a potential reason for the low MDT efficiencies in the run IV layout could be the usage of the default drift-time relations instead of the proper ones in the calibration database. From this MR on, we...Hi,
as discussed in ATLASRECTS-6203, a potential reason for the low MDT efficiencies in the run IV layout could be the usage of the default drift-time relations instead of the proper ones in the calibration database. From this MR on, we use the calibration tool by default and remove the property to switch it off optionally. These developments have been made by @nkoehler. They are his last ones before moving on to other tasks outside ATLAS. Marking the end of an era @minions:
![image](https://media.giphy.com/media/oW7fkm9V1sYEg/giphy.gif)
To continue the game philosopher of the day let me also mention: @goblirsc, @sroe, @npetters, @pgadow, @fsforza, @szambito, @sabidi, @gartoni, @mvanadia:
![image](/uploads/da005f12642ccee130fe9b9da2ef7b1f/image.png)https://gitlab.cern.ch/atlas/athena/-/merge_requests/43927Revert "new L1 Raw/RDO containers for TGC"2021-06-15T17:26:09+02:00Tadej Novaktadej.novak@cern.chRevert "new L1 Raw/RDO containers for TGC"This reverts merge request !43857 as it changes output in a way that may affect reprocessing.This reverts merge request !43857 as it changes output in a way that may affect reprocessing.https://gitlab.cern.ch/atlas/athena/-/merge_requests/44075Fix McEventCollection reproducibility on T->P->T2021-06-09T03:03:25+02:00Tadej Novaktadej.novak@cern.chFix McEventCollection reproducibility on T->P->TChild members of `McEventCollection` should not be initialised if blank. This fixes reproducibility of `McEventCollection` when going transient -> persistent -> transient (ATLASSIM-3598).
Also fixing two cases where HepMC3 members does ...Child members of `McEventCollection` should not be initialised if blank. This fixes reproducibility of `McEventCollection` when going transient -> persistent -> transient (ATLASSIM-3598).
Also fixing two cases where HepMC3 members does not need to be instantiated. I would appreciate if @averbyts could check.
Running ~"full-unit-tests" to make sure nothing unexpected changes.https://gitlab.cern.ch/atlas/athena/-/merge_requests/43871Add code to copy AntiKt6TruthJets to the presampled RDO file and then into th...2021-06-03T03:03:51+02:00John Derek ChapmanAdd code to copy AntiKt6TruthJets to the presampled RDO file and then into the...This MR adds code to copy `AntiKt6TruthJets` to the presampled pile-up RDO file and then into the Overlay output RDO file. This will increase the RDO file size.
It also reduces the time window over which the pile-up truth jets are saved ...This MR adds code to copy `AntiKt6TruthJets` to the presampled pile-up RDO file and then into the Overlay output RDO file. This will increase the RDO file size.
It also reduces the time window over which the pile-up truth jets are saved from [-500,+100] ns to [-125,+75] ns. This should help reduce the RDO file size. See ATLASSIM-3837 for the background.https://gitlab.cern.ch/atlas/athena/-/merge_requests/43857new L1 Raw/RDO containers for TGC2021-05-28T11:08:27+02:00Toshi Sumidatoshi.sumida@cern.chnew L1 Raw/RDO containers for TGC* Updated BS format in TGC
* Added new L1 Raw/RDO containers (all empty) as preparation of installation of New Sector Logic in TGC* Updated BS format in TGC
* Added new L1 Raw/RDO containers (all empty) as preparation of installation of New Sector Logic in TGCToshi Sumidatoshi.sumida@cern.chToshi Sumidatoshi.sumida@cern.chhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/43424Manual loop unrolling in SensorSim3DTool2021-05-19T03:04:22+02:00Tobias BisanzManual loop unrolling in SensorSim3DToolI'll post some profiles. These changes don't help readability, but seem to have a significant impact on speed - unfortunatelyI'll post some profiles. These changes don't help readability, but seem to have a significant impact on speed - unfortunatelyhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/43241Pixel digitization: log->logf to save some cpu time2021-05-10T03:05:02+02:00Tomas DadoPixel digitization: log->logf to save some cpu timeA simply change to replace `std::log` with `logf` that is less precise but faster for radiation damage code for pixel digitization
This does impact the output, but at the order of floating point precision and is thus completely negligib...A simply change to replace `std::log` with `logf` that is less precise but faster for radiation damage code for pixel digitization
This does impact the output, but at the order of floating point precision and is thus completely negligible.
A speed up of 20-30 seconds is seen for a pileup digitization job with 10 events
Note that `std::logf` wont compile on gcc, it is a known issue, see: https://gitlab.cern.ch/atlas/athena/-/blob/master/InnerDetector/InDetDetDescr/PixelReadoutGeometry/src/PixelModuleDesign.cxx#L130https://gitlab.cern.ch/atlas/athena/-/merge_requests/41500Use RandBinomialFixedP in TRT digitization2021-04-20T03:02:49+02:00Tadej Novaktadej.novak@cern.chUse RandBinomialFixedP in TRT digitizationUse `RandBinomialFixedP` in TRT digitization.
This changes digi/overlay output due to random number changes. Final xAOD digest also differs.
/cc @mduehrss @jchapman @cgrefe @calfayanUse `RandBinomialFixedP` in TRT digitization.
This changes digi/overlay output due to random number changes. Final xAOD digest also differs.
/cc @mduehrss @jchapman @cgrefe @calfayanhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/40987TGC Digitization: Implementation of propagation time difference due to the ef...2021-03-12T03:04:48+01:00Natsu TeramuraTGC Digitization: Implementation of propagation time difference due to the effect of twisted cable.The inner station cable connecting the ASD to the PSB is long and twisted, which causes signal propagation time differences between channels. Out of the 32 channels of the inner station sensors, channels 12-16 and 27-32 have smaller prop...The inner station cable connecting the ASD to the PSB is long and twisted, which causes signal propagation time differences between channels. Out of the 32 channels of the inner station sensors, channels 12-16 and 27-32 have smaller propagation times than the other channels because they are attached to the inner of the cable. I have implemented a method to calculate the effect of this.
The compilation is fine, no errors or warnings. Also, I have tested with single muon MC. I could find the BCID distribution I expected.https://gitlab.cern.ch/atlas/athena/-/merge_requests/40853Radiation damage code changes2021-02-20T03:04:08+01:00Tomas DadoRadiation damage code changesThis MR consists of 2 commits:
* First commit skips a loop iteration if the original energy deposit from Geant4 is in an invalid Si cell - this _changes the output_ - see below for plots. However, this should be considered more of a bug...This MR consists of 2 commits:
* First commit skips a loop iteration if the original energy deposit from Geant4 is in an invalid Si cell - this _changes the output_ - see below for plots. However, this should be considered more of a bug fix
* Second commit brings speed improvements:
* Removing one superfluous if condition in the 3D sensor (it is already satisfied in that part of the code)
* Replaces a code where something like (1 - 2*bool) is used which was marked as being slow by VTune. This is beyond my c++/compiler optimisation knowledge why this is so slow, but it seems to be slow and it is fixed now.
* The last change moves a calcualtion of one expensive part outside of the `ncharge` loop
The changes in the second commit bring no additional changes wrt the first commit.
cc @tadej @bnachmanhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/39659Activate IBL special charge calibration (ATLASSIM-5035)2021-02-20T03:02:31+01:00Soshi TsunoActivate IBL special charge calibration (ATLASSIM-5035)Pixel group agreed to use this IBL special charge correction both in default (no radiation damage) and radiation damage digitizer. Thus, the default value should be True.
This change will affect simulation (q221 etc) but not data.Pixel group agreed to use this IBL special charge correction both in default (no radiation damage) and radiation damage digitizer. Thus, the default value should be True.
This change will affect simulation (q221 etc) but not data.https://gitlab.cern.ch/atlas/athena/-/merge_requests/40525Radiation damage speed up2021-02-18T15:21:52+01:00Tomas DadoRadiation damage speed upThis MR replaces !40382
This MR is a fist step towards speeding up the radiation damage code.
It has been identified with a profiler that the dominant portion of time is spent in retrieving values for various objects (position, Ramo po...This MR replaces !40382
This MR is a fist step towards speeding up the radiation damage code.
It has been identified with a profiler that the dominant portion of time is spent in retrieving values for various objects (position, Ramo potential, etc) from a ROOT histogram.
Thus, this MR adds a new helper class that takes a ROOT histogram, transforms it into a 1D linearized vector and adds optimal (to the best of my knowledge) function to find a bin, exploiting the fact that the bins are equidistant.
This results in some tiny differences wrt the old implmentation due to floating point precision, but now the code is faster and the reading of the values from the histograms is not in the top 5 largest CPU consumers anymore, as tested with the overlay transform without pileup.
Further improvements will follow in the future.
cc @tadejhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/39912Activation of new deadmap folder (ATLASRECTS-5014)2021-02-09T00:41:17+01:00John Derek ChapmanActivation of new deadmap folder (ATLASRECTS-5014)(Copy of !38486 with conflicts resolved and commits squashed down to two.)
The deadmap format will be changed in rel.22. The previous DB folder was /PIXEL/PixMapOverlay, and new folder /PIXEL/PixelModuleFeMask .
This new folder is not ...(Copy of !38486 with conflicts resolved and commits squashed down to two.)
The deadmap format will be changed in rel.22. The previous DB folder was /PIXEL/PixMapOverlay, and new folder /PIXEL/PixelModuleFeMask .
This new folder is not included in old global tag. Thus, in the job option, the DB-tag is specified, but this should be removed when the q-test update new global tag.
Unfortunately, q221 uses old global tag, OFLCOND-MC16-SDR-25, which associates PixMapOverlay-SIM-MC16-000-02. But the RUN-2 best-knowledge tag is based on PixMapOverlay-SIM-MC16-000-03, and new deadmap conditions also based on this tag (-03).
Therefore, the q221 test will not pass T0 policy. The reference file is updated.
On the other hand, the data q431 is no problem.
FYI @stsuno, @abarton, @tadejhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/39655Switch from CLHEP::RandGauss to CLHEP::RandGaussZiggurat in Muon Digitization...2021-02-08T09:48:36+01:00Nicolas KoehlerSwitch from CLHEP::RandGauss to CLHEP::RandGaussZiggurat in Muon Digitization code (ATLASSIM-5037)Hi,
this MR moves from CLHEP::RandGauss to CLHEP::RandGaussZiggurat in the Muon Digitization code (fixes ATLASSIM-5037).
Best, NicoHi,
this MR moves from CLHEP::RandGauss to CLHEP::RandGaussZiggurat in the Muon Digitization code (fixes ATLASSIM-5037).
Best, Nico