GEANT4 - Technical User Forum, CERN, 7 October 2003

Submitted by Anonymous (not verified) on

7 October 2003, 15:00-17:30 CEST (13:00-15:30 GMT)

Hosted at CERN.

Chair: J. Apostolakis

Meeting location: Building 40, Room SS-D01 (Dirac).

Connection via telephone, contact +41 22 767 7000

Final Agenda, version 1.3, 7th October 2003

Agenda outline

  1. Regular items (15 min)
  2. News from Geant4 collaboration (30 min)
    • Update regarding issues from first proto-TF meeting (J. Apostolakis).
  3. Requirements, requests and issues (1hr 45min)
    1. Requirements of functionality
    2. Issues in process, release schedules and user support
Details of above item:

A. Requirements of functionality

  • A1) Killing the primary in Bremsstrahlung

    Originator: CMS (A. De Roeck)

    For electron brem (and possibly muon brem) for hard brem (defined by threshold set by user) to kill the incoming electron and generate a new track for it, together with the track already being generated for the gamma.

  • A2) Abstraction of geometry navigation / modelling

    Originator: A. Morsch (ALICE)

    We request that G4 improves the modularity of its design in order to enable the simple interfacing with an external geometry modeler.

    Use case: ALICE intents to use Geant4 together with the Virtual MonteCarlo and the geometry modeler developped by the Root team (TGeo).

  • A3) pre-defined decay products

    Originator: CMS (A. De Roeck) Propagate pre-assigned decay time down entire chain of pre-defined decay products.

  • A4) user defined MC truth

    Originator: CMS (A. De Roeck)

    Request the association and full navigability between - generator primary particles and predefined decay products - G4PrimaryParticle created for above - G4DynamicParticle created for above G4PrimaryParticle - G4Track for above

  • A5) Physics modelling options and consistency

    Originator: A. Morsch (ALICE)

    We need microscopic models all-the-way from 20 Mev to 10 TeV. For ranges in which there are different models we expect a clear statement which is the current best. For the overlap of models, the consistency of the overlap and the switchover energy is responsibility of the Monte Carlo.

  • A6) Maintaining event generator information

    Paulo Mora de Freitas (LC/Mokka)

    The PithyaG4Track relationships, mainly concerning the fact that in the current public release we lost some Pithya information if using the standard G4 HEPEVT interface. Note: We understand that a first solution already implemented in the current G4 development releases.

  • A7) Depositing additional information in calorimeter hits

    Paulo Mora de Freitas (LC/Mokka)

    Maintaining the relation between an entering particle and a calorimeter hits. Use case: in our calorimeter hit lay-out we keep the PID of the particle entering in the calorimeter to help to test the reconstruction programs. Also, we keep the partial contribution by the particle type in the shower to help to understood the shower development, mainly in the Hcal. We suggest to explore whether this is a common simulation need - and, if so, how it could be supported or provided by the G4 kernel ?

  • A8) Enhanced saving and restoring of selected processes' cross-section tables

    Andrea Dell'Acqua (Atlas)

    The ATLAS detector simulation provides the ability to choose at the beginning of a job between a large number of geometry layouts. We are interested in using the Geant4 ability to save and restore cross-section tables, but its current implementation has limitation that do not allow this.

    In particular, as our geometry can not be correspondigly saved, it is not possible (as of today) to check, when the cross section tables are read back in, that the saved configuration corresponds to the one currently in memory. (Note that the "cuts per region" has made this even more complex.)

    It is then our requirement that:

    1. an automatic checking procedure be run everytime a set of cross-section tables is read in, in order to verify the consistency of the data set just read in with the detector configuration built in memory;
    2. the program be stopped (possibly nicely) if consistency can not be confirmed/re-established;
    3. warning messages be printed for all those materials/ material-region combinations found in the read-in set that have no correspondance in the current configuration;
    4. that the possibility be provided to drop/recalculate cross-section tables for selected materials/material-region combinations without affecting the remaining set of tables.

B. Processes, Release issues and User support

  • B1) Physics lists capabilities and choices

    In two parts:
    1. Choices & recommendadations.

      Originator: A. Morsch (ALICE)

      Request a restricted number of pre-canned physics lists specialised for accuracy and use case. Request that experts advise on the current best physics list, rather than simply offering a choice of options. Request a single recommendation for all types of problems.

    2. Documentation, change and release mechanisms.

      Originator: F. Giannotti (ATLAS)

      Improved documentation of physics lists, including description of changes from version to version, Request a revised mechanism for releasing the physics lists, together with and in close integration with geant4 source releases.

  • B2) Correction of known problems

    Originator: A. Morsch (ALICE)

    If a problem is discovered and acknowledged in a model or an interaction, the problem must to be fixed, with priority. It should not be asked of the user(s) to estimate the damage to his/her physics, as it is complicated, labour intensive and can be impossible in the absence of the 'truth'.

  • B3) Geant4 release types and frequency

    Originator: M Stavrianakou / A De Roeck for CMS

    Propose to revise the current release scheme (patch releases - reference tags - production release) to include for release of new features that extend functionality without requiring interface changes.

Tuesday, 7 October 2003 - JA
Meeting Date