GEANT4 - Requirements presented at the Technical User Forum, CERN, 5 February 2004

 

Meeting of 5 February 2004, 15:00-18:00 CEST

Hosted at CERN and accessible via VRVS.

Chair: A. De Roeck

Contributing: To be filled.

Draft of the list of the presented Requirements, Version 0.2, 12th February 2004,

Editors: A. De Roeck and J. Apostolakis.

New requirements on robustness, performance, support

  • 0301) Robustness of G4 and improved diagonostics to give more handels to solve problems

    Originator: (LHC experiments)

    Description: " The LHC experiments CMS and LHCb are entering production now. Occasional crashes are seen in simulations of files containing several hundered events. These problems will have to be tackled and removed. Additional information given/printed during the abort will help to localize the problem. "

  • 0302) Reproducibility when resuming of runs at an event different from the first one

    Originator: CMS (M. Liendl)

    Description: For debugging purposes it is required that one can reproduce a particular event exactly, when one starts the simulation from that event.

    Discusion: It should be checked again, in a common effort between the experiments and G4 whether it works with the present G4 6.0.

    Some fixes for uninitialized variable were in G4 (6.0?) and experiment programs in 2H03.

  • 0303) Performance of G4

    Originator: (LHC experiments)

    Description: " Compared to G3 simulation, under similar circumstances G4 is reported by the LHC experiments, to be a factor 1.5-2 slower. A study group started last year to address this issue, and should continue with more priority. This is expected to be a collaboration between G4 and the users. "

Requirements of functionality

  • 0304) Exchange format for the geometry

    Originator: ATLAS (A. Rimondi)

    Description: Enable use of an external file for exchanging geometry description. Potential options: GDML, DDD, other (?).

    Note: The solution G4 proposes is GDML in the framework of the LCG project. The GDML implementation is already partially done (the input part).

  • 0305) Ability to release the memory of an Allocator 'stack' on request.

    Originator: ATLAS & CMS

    Use case: " Step behavior [is] seen in the memory usage during event file simulation."

    Note: A mechanism to release a stack is under study by G4.

  • 0306) Storage retrieval of cuts/physics-tables

    Originator: CMS (M. Liendl)

    Description: Extend retrieval of physics tables to case where the geometry is built in a different order than at storage.

    Example:

    • - build detector (tracker, calos ,muons), save tables - OK
    • - build (part of) detector in different order: calos, tracker, no muons
    then the table loading fails.

    Note: this is related to requirement 0208 (ie A8 of previous TF#2)

    Is there relation with prob. rep. #527: ascii and binary format problems; inadequate information with default verbosity - any news?)

  • 0307) Region settings in reflected geometries

    Originator: CMS (M. Liendl)

    Description: " If a region is assigned to a logical-volume and the volume is placed n-times in the detector, the region cuts are applied to all n-regions (valid for all daughter volumes recursively). If the same volume is reflected m-times, the region settings are not applied to the reflected volumes. " Example: when reflecting a whole endcap of a subdetector, we need to have the same region cuts applied to the reflected volume hierarchy (same physics in both endcaps)

  • 0308) Creating a new particle

    Originator: LHCb (G. Corti)

    Description: The possibility to assign a new track ID (creating new particle) to a hadron undergoing inelastic scattering, in all physics lists, and steerable from the physics lists. The choice should be under user control since it depends on specific studies. This is necessary to understand the behaviour of the tracking for example where if the leading outgoing particle has very different kinematic from the incoming particle it can be misleading [to reconstruction programs to see this] as a single particle. "

    In cases where different behaviors of a model are a priori possible (for instance the desired changing or not changing the track ID for pions undergoing inelastic scattering), the default behaviour should be clearly stated and easily switchable by the user.

    Action H.P. Wellish : Work in progress.

  • 0309) Provide documentation on the technical aspects of all available physics processes

    Originator: LHCb (G. Corti)

    Description: " All available physics processes, models, cross-sections, etc., should provide documentation of the technical aspects of the implementation: details of the expected behaviour of a model should be provided (for example how incoming and outgoing particles are handled). This applies to both hadronic and electromagnetic processes. "

    Action Physics group coordinators :

  • 0310) Consistent behaviour across use cases

    W Originator: LHCb (G. Corti)

    Description: " A physics list should be implemented in a coordinated way regarding the output of the models' behaviour, so that such behaviour would be consistent as much as possible. For example an incoming particle should always be (or not be) killed in all inelastic scattering models of a given physics list. In the cases where this is not possible (due to specific characteristcs of the models) the difference should be clearly described."

    Action: Report on evaluation at next meeting.

  • 0311) Parameters used in physics list should be well document and under user control

    Originator: LHCb (G. Corti)

    Description: " When the behaviour of a specific physics list depends on parameters (for example on a momentum threshold) this should be clearly documented, specifying if such parameters are fixed or under user control. "

    Note (from discussion): Major user modifications, such as these, would reduce the value of comparisons of the same physics list between users and experiments.

  • 0312) Possibility of customizing volume/solid creation step G4

    Originator: ATLAS (A. Rimondi)

    Description: " E.g add a call to a user routine when a volume is created in order to add attributes to the volume (detectorName::, other?) "

  • 0313) Particle properties from an external source

    Originator: ATLAS & CMS

    Description: " The request is to study whether one can have a unique definition of the particle properties throughtout all the physics models within G4 and preferably also consistent with the values used in generators. A candidate catalogue could be HepPDT, extracted from the PDG tables. This needs to be studied however, since some of the physics models assume explictely certain mass/width values for certain resonances (in generally poorly measured).

Issues, proto-requirements, open problems

  • 0314) Centralize different implementations of the MC truth scheme

    Originator: ATLAS (A. Rimondi)

    Description: " Needs the users to get together and work out a proposal, perhaps on a next G4 Technical Forum. "

  • 0315) Fix problems with the boolean processor

    Originator: CMS (M. Liendl)

    Description: " Many problems with the boolean processor are observed in visualization "

  • 0316) Tools for optimizing of tracking through the magnetic field

    Originator: ATLAS (A. Rimondi)

    Description: " Use interactive functionality in order to set up parameters from outside without modifying the code. "

  • 0317) Solid parameters checking

    Originator: CMS (M. Liendl)

    Description: Additional checking of validity of proposed values in solids' constructors.

  • xxx) Improved visualization options

    Originator: ATLAS (A. Rimondi)

    Description: To be added

    More details are needed to turn this into a requirement "


ADR, 11th February 2004 and JA, 12th February 2004.

Meeting Date: 

Thursday, February 5, 2004