Extract of Gantt chart from TDR
- Simulation Schedule in Computing Upgrade TDR:
Various activities need to be carried out and fit in more then one of the main topic listed above. In particular while the overall architecture of Gaussino and Gauss has been defined, activities like the repackaging of different components or the move to the new Gaudi concerns both.
For this reason in the activities listed below sometimes it is indicated in which context they fit in.
Minimal generator phase in Gaussino and its migration to HepMC 3
| Lead group |
Simulation |
| Participating groups |
Simulation |
| Description |
The generator phase of Gauss has been ported in its minimal implementation in Gauss, i.e. all interfaces and at least one implementation of each tool (cut, PV smearing, production engine). It has been tested and used for a first implementation of random number in the new Gaudi in a MT environment, although further investigation would be helpful. In addition the code has been migrated to a more recent HepMC 3 version that is advertised as thread safe and with a smaller memory footprint. Nevertheless HepMC 3 is not completely commissioned for production quality and evolution should be followed. Generator tests should also be put in place. First implementation exists and running. |
| Required FTE |
0.3 |
| Available FTE |
0.2 |
| Deadline |
2018 |
| Dependencies |
This depend on |
| People currently involved |
Dominik |
| New effort required? |
Helpful for generator testings and monitoring |
| Link to documentation |
Computing TDR, Dominik presentation at last A&S |
Repackaging of libraries to factorise out experiment indendent parts
| Lead group |
Simulation |
| Participating groups |
Simulation, Core software, and all other to smaller extent |
| Description |
In order to have a minimal fully functional Gaussino it is necessary to repackage out into some 'GaudiExtension' common packages that are really not LHCb specific, They are for example ParticlePropertySvc, DetectorDescription (right now), Basic Event Model classes. These packages are currently in LHCb but they should be moved out of the repository and build either together with the Gaussino project (when used by others then LHCb) or with LHCb for us in order to have a |
| Required FTE |
0.2 |
| Available FTE |
0.1 |
| Deadline |
December 2018 |
| Dependencies |
|
| People currently involved |
Dominik, Gloria |
| New effort required? |
Yes from Core Software |
| Link to documentation |
|
Gauss built on top of Gaussino
| Lead group |
Simulation |
| Participating groups |
Simulation, Core Software |
| Description |
Gauss will depend on Gaussino with additional configuration packages to specify the setting for example of Pythia8 or Geant4 and other package with for example additional generators as weill as the final Gauss() configurable. For this we need the Gauss project to have a different build strategy and load the sources from both the Gaussino and Gauss GitLab repository. This activity is specifically to setup up the structure and the minimal Gauss extension for a full simulation, i.e. Pythia8 + G4. The generator and simulation phase can be done separately |
| Required FTE |
0.6 |
| Available FTE |
0.3 |
| Deadline |
March 2018 |
| Dependencies |
This requires a Gaussino with both generator and Geant4 implementation. |
| People currently involved |
Dominik, Gloria |
| New effort required? |
Yes, from core software |
| Link to documentation |
|
Geant4 Multithreading with Gaudi future in Gaussino
| Lead group |
Simulation |
| Participating groups |
Simulation, Core software |
| Description |
The MT implementation of Geant4 needs to marry the Gaudi choices in particular since the event loop and thread handling should be steered by Gaudi. The idea being that it is Gaussino that controls the Geant4 threads. In addition to exploring the multi-threaded interplay and verifying which implementation is more optimal one needs to rewrite all of the Gauss G4 User classes to match the G4 MT interfaces, and removed all double inheritance GiGa mechanisms since it it not usable in the G4 MT version. Hence all of the GiGa Run Manager, Event Manager, Run/Event/Tracking/Stepping actions need to be modified to different extents. This task does not cover specific physics processes of detectors (e.g. RICH) nor the geometry that are separate activities |
| Required FTE |
0.6 |
| Available FTE |
0.6 |
| Deadline |
December 2018 |
| Dependencies |
Gaudi |
| People currently involved |
Dominik |
| New effort required? |
|
| Link to documentation |
|
Geometry translation from LHCb to Geant4
| Lead group |
Simulation |
| Participating groups |
Simulation, Core software |
| Description |
The LHCb geometry is passed to Geant4 internal classes. This is done via a dedicated service that select which part of the geometry has to be simulated. With the move to DD4Hep as geometry format for the upgrade detector the service will need to be rewritten. A new generic interface should be implemented in Gaussino as well as a generic implementation based on DD4Hep. We need to understand if we should use DD4Hep plugins for selecting the volume to pass but also find an alternative way to inform Geant4 to which volumes to attach a given sensitive detector / magnetic field manager in order to allow to add or remove them at run time. The new service should allow to simulate all misalignment of the detector. The support of the geometry of the current detector is seen as a separate activity |
| Required FTE |
0.6 |
| Available FTE |
0 |
| Deadline |
December 2018 |
| Dependencies |
Gaudi |
| People currently involved |
|
| New effort required? |
Yes |
| Link to documentation |
|
Support of Current Detector Geometry in future Gauss
| Lead group |
Simulation |
| Participating groups |
Simulation, Core software |
| Description |
The LHCb geometry is passed to Geant4 internal classes. With the move to DD4Hep as geometry format for the upgrade detector we need to ensure that the geometry of the current detector for each year can be simulated with the new Gauss. The favoured solution at the moment is to make use of GDML by saving with the current Gauss all different detector configurations (with the correct Velo position) and load it via DD4Hep. An issue are the sensitive detectors and magnetic filed manager that are intended to be treated separately. One has to verify the DD4Hep use of GDML, create GDML for all different configurations, implement a repository and a way to load the correct one at run time. |
| Required FTE |
0.4 |
| Available FTE |
0 |
| Deadline |
March 2019 |
| Dependencies |
DD4Hep in Gaussino |
| People currently involved |
|
| New effort required? |
Yes |
| Link to documentation |
|
Gaussino minimal simulation phase
| Lead group |
Simulation |
| Participating groups |
Simulation, Core software |
| Description |
Once all elements above are available in Gaussino (MT, rewrite of GiGa, geometry) they have to be combined together to provide a fully functional version of the Geant4 simulation with a clear framework |
| Required FTE |
0.2 |
| Available FTE |
0.2 |
| Deadline |
March 2019 |
| Dependencies |
See description |
| People currently involved |
Dominik |
| New effort required? |
No |
| Link to documentation |
|
Migration of EvtGen to HepMC3 and implementation in Gauss based on Gaussino
| Lead group |
Simulation |
| Participating groups |
Simulation |
| Description |
We will need to port EvtGen itself to use HepMC 3 and to the new Gaudi/Gauss. In addition we want to repackage EvtGen to use the central repository in HepForge rather then our own copy. The mechanism we have to do so for Delphes and to some extent Geant4 where we can apply our patches to the external releases should be adopted |
| Required FTE |
0.6 |
| Available FTE |
0.6 to be verified |
| Deadline |
February 2016 |
| Dependencies |
This requires a generator version of Gauss built on top of Gaussino |
| People currently involved |
|
| New effort required? |
Under discussion |
| Link to documentation |
|
Simulation Event Model
| Lead group |
Simulation |
| Participating groups |
All |
| Description |
HepMC3 will not be part of the LHCb event model but all MCParticle/MCVertex , MC(XXHIts). etc. need to be ported to the new AoS or SoA structure. At the moment the SoA structure is the chosen solution. The simulation objects and containers need to evolve during the processing and the whole system need to be tested. In addition the possibility of having a common part between Particle and MCParticle need to be investigated as well as the best way of connecting MCParticles and MCVertices |
| Required FTE |
0.4 |
| Available FTE |
0.1 |
| Deadline |
October 2018 |
| Dependencies |
Baseline Event Model |
| People currently involved |
Paul, Dominik |
| New effort required? |
|
| Link to documentation |
|
Improve passing conditions to simulation
| Lead group |
Simulation |
| Participating groups |
Computing, Simulation |
| Description |
Currently the way of passing some conditions to simulation (field map, velo motor position) is via a global tag even if they have very little differences. Part of the reason is to propagate them transparently to the successive applications. A better way of doing so via the DDDB configurable and querying the MC samples should be investigated. This should be easy to use in production. |
| Required FTE |
|
| Available FTE |
|
| Deadline |
|
| Dependencies |
|
| People currently involved |
Marco Cl., Gloria |
| New effort required? |
|
| Link to documentation |
|
Port all generators to new Gaudi and HepMC3 - December 2020
Restructuring of Gauss configurable to support all options in a simpler & safer way - December 2019
Delphes fully functional in current Gauss
Porting Delphes to future Gauss
Delphes configuration and procedures for different year (look-up tables for tracking)
PIDCalib integration in fast sim (DELPHES and production environment for RICHLess options)
Infrastructure for specific detector replacement of Geant4 by fastSim in Gauss/Gaussino
Calorimeter frozen showers
Calorimeter ML CaloGAN
--
GloriaCorti - 2018-05-08
LHCb Web>LHCbComputing>LHCbComputingUpgrade>LHCbComputingUpgradeUSPGPlanning>SimulationActivities (2018-06-09, VladimirGligorov)
EditAttachPDF
jpg 
Copyright &© 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.