Gauss merge requestshttps://gitlab.cern.ch:8443/lhcb/Gauss/-/merge_requests2024-03-28T00:22:46+01:00https://gitlab.cern.ch:8443/lhcb/Gauss/-/merge_requests/1036Draft: Use of BetheHeitler5D model for gamma conversion2024-03-28T00:22:46+01:00Michele VeltriDraft: Use of BetheHeitler5D model for gamma conversionModify the gauss configuration file to make available a new physics list: G4EmStandardPhysics_option2gc5D.cc
The new list is a variant of the default option2 which uses the BetheHeitler5D model for gamma conversionModify the gauss configuration file to make available a new physics list: G4EmStandardPhysics_option2gc5D.cc
The new list is a variant of the default option2 which uses the BetheHeitler5D model for gamma conversionMichele VeltriMichele Veltrihttps://gitlab.cern.ch:8443/lhcb/Gauss/-/merge_requests/1020Draft: Add functionality to propogate weights through Pythia to HEPMC2023-11-06T17:08:41+01:00Nathan Allen Griesernathan.allen.grieser@cern.chDraft: Add functionality to propogate weights through Pythia to HEPMCAdd necessary feature to propogate MadGraph systematic variations through Pythia to HEPMC. Supports any other weights that need are passed to Pythia.Add necessary feature to propogate MadGraph systematic variations through Pythia to HEPMC. Supports any other weights that need are passed to Pythia.Philip James IltenNathan Allen Griesernathan.allen.grieser@cern.chPhilip James Iltenhttps://gitlab.cern.ch:8443/lhcb/Gauss/-/merge_requests/1016Draft: Dynamic definition of particle for Gauss-on-Gsino when using G4 10.72024-03-29T00:11:35+01:00Gloria CortiDraft: Dynamic definition of particle for Gauss-on-Gsino when using G4 10.7This is to port to Sim11 `master` the dynamic definition of particles we have introudced in Sim10 in a clean way. As that requires a workaround from G4 10.7.
(see !910, !968 and !1012 in Sim10).This is to port to Sim11 `master` the dynamic definition of particles we have introudced in Sim10 in a clean way. As that requires a workaround from G4 10.7.
(see !910, !968 and !1012 in Sim10).Michele VeltriMichele Veltrihttps://gitlab.cern.ch:8443/lhcb/Gauss/-/merge_requests/1001Draft: Calo Challenge setup in LHCb2024-03-29T00:11:07+01:00Michal MazurekDraft: Calo Challenge setup in LHCb@gcorti @azaborow @dasalama @witoldp @landerli @admorris @witoldp @mkmiec
This MR introduces a general setup that can be used to run ML inference and produce training datasets that can be used in fast simulations compatible with the Cal...@gcorti @azaborow @dasalama @witoldp @landerli @admorris @witoldp @mkmiec
This MR introduces a general setup that can be used to run ML inference and produce training datasets that can be used in fast simulations compatible with the CaloChallenge setup and involving the LHCb calorimeters.
CaloChallenge is a ML competition focusing on fast calorimeter simulation using generative models. The idea is to represent each particle shower by virtual hits forming concentric cylinders with particles propagating along the z-axis.
More info on the calo challenge: https://calochallenge.github.io/homepage/.
The experiment-independent approach for cylindrical and planar calorimeters was presented in Gaussino in https://gitlab.cern.ch/Gaussino/Gaussino/-/merge_requests/131 and https://gitlab.cern.ch/Gaussino/Gaussino/-/merge_requests/146 respectively. The work in this MR further extends this work to adapt the configuration for the calorimeters in LHCb.
## Problems
The CaloChallenge setup in Gauss is way much more complex than the examples used in Gaussino. The following problems were met when implementing the configuration:
1. **DetDesc / DD4hep**: the setup must remain agnostic to the actual geometry description used in LHCb, e.g. the weights of the models should not depend on whether we used DetDesc or DD4hep,
2. **Non-uniformity of the calorimeters**: the geometry of the calorimeters is very complex. The detectors themselves are slightly tilted, and shifted with respect to the LHCb coordiante system. Moreover, some of the subregions of the calorimeters are shifted with respect to each other. There's also a beam hole in the middle of the calorimeter. See images below.
3. **Gauss must accept virtual hits**: the hits produced by the CaloChallenge inference must be converted to the native data container used in LHCb: `LHCb::MCCaloHits` (the work on this was done by @mkmiec in !981)
4. **Energy corrections**: the models must be trained on the energy values including all the energy corrections that are applied in the native sensitive detector class,
5. **Timing resolution**: split the energy output into 25 ns time slots (this is what is done in Gauss in detailed simulation). The timing resolution is ignored for now in the setup in this MR.
6. **ML backends**: the setup should be backend agnostic as much as possible. This became possible with the interfaces in Gaussino to pyTorch (https://gitlab.cern.ch/Gaussino/Gaussino/-/merge_requests/55) and ONNXRuntime (https://gitlab.cern.ch/Gaussino/Gaussino/-/merge_requests/145).
![GAUSS_ZMAX_RUN1AND2](/uploads/666e444315cde8dd726564bc0dd78aa7/GAUSS_ZMAX_RUN1AND2.png)
![GAUSS_ZMAX_RUN3_ZOOM](/uploads/75e242526cdfb1e3d5ce9aa6c1400123/GAUSS_ZMAX_RUN3_ZOOM.png)
## Solution
The configuration changes depending on whether we run in the **inference** or the **training dataset production** mode. Both setups use extensively the packages in Gaussino: CustomSimulations, ParallelGeoemtry and ExternalDetector.
**Inference mode**:
1. Kill all the particles of interest traveling through a very thin plane, a `CollectorPlane`, which collects all the necessary information about these particles to feed the ML models.
2. Fetch the G4 info using `Gsino::CaloChallenge::GetCollectorHitsAlg` and trigger the ML inference with either `pyTorch`, `ONNXRuntime` or any other available backend using `Gsino::CaloChallenge::GetMLCaloHitsAlg` at the beginning of the calorimeter sensitive area (marked in the setuo as the `Trigger Plane`).
3. Monitor the performance of the inference with the low level `Gsino::CaloChallenge::DetailedAndFastSimMonitoring` algorithm.
4. Convert, merge and optionally split the generic `CaloHit`s used in the inference to the `LHCb::MCCaloHit`s.
5. Monitor and store the `LHCb::MCCaloHits` as in the standard simulation.
**Training dataset production**:
1. Keep the the track of the particles passing through the `CollectorPlane`, but do not kill them and let them participate in the detailed simulation.
2. Both virtual hits and native hits are produced. The native sensitive detector class of the calorimeters used in LHCb triggers the sensitive detector class in CaloChallenge to produce the virtual hits. This allows us to propagate all the energy corrections to the virtual hits.
3. Use `Gsino::CaloChallenge::TrainingDataCollector` and `Gauss::CaloCollector` to produce training datasets for the virtual and native hits respectively.
![GAUSS_CALO_CHALLENGE_RUN3](/uploads/d973387c8fd4dda058c96b7d0733fb68/GAUSS_CALO_CHALLENGE_RUN3.png)
## Results
### Visualization
![EXAMPLES_MOMENTUM_COMPARISON_ECAL_FixedMomentum_11_theta7.0_DetailedSimulation_vis_phi0.0_theta180.0](/uploads/5f8f882e2ea8a0fd7ed41711bfb48c9d/EXAMPLES_MOMENTUM_COMPARISON_ECAL_FixedMomentum_11_theta7.0_DetailedSimulation_vis_phi0.0_theta180.0.png)
![EXAMPLES_SIMULATION_COMPARISON_ECAL_FixedMomentum_10.0GeV_11_theta7.0_vis_phi0.0_theta180.0](/uploads/cdbb1dccb6366158e839c4dab299b621/EXAMPLES_SIMULATION_COMPARISON_ECAL_FixedMomentum_10.0GeV_11_theta7.0_vis_phi0.0_theta180.0.png)
### Training data vs. output
![TRAINING_DATA_GAUSSINO_SIMULATION_COMPARISON_ECAL_FixedMomentum_10.0GeV_11_theta7.0](/uploads/12e2070e785570b17fbfbb59bdb00569/TRAINING_DATA_GAUSSINO_SIMULATION_COMPARISON_ECAL_FixedMomentum_10.0GeV_11_theta7.0.png)
### Monitoring
![MONITORING_SIMULATION_COMPARISON_ECAL_FixedMomentum_10.0GeV_11_theta7.0](/uploads/91b27c476e5c72dd80c66bdd0d096822/MONITORING_SIMULATION_COMPARISON_ECAL_FixedMomentum_10.0GeV_11_theta7.0.png)https://gitlab.cern.ch:8443/lhcb/Gauss/-/merge_requests/994Draft: Dependencies and Configurable options for Madgraph in Futurev52023-10-24T20:21:18+02:00Ruben PozziDraft: Dependencies and Configurable options for Madgraph in Futurev5Integrating Madgraph into Futurev5. Dependent on https://gitlab.cern.ch/Gaussino/Gaussino/-/merge_requests/151.
A more detailed explanation with diagrams, and on **how to test it** can be found here https://codimd.web.cern.ch/JtD7xAGqS6...Integrating Madgraph into Futurev5. Dependent on https://gitlab.cern.ch/Gaussino/Gaussino/-/merge_requests/151.
A more detailed explanation with diagrams, and on **how to test it** can be found here https://codimd.web.cern.ch/JtD7xAGqS6S9eSIyfmKqRA#.
It depends on implementation in Gaussino as described in Gaussino/Gaussino#39Ruben PozziRuben Pozzihttps://gitlab.cern.ch:8443/lhcb/Gauss/-/merge_requests/929Draft: Decaying Luminosity2024-03-29T00:06:11+01:00Timothy David EvansDraft: Decaying LuminosityAdds the option to decay the luminosity, as expected in Run 5+.
- Adds a pileup tool that generates the time in the fill, and then a corresponding poisson distributed random number for the number of vertices.
- Adds a flag in Generatio...Adds the option to decay the luminosity, as expected in Run 5+.
- Adds a pileup tool that generates the time in the fill, and then a corresponding poisson distributed random number for the number of vertices.
- Adds a flag in Generation to give 'exclusive' productions (that is, event types where we force the parent particle to decay to a given final state). The reason for this is the distribution in time of signal, vs min bias is quite different, as the probability that there is a signal decay is ~ proportional to the number of vertices. Perhaps this flag could be deduced from the event type?
- The time in the fill is going to be a very useful number to store. There is a field in MCHeader for this but is used by ReDecay at the moment?Gloria CortiTimothy David EvansGloria Cortihttps://gitlab.cern.ch:8443/lhcb/Gauss/-/merge_requests/897Draft: LbESEPP for beam-electron scattering2024-03-28T00:26:18+01:00Giacomo GrazianiDraft: LbESEPP for beam-electron scatteringRequest for integration in Gauss of a new generator, ESEPP, to simulate the elastic lepton-proton(/nucleus) scattering taking into account the radiative corrections. This is a rebase, with modernised code, of MR !458 from 2019 (which was...Request for integration in Gauss of a new generator, ESEPP, to simulate the elastic lepton-proton(/nucleus) scattering taking into account the radiative corrections. This is a rebase, with modernised code, of MR !458 from 2019 (which was closed)
See details of generator in [presentation on 12 October 2022](https://indico.cern.ch/event/1187113/contributions/5090906/attachments/2526564/4346424/20221012-SimDev-ESEPP.pdf)Sim10/2024.02 (Gauss v56r8)Michele VeltriMichele Veltrihttps://gitlab.cern.ch:8443/lhcb/Gauss/-/merge_requests/880Draft: Visualization configurable for Phoenix and Geant42024-01-18T15:46:52+01:00Michal MazurekDraft: Visualization configurable for Phoenix and Geant4This should add an additional layer of LHCb-related options that should activate G4 or Phoenix visualization in Gaussino.
FYI @fbilandzThis should add an additional layer of LHCb-related options that should activate G4 or Phoenix visualization in Gaussino.
FYI @fbilandzMichal MazurekMichal Mazurekhttps://gitlab.cern.ch:8443/lhcb/Gauss/-/merge_requests/657Modify propagation for corrected acceptance, all track types2023-09-04T15:06:06+02:00Adam DavisModify propagation for corrected acceptance, all track typesChange Lamarr's default behaviour to have fiducial acceptance cuts. At the same time, do so as a function of track state, allowing for all track types to be reconstructed.
Benedetto is cross-checking for the changes in Lamarr based on t...Change Lamarr's default behaviour to have fiducial acceptance cuts. At the same time, do so as a function of track state, allowing for all track types to be reconstructed.
Benedetto is cross-checking for the changes in Lamarr based on this.
@bsiddi @landerliBenedetto Gianluca Siddibenedetto.gianluca.siddi@cern.chBenedetto Gianluca Siddibenedetto.gianluca.siddi@cern.chhttps://gitlab.cern.ch:8443/lhcb/Gauss/-/merge_requests/644Draft: SuperChic32023-12-11T16:28:15+01:00Albert BurscheDraft: SuperChic3Work in progress for SuperChic 3 integration.Work in progress for SuperChic 3 integration.https://gitlab.cern.ch:8443/lhcb/Gauss/-/merge_requests/577Draft: resolve LHCBGAUSS-471 (PowHeg-Box)2024-03-28T00:26:14+01:00Philip James IltenDraft: resolve LHCBGAUSS-471 (PowHeg-Box)Make necessary changes to be able to use PowHeg-Box again within Gauss.
This required to migrate LbPowheg to the new plugin structure that was introduced in Pythia 8.209 for PowhegBox and to get dynamic plugin libraries.
This MR repl...Make necessary changes to be able to use PowHeg-Box again within Gauss.
This required to migrate LbPowheg to the new plugin structure that was introduced in Pythia 8.209 for PowhegBox and to get dynamic plugin libraries.
This MR replaces !96, !559 and !536
It will require a first release of `Gen/PowhegboxData v1r0`
Closes LHCBGAUSS-471.Sim10/2024.02 (Gauss v56r8)Gloria CortiHengne LiGloria Corti