Geant4 7.0 Release Notes
December 17th, 2004


The code and binary libraries for the supported systems are available through our Source Code Web page.

Please refer to the Geant4 User Documentation for further information about using Geant4.

Contents

  1. Supported and Tested Platforms
  2. AIDA and CLHEP
  3. Compiler Specific Problems
  4. Known Run-Time Problems
  5. Compilation Warnings
  6. Known Run-Time Warnings
  7. Major items for migration of user code
  8. Detailed list of changes and fixes

1. Supported and Tested Platforms

Official platforms: More verified configurations: Platforms configured but not tested and not supported:

2. AIDA and CLHEP

Geant4 7.0 requires the installation of CLHEP.
Tests have been performed with CLHEP-1.8.1.0
The software has been verified also with CLHEP-1.9.1.2.

Geant4 7.0 examples with histogramming cowork with AIDA 3.2.1 implementations. These include: AIDA headers can be downloaded from: http://aida.freehep.org

3. Compiler Specific Problems

4. Known Run-Time Problems and Limitations

For a complete list of outstanding run-time problems and to submit any problem you may find running this version of Geant4, please refer to the Geant4 Problem Reporting System.

5. Compilation Warnings

There may be compilation warnings on some platforms. We do not believe that any will lead to incorrect run-time behaviour.

6. Known Run-Time Warnings

The following message can be written to error output while tracking. We believe it does not give rise to incorrect behaviour. 
    G4PropagateInField: Warning: Particle is looping 
    -  tracking in field will be stopped. 
       It has performed 1000 steps in Field while a maximum of 1000
       are allowed.

7. Major items for migration of user code

Some migrations are necessary in different areas of the user code in order to upgrade from release 6.2 to release 7.0, a full recompilation and/or reinstallation of libraries and user applications is moreover required.

Direct usage of <cmath> for standard mathematical functions

In this release the Geant4 code makes now direct usage of <cmath> for standard mathematical functions. All direct/indirect inclusions of <math.h> have been removed.
To be compliant with this migration, the user code should be modified as well, by adopting either one of the following approaches: As part of this migration also standard headers like: 
       <math.h>, <limits.h>, <stdlib.h>
are no longer indirectly included. This may require the user code to include them if/where necessary.
To be noticed also that this migration involves also the removal of usage of the ad-hoc template function originally defined in CLHEP: 
       T abs(T)
So the definition of this function will not be any longer available in a indirect way. The standard mathematical function: 
       std::abs()
will have to be used instead.

New Installation procedure for the Configure script

The installation procedure of the kernel libraries using the Configure script has changed. It is now required to specify the final area of installation for the libraries and sources; libraries are now first built in the local directory where the source has been downloaded and unpacked; and will be later-on installed in the specified installation area (requiring root priviledges if necessary). See the Installation Guide for the details.

Migration for usage of the G4VParticleChange class

An interface change to the class G4VParticleChange is implemented in Geant4 7.0. Advanced users, who have implemented a physics process should be aware that the following methods have been removed: 
      void  SetTrueStepLength(G4double truePathLength);
      void  SetLocalEnergyDeposit(G4double anEnergyPart);
      G4TrackStatus GetStatusChange() const;
      void  SetStatusChange(G4TrackStatus status);
      void  SetSteppingControl(G4SteppingControl StepControlFlag);
      void  SetParentWeight(G4double);
They have been replaced by the following methods, respectively: 
      void ProposeTrueStepLength(G4double truePathLength);
      void ProposeLocalEnergyDeposit(G4double anEnergyPart);
      G4TrackStatus GetTrackStatus() const;
      void ProposeTrackStatus(G4TrackStatus status);
      void ProposeSteppingControl(G4SteppingControl StepControlFlag);
      void ProposeParentWeight(G4double);
For the detailed list of all interface changes involved in G4VParticleChange, please consult: http://cern.ch/geant4/source/source/migration_70.html.

Step limitation

A user now needs to change his/her code, in order to limit the step size of a particle -- when using the class G4UserLimits to limit the step. Up to the previous release, step limitation due to the maximum step length of G4UserLimits was directly done by G4SteppingManager, while all other limits (maxTrackLength, maxStepNumber, MinKinEnergy and minRemainRange) were dealt by G4UserSpecialCuts process. To solve this inconsistency, to simplify the majority of applications which do not utilize the step limitation, and to give more usability to the user, we introduce a new process G4StepLimiter and move the step limitation procedure in G4SteppingManager to this new process. The user who is using the step length limitation MUST include the new G4StepLimiter process in the physics-list explicitly. This new process may be assigned only to the selected particle types (e.g. only to the charged particles) instead of setting it to all particle types.
No change is required for the user who is NOT using G4UserLimits for the purpose of maximum step limitation.

Killing of a particle

An advanced user who has created a process with a continuous component ('AlongStep' action) that can kill or bring a particle to a rest will need to review their process implementation. Energy-loss processes no longer change the track status of a charged particle as part of their AlongStepDoIt() action. For a user-defined process with a "continuous" component, in order to stop (and thus either kill or bring to a rest in an 'alive' state) a particle in its AlongStepDoIt() method, it is now necessary to propose zero kinetic energy for the particle. Alternatively a process can contribute to the particle arriving at zero energy, as a result of the action of two or more processes, e.g. energy loss and propagation in an electric field (in the transportation process). Once a particle has zero (or less) proposed energy, it is brought to a rest and its energy is set exactly to zero. If the particle can decay, can be annihilated or generally has one or more 'AtRest' actions, then another step will be performed that calls these; else, the particle is killed. The discrete component (or 'PostStep' action) of a process will not be performed once the particle has come to a stop.
Note: the case of a particle that comes to a rest in a field and is then re-accelerated, is not supported at this time.

Future migration for G4GeneralParticleSource class

A 'tree-structured' command format is implemented in this release for G4GeneralParticleSource. The old UI commands have been kept for backward compatibility but will be removed in the future.
For more information, please consult: http://reat.space.qinetiq.com/gps.

8. Detailed list of changes and fixes

These are the main new features/fixes included in this release since the last patched public release (for the detailed list of fixes/additions, please refer to the related History files provided in most packages):

Configuration

Digitization & Hits

Electromagnetic Processes (Low-energy)

Electromagnetic Processes (Standard)

Event

General Processes, Parameterisation, Cuts, Decay, Optical

Geometry

Global

Graphical Representations

Hadronic Processes

Parameterisations

Particles

Run and Interfaces

Track and Tracking

Visualization

Physics lists

Environments

Examples