Connection via telephone, contact +41 22 767 7000
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.
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).
Originator: CMS (A. De Roeck) Propagate pre-assigned decay time down entire chain of pre-defined decay products.
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
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.
Paulo Mora de Freitas (LC/Mokka)
The Pithya<->G4Track 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.
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 ?
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:
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.
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.
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'.
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.