GEANT4 - Minutes of Technical User Forum, CERN, 7 October 2003

 

Meeting of 7 October 2003, 15:00-17:30 CEST

Hosted at CERN.

Chair: J. Apostolakis

Contributing: M. Asai, A Dell'Acqua, F. Gianotti, V. Ivantchenko, A. Morsch, M. Maire, P. Mora de Freitas, F. Ranjard, G. Santin, M. Stavrianakou. (Potential ommisions to be corrected).

Draft Minutes, Version 1.0, 18th December 2003, J. Apostolakis.

New Requirements

A. Requirements of functionality

  • 0201) Killing the primary in Bremsstrahlung

    Formelly numbered A01. Originator: CMS (A. De Roeck)

    Description: "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. "

    Seconded by A Dell'Acqua (ATLAS), who added a refinement to use other criteria to decide whether to create a new track - potentially including eg the inital energy of the primary.

    Constraints: Performance is a consideration, as any mechanism that is added to all processes could have performance implications.

    Discussion: Geant4 includes the concept of a Wrapper Process which can be used to change the wrapped process' behaviour. In particular we expect that it is possible to customise a discrete process to kill its primary under particular conditions. For its definition see the wrapper process class.

    A potential issue in utilising the wrapping of processes in conjuction with supplied physics lists was touched upon. A mechanism to change a physics list in memory to substitute the wrapped process for the original should be demonstrated. An alternative would be to add an optional hook/mechanism to examine and conditionally change the behaviour of a discrete process.

    Given the potential diversity of requirements, it was proposed to refine the requirement and study the utility of the wrapper process for fulfilling it.

    Action: M. Stavrianakou, V. Ivantchenko: study the proposed solution utilising a wrapper class, and report upon its viability.

  • 0202) Abstraction of geometry navigation / modelling

    Was A02. Originator: A. Morsch (ALICE)

    Description: "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).

    Discussion: the wish was reiterated to enable a common modeller between different Monte Carlos. Detailed requirements were not presented, and will need to be provided separately.

    Action: A. Morsch, A. Gheata: Provide detailed requirements.

    Action G. Cosmo : Provide prototype implementation.

  • 0203) pre-defined decay products

    Was A03. Originator: CMS (A. De Roeck)

    Description: "Propagate pre-assigned decay time down entire chain of pre-defined decay products."

    This requirement was agreed without comment. An implementation is being included in the development tags and is scheduled for inclusion in the next release.

    Action: M Asai Report on status regarding release at next meeting.

  • 0204) User defined MC truth

    Was A04. Originator: CMS (A. De Roeck)

    Description: 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 G4DynamicParticle

    Discussion: A proposed implementation has been created in the recent past.

    Action: M Asai: to report on release and evolution. CMS to report feedback.

  • 0205) Maintaining event generator information

    Formely A06. Originator: Paulo Mora de Freitas (LC/Mokka)

    Description: "Strengthening the relationship between Pithya particle <->G4Track: in the current public release we lost some Pithya information when using the standard G4 HEPEVT interface. "

    Note: We understand that a first solution already implemented in the current G4 development releases.

    Action: M Asai to provide template for users showing how to use full HEP-EVT functionality.

  • 0206) Physics modelling options and consistency

    Formely A5. Originator: A. Morsch (ALICE)

    Description: "ALICE believe 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. "

    The discussion noted the increased variety of hadronic physics modelling and evolving physics lists which are largely addressing this need. Nevertheless Hans Peter noted the difficulty in bridging the gap between most cascade models, which reach to typically 3 GeV and string models, which are typically valid to ~20 GeV.

    Action: Hans Peter to update on advances n Geant4 6.0 at next TF meeting.

  • 0207) Depositing additional information in calorimeter hits

    Formely A7. Originator: Paulo Mora de Freitas (LC/Mokka)

    Description: "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 ? "

    Action: Makoto to provide pointer to example code.

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

    Formely A7. Originator: Andrea Dell'Acqua (Atlas)

    Description: "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."

    Notes: These requirements were agreed, and study of the extent of changes required is starting. It was agreed that the priority was to notify the user clearly in case of conditions that cannot be coped with.

    Action Hisaya to provide a proposed plan for implementation

B. Processes, Release issues and User support

  • 0209) Physics lists capabilities and choices

    Formelly B1. In two parts:
    1. Choices & recommendadations.

      Originator: A. Morsch (ALICE)

      Description: "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. "

      Note: The LCG hadronic physics lists now include information regarding the option that currently provides the best physics and the one that is the most CPU performant.

    2. Documentation, change and release mechanisms.

      Originator: F. Giannotti (ATLAS)

      Description: "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. "

      Discussion revealed the interest of users in slow and clear evolution of the capabilities of the hadronic physics lists.

      Action:Hans Peter undertook to provide Release Notes for new versions of the hadronic physics lists, which list changes that are relevant to the lists.

      The procedure for release was proposed: a Geant4 release is to include the latest available physics lists, ported to this release. Subsequent validation and resulting improvements would be put out as soon as available and also included in regular development releases.

      Action:Hans Peter agreed to add verbosity to each physics list to describe very briefly its intended use case and key information.

  • 0210) Correction of known problems

    Formelly B2. Originator: A. Morsch (ALICE)

    Description: "If a problem is discovered and acknowledged in a model or an interaction, the problem must to be fixed, with priority. It was stressed that in many cases it is hard to assess with full confidence whether a problem will affect a physics observable. "

    Note: It was agreed that it is important to resolve known problems, if the problem is not inherent in a particular modelling approach.

  • 0211) Geant4 release types and frequency

    Formelly B3. Originator: M Stavrianakou / A De Roeck for CMS

    Description: "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. "

    Note: The constraints behind the current release scheduling were discussed. It was agreed that a major change would not be discussed

    The Geant4 team urged early communication of significant change requests.


JA, 18th December 2003

Meeting Date: 

Tuesday, October 7, 2003