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).
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.
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.
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.
Was A04. Originator: CMS (A. De Roeck)
Description: Request the association and full navigability between - generator primary particles and predefined decay products
Discussion: A proposed implementation has been created in the recent past.
Action: M Asai: to report on release and evolution. CMS to report feedback.
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.
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.
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.
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:
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
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.
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.
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.
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.