Contributing: To be filled.
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. "
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.
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. "
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).
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.
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:
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?)
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)
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.
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 :
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.
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.
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?) "
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).
Originator: ATLAS (A. Rimondi)
Description: " Needs the users to get together and work out a proposal, perhaps on a next G4 Technical Forum. "
Originator: CMS (M. Liendl)
Description: " Many problems with the boolean processor are observed in visualization "
Originator: ATLAS (A. Rimondi)
Description: " Use interactive functionality in order to set up parameters from outside without modifying the code. "
Originator: CMS (M. Liendl)
Description: Additional checking of validity of proposed values in solids' constructors.
Originator: ATLAS (A. Rimondi)
Description: To be added
More details are needed to turn this into a requirement "