source: trunk/documents/UserDoc/DocBookUsersGuides/ForApplicationDeveloper/xml/TrackingAndPhysics/physicsProcess.xml @ 1222

<!-- ******************************************************** -->
<!--                                                          -->
<!--  [History]                                               -->
<!--    Changed by: Katsuya Amako, 30-Jul-1998                -->
<!--    Proof read by: Joe Chuma,  29-Jun-1999                -->
<!--    Converted to DocBook: Katsuya Amako, Aug-2006         -->
<!--                                                          -->
<!-- ******************************************************** -->


<!-- ******************* Section (Level#1) ****************** -->
<sect1 id="sect.PhysProc">
<title>
Physics Processes
</title>

<para>
Physics processes describe how particles interact with a
material. Seven major categories of processes are provided by
Geant4:

<orderedlist spacing="compact">
  <listitem><para>
    <link linkend="sect.PhysProc.EleMag">
    electromagnetic
    </link>
    ,
  </para></listitem>
  <listitem><para>
    <link linkend="sect.PhysProc.Had">
    hadronic
    </link>
    ,
  </para></listitem>
  <listitem><para>
    <link linkend="sect.PhysProc.Decay">
    decay
    </link>
    ,
  </para></listitem>
  <listitem><para>
    <link linkend="sect.PhysProc.PhotoHad">
    photolepton-hadron
    </link>
    ,
  </para></listitem>
  <listitem><para>
    <link linkend="sect.PhysProc.Photo">
    optical
    </link>
    ,
  </para></listitem>
  <listitem><para>
    <link linkend="sect.PhysProc.Param">
    parameterization
    </link>
    and
  </para></listitem>
  <listitem><para>
    <link linkend="sect.PhysProc.Trans">
    transportation
    </link>
    .
  </para></listitem>
</orderedlist>
</para>

<para>
The generalization and abstraction of physics processes is a key
issue in the design of Geant4. All physics processes are treated in
the same manner from the tracking point of view. The Geant4
approach enables anyone to create a process and assign it to a
particle type. This openness should allow the creation of processes
for novel, domain-specific or customised purposes by individuals or
groups of users.
</para>

<para>
Each process has two groups of methods which play an important
role in tracking, <literal>GetPhysicalInteractionLength</literal> (GPIL) and
<literal>DoIt</literal>. The GPIL method gives the step length from the
current space-time point to the next space-time point. It does this
by calculating the probability of interaction based on the
process's cross section information. At the end of this step the
<literal>DoIt</literal> method should be invoked. The <literal>DoIt</literal> method
implements the details of the interaction, changing the particle's
energy, momentum, direction and position, and producing secondary
tracks if required. These changes are recorded as
<emphasis>G4VParticleChange</emphasis> objects(see 
<link linkend="brhead.PhysProc.PrtChng">
Particle Change</link>).
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
G4VProcess
</bridgehead>

<para>
<emphasis>G4VProcess</emphasis> is the base class for all physics processes.
Each physics process must implement virtual methods of
<emphasis>G4VProcess</emphasis> which describe the interaction (DoIt) and
determine when an interaction should occur (GPIL). In order to
accommodate various types of interactions <emphasis>G4VProcess</emphasis>
provides three <literal>DoIt</literal> methods:

<itemizedlist spacing="compact">
  <listitem><para>
    <literal>G4VParticleChange* AlongStepDoIt( const G4Track&amp; track,
    const G4Step&amp; stepData )</literal>
    <para>
    This method is invoked while <emphasis>G4SteppingManager</emphasis> is
    transporting a particle through one step. The corresponding
    <literal>AlongStepDoIt</literal> for each defined process is applied for
    every step regardless of which process produces the minimum step
    length. Each resulting change to the track information is recorded
    and accumulated in <emphasis>G4Step</emphasis>. After all processes have been
    invoked, changes due to <literal>AlongStepDoIt</literal> are applied to
    <emphasis>G4Track</emphasis>, including the particle relocation and the safety
    update. Note that after the invocation of <literal>AlongStepDoIt</literal>,
    the endpoint of the <emphasis>G4Track</emphasis> object is in a new volume if the
    step was limited by a geometric boundary. In order to obtain
    information about the old volume, <emphasis>G4Step</emphasis> must be accessed,
    since it contains information about both endpoints of a step.
    </para>
  </para></listitem>
  <listitem><para>
    <literal>G4VParticleChange* PostStepDoIt( const G4Track&amp; track,
    const G4Step&amp; stepData )</literal>
    <para>
    This method is invoked at the end point of a step, only if its
    process has produced the minimum step length, or if the process is
    forced to occur. <emphasis>G4Track</emphasis> will be updated after each
    invocation of <literal>PostStepDoIt</literal>, in contrast to the
    <literal>AlongStepDoIt</literal> method.
    </para>
  </para></listitem>
  <listitem><para>
    <literal>G4VParticleChange* AtRestDoIt( const G4Track&amp; track,
    const G4Step&amp; stepData )</literal>
    <para>
    This method is invoked only for stopped particles, and only if
    its process produced the minimum step length or the process is
    forced to occur.
    </para>
  </para></listitem>
</itemizedlist>
</para>

<para>
For each of the above <literal>DoIt</literal> methods <emphasis>G4VProcess</emphasis>
provides a corresponding pure virtual GPIL method:

<itemizedlist spacing="compact">
  <listitem><para>
    <literal>G4double PostStepGetPhysicalInteractionLength( const
    G4Track&amp; track, G4double previousStepSize, G4ForceCondition*
    condition )</literal>
    <para>
    This method generates the step length allowed by its process. It
    also provides a flag to force the interaction to occur regardless
    of its step length.
    </para>
  </para></listitem>
  <listitem><para>
    <literal>G4double AlongStepGetPhysicalInteractionLength( const
    G4Track&amp; track, G4double previousStepSize, G4double
    currentMinimumStep, G4double&amp; proposedSafety, G4GPILSelection*
    selection )</literal>
    <para>
    This method generates the step length allowed by its process.
    </para>
  </para></listitem>
  <listitem><para>
    <literal>G4double AtRestGetPhysicalInteractionLength( const
    G4Track&amp; track, G4ForceCondition* condition )</literal>
    <para>
    This method generates the step length in time allowed by its
    process. It also provides a flag to force the interaction to occur
    regardless of its step length.
    </para>
  </para></listitem>
</itemizedlist>
</para>

<para>
Other pure virtual methods in <emphasis>G4VProcess</emphasis> follow:

<itemizedlist spacing="compact">
  <listitem><para>
    <literal>virtual G4bool IsApplicable(const
    G4ParticleDefinition&amp;)</literal>
    <para>
    returns true if this process object is applicable to the
    particle type.
    </para>
  </para></listitem>
    <listitem><para>
      <literal>virtual void PreparePhysicsTable(const
      G4ParticleDefinition&amp;)</literal> and
  </para></listitem>
  <listitem><para>
    <literal>virtual void BuildPhysicsTable(const
    G4ParticleDefinition&amp;)</literal>
    <para>
    is messaged by the process manager, whenever cross section
    tables should be prepared and rebuilt due to changing cut-off
    values. It is not mandatory if the process is not affected by
    cut-off values.
    </para>
  </para></listitem>
  <listitem><para>
    <literal>virtual void StartTracking()</literal> and
  </para></listitem>
  <listitem><para>
    <literal>virtual void EndTracking()</literal>
    <para>
    are messaged by the tracking manager at the beginning and end of
    tracking the current track.
    </para>
  </para></listitem>
</itemizedlist>
</para>


<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
Other base classes for processes
</bridgehead>

<para>
Specialized processes may be derived from seven additional
virtual base classes which are themselves derived from
<emphasis>G4VProcess</emphasis>. Three of these classes are used for simple
processes:

<variablelist>
  <varlistentry>
    <term><emphasis>G4VRestProcess</emphasis></term>
    <listitem>
      <para>
      Processes using only the <literal>AtRestDoIt</literal> method.
      </para>
      <para>
      example: neutron capture
      </para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><emphasis>G4VDiscreteProcess</emphasis></term>
    <listitem>
      <para>
      Processes using only the <literal>PostStepDoIt</literal> method.
      </para>
      <para>
      example: compton scattering, hadron inelastic interaction
      </para>    
    </listitem>
  </varlistentry>
</variablelist>
</para>

<para>
The other four classes are provided for rather complex
processes:

<variablelist>
  <varlistentry>
    <term><emphasis>G4VContinuousDiscreteProcess</emphasis></term>
    <listitem>
      <para>
      Processes using both <literal>AlongStepDoIt</literal> and
      <literal>PostStepDoIt</literal> methods.
      </para>
      <para>
      example: transportation, ionisation(energy loss and delta ray)
      </para>    
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><emphasis>G4VRestDiscreteProcess</emphasis></term>
    <listitem>
      <para>
      Processes using both <literal>AtRestDoIt</literal> and
      <literal>PostStepDoIt</literal> methods.
      </para>
      <para>
      example: positron annihilation, decay (both in flight and at rest)
      </para>    
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><emphasis>G4VRestContinuousProcess</emphasis></term>
    <listitem>
      <para>
      Processes using both <literal>AtRestDoIt</literal> and
      <literal>AlongStepDoIt</literal> methods.
      </para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><emphasis>G4VRestContinuousDiscreteProcess</emphasis></term>
    <listitem>
      <para>
      Processes using <literal>AtRestDoIt</literal>, 
      <literal>AlongStepDoIt and</literal> PostStepDoIt methods.
      </para>
    </listitem>
  </varlistentry>
</variablelist>
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4' id="brhead.PhysProc.PrtChng">
Particle change
</bridgehead>

<para>
<emphasis>G4VParticleChange</emphasis> and its descendants are used to store
the final state information of the track, including secondary
tracks, which has been generated by the <literal>DoIt</literal> methods. The
instance of <emphasis>G4VParticleChange</emphasis> is the only object whose
information is updated by the physics processes, hence it is
responsible for updating the step. The stepping manager collects
secondary tracks and only sends requests via particle change to
update <emphasis>G4Step</emphasis>.
</para>

<para>
<emphasis>G4VParticleChange</emphasis> is introduced as an abstract class. It
has a minimal set of methods for updating <emphasis>G4Step</emphasis> and
handling secondaries. A physics process can therefore define its
own particle change derived from <emphasis>G4VParticleChange</emphasis>. Three
pure virtual methods are provided,

<itemizedlist spacing="compact">
  <listitem><para>
    <literal>virtual G4Step* UpdateStepForAtRest( G4Step* step)</literal>, 
  </para></listitem>
  <listitem><para>
    <literal>virtual G4Step* UpdateStepForAlongStep( G4Step* step )</literal>
    and
  </para></listitem>
  <listitem><para>
    <literal>virtual G4Step* UpdateStepForPostStep( G4Step* step)</literal>,
  </para></listitem>
</itemizedlist>

which correspond to the three <literal>DoIt</literal> methods of
<emphasis>G4VProcess</emphasis>. Each derived class should implement these
methods.
</para>


<!-- ******************* Section (Level#2) ****************** -->
<sect2 id="sect.PhysProc.EleMag">
<title>
Electromagnetic Interactions
</title>

<para>
This section summarizes the electromagnetic (EM) physics processes which
are provided with Geant4. Extended information are avalable at EM web 
<ulink url="http://geant4.web.cern.ch/geant4/collaboration/EMindex.shtml">
<emphasis role="bold">pages</emphasis></ulink>.   
For details on the implementation of these
processes please refer to the 
<ulink url="http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/PhysicsReferenceManual/html/PhysicsReferenceManual.html">
<emphasis role="bold">Physics Reference Manual</emphasis></ulink>.
</para>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.EleMag.Stand">
<title>
"Standard" Electromagnetic Processes
</title> 

<para>
The following is a summary of the standard electromagnetic
processes available in Geant4.

<itemizedlist spacing="compact">
  <listitem><para>
    Photon processes
    <itemizedlist spacing="compact">
      <listitem><para>
        Compton scattering (class name <emphasis>G4ComptonScattering</emphasis>)
      </para></listitem>
      <listitem><para>
        Gamma conversion (also called pair production, class name
        <emphasis>G4GammaConversion</emphasis>)
      </para></listitem>
      <listitem><para>
        Photo-electric effect (class name <emphasis>G4PhotoElectricEffect</emphasis>)
      </para></listitem>
      <listitem><para>
        Muon pair production (class name <emphasis>G4GammaConversionToMuons</emphasis>)
      </para></listitem>
    </itemizedlist>
  </para></listitem>
  <listitem><para>
    Electron/positron processes
    <itemizedlist spacing="compact">
      <listitem><para>
        Ionisation and delta ray production (class name
        <emphasis>G4eIonisation</emphasis>)
      </para></listitem>
      <listitem><para>
        Bremsstrahlung (class name <emphasis>G4eBremsstrahlung</emphasis>)
      </para></listitem>
      <listitem><para>
        Multiple scattering (class name <emphasis>G4eMultipleScattering</emphasis>)
      </para></listitem>
      <listitem><para>
        Positron annihilation into two gammas (class name
        <emphasis>G4eplusAnnihilation</emphasis>)
      </para></listitem>
      <listitem><para>
        Positron annihilation into two muons (class name
        <emphasis>G4AnnihiToMuPair</emphasis>)
      </para></listitem>
      <listitem><para>
        Positron annihilation into hadrons (class name
        <emphasis>G4eeToHadrons</emphasis>)
      </para></listitem> 
    </itemizedlist>
  </para></listitem>
  <listitem><para>
    Muon processes
    <itemizedlist spacing="compact">
      <listitem><para>
        Bremsstrahlung (class name <emphasis>G4MuBremsstrahlung</emphasis>)
      </para></listitem>
      <listitem><para>
        Ionisation and delta ray production (class name
        <emphasis>G4MuIonisation</emphasis>)
      </para></listitem>
      <listitem><para>
        Multiple scattering (class name <emphasis>G4MuMultipleScattering</emphasis>)
      </para></listitem>
      <listitem><para>
        e+e- pair production (class name
        <emphasis>G4MuPairProduction</emphasis>)
      </para></listitem>
    </itemizedlist>
  </para></listitem>
  <listitem><para>
    Hadron/ion processes
    <itemizedlist spacing="compact">
      <listitem><para>
        Bremsstrahlung (class name <emphasis>G4hBremsstrahlung</emphasis>)
      </para></listitem>
      <listitem><para>
        Ionisation (class name <emphasis>G4hIonisation</emphasis>)
      </para></listitem>
      <listitem><para>
        e+e- pair production (class name <emphasis>G4hPairProduction</emphasis>)
      </para></listitem>
      <listitem><para>
        Ionisation for ions (class name <emphasis>G4ionIonisation</emphasis>)
      </para></listitem>
      <listitem><para>
        Multiple scattering (class name <emphasis>G4hMultipleScattering</emphasis>)
      </para></listitem>
      <listitem><para>
        Ionisation for heavy exotic particles (class name
        <emphasis>G4hhIonisation</emphasis>)
      </para></listitem>
      <listitem><para>
        Ionisation for classical magnetic monopole (class name
        <emphasis>G4mplIonisation</emphasis>)
      </para></listitem>
    </itemizedlist>
  </para></listitem>
  <listitem><para>
    Coulomb scattering processes
    <itemizedlist spacing="compact">
      <listitem><para>
        Alternative process for simulation of single Coulomb scattering 
        of all charged particles (class name <emphasis>G4CoulombScattering</emphasis>)
      </para></listitem>
      <listitem><para>
        Alternative process for simulation of single Coulomb scattering 
        of ions (class name <emphasis>G4ScreenedNuclearRecoil</emphasis>)
      </para></listitem>
    </itemizedlist>
  </para></listitem>
  <listitem><para>
    Processes for simulation of polarized electron and gamma beams
    <itemizedlist spacing="compact">
      <listitem><para>
        Compton scattering of circularly polarized gamma beam on 
        polarized target (class name <emphasis>G4PolarizedCompton</emphasis>)
      </para></listitem>
      <listitem><para>
        Pair production induced by circularly polarized gamma beam 
        (class name <emphasis>G4PolarizedGammaConversion</emphasis>)
      </para></listitem>
      <listitem><para>
        Photo-electric effect induced by circularly polarized gamma beam
        (class name <emphasis>G4PolarizedPhotoElectricEffect</emphasis>)
      </para></listitem>
      <listitem><para>
        Bremsstrahlung of polarized electrons and positrons 
        (class name <emphasis>G4ePolarizedBremsstrahlung</emphasis>)
      </para></listitem>
      <listitem><para>
        Ionisation of polarized electron and positron beam 
        (class name <emphasis>G4ePolarizedIonisation</emphasis>)
      </para></listitem>
      <listitem><para>
        Annihilation of polarized positrons 
        (class name <emphasis>G4eplusPolarizedAnnihilation</emphasis>)
      </para></listitem>
    </itemizedlist>
  </para></listitem>
  <listitem><para>
    Processes for simulation of X-rays and optical protons production by charged particles
    <itemizedlist spacing="compact">
      <listitem><para>
        Synchrotron radiation (class name <emphasis>G4SynchrotronRadiation</emphasis>)
      </para></listitem>
      <listitem><para>
        Transition radiation 
        (class name <emphasis>G4TransitionRadiation</emphasis>)
      </para></listitem>
      <listitem><para>
        Cerenkov radiation  
        (class name <emphasis>G4Cerenkov</emphasis>)
      </para></listitem>
      <listitem><para>
        Scintillations
        (class name <emphasis>G4Scintillation</emphasis>)
      </para></listitem>
    </itemizedlist>
  </para></listitem>
  <listitem><para>
    The processes described above use physics model classes, which
    may be combined according to particle energy. It is possible to
    change the energy range over which different models are valid, and
    to apply other models specific to particle type, energy range, and
    G4Region. The following alternative models are available:
    <itemizedlist spacing="compact">
      <listitem><para>
        Ionisation in thin absorbers (class name <emphasis>G4PAIModel</emphasis>)
      </para></listitem>
    </itemizedlist>
  </para></listitem>
</itemizedlist>
</para>

<para>
It is recommended to use physics constructor classes provided
with rederence physics lists ($G4INSTALL/source/physics_lists/builders):
    <itemizedlist spacing="compact">
      <listitem><para>
        default EM physics (class name <emphasis>G4EmStandardPhysics</emphasis>)
      </para></listitem>
      <listitem><para>
        optional EM physics providing fast but less acurate electron transport due to
        "Simple" method of step limitation by multiple scattering, reduced
        step limitation by ionisation process and  enabled "ApplyCuts" option
        (class name <emphasis>G4EmStandardPhysics_option1</emphasis>)
      </para></listitem>
      <listitem><para>
        Experimental EM physics with enabled "ApplyCuts" option, <emphasis>G4WentzelVIModel</emphasis>
        for muon multiple scattering
        (class name <emphasis>G4EmStandardPhysics_option2</emphasis>)
      </para></listitem>
      <listitem><para>
        EM physics for simulation with high accuracy due to "UseDistanceToBoundary" multiple
        scattering step limitation, reduced <emphasis>finalRange</emphasis> parameter of stepping function
        optimized per particle type, <emphasis>G4WentzelVIModel</emphasis>
        for muon multiple scattering and  <emphasis>G4IonParameterisedLossModel</emphasis> for ion ionisation
        (class name <emphasis>G4EmStandardPhysics_option3</emphasis>)
      </para></listitem>
      <listitem><para>
        Combined Standard and Low-energy EM physics constructors based on the Option3 constructor; 
        low-energy models are applied below 1 GeV:
         <itemizedlist spacing="compact">
           <listitem><para>
           Models based on Livermore data bases for electrons and gamma (<emphasis>G4EmLivermorePhysics</emphasis>);
           </para></listitem>    
          <listitem><para>
           Polarized models based on Livermore data bases for electrons and gamma (<emphasis>G4EmLivermorePolarizedPhysics</emphasis>);
           </para></listitem>   
          <listitem><para>
           Penelope models for electrons, positrons and gamma (<emphasis>G4EmPenelopePhysics</emphasis>);
           </para></listitem>   
          <listitem><para>
           Low-energy DNA physics (<emphasis>G4EmDNAPhysics</emphasis>).
           </para></listitem>   
         </itemizedlist>
      </para></listitem>    </itemizedlist>
Examples of the registration of these physics constructor and 
construction of alternative combinations of options are shown
in novice, extended and advanced examples ($G4INSTALL/examples/extended/electromagnetic and $G4INSTALL/examples/advanced).
Examples illustrating the use
of electromagnetic processes are available as part of the Geant4
<ulink url="http://geant4.web.cern.ch/geant4/support/download.shtml">
release</ulink>.
</para>

<para>
<emphasis role="bold">Options</emphasis> are available for steering of
electromagnetic processes. These options may be invoked either by
UI commands or by the interface class G4EmProcessOptions. This
class has the following public methods:

<itemizedlist spacing="compact">
   <listitem><para>
     SetLossFluctuations(G4bool)
   </para></listitem>
   <listitem><para>
     SetSubCutoff(G4bool, const G4Region* r=0)
   </para></listitem>
   <listitem><para>
     SetIntegral(G4bool)
   </para></listitem>
   <listitem><para>
     SetMinSubRange(G4double)
   </para></listitem>
   <listitem><para>
     SetMinEnergy(G4double)
   </para></listitem>
   <listitem><para>
     SetMaxEnergy(G4double)
   </para></listitem>
   <listitem><para>
     SetMaxEnergyForCSDARange(G4double)
   </para></listitem>
   <listitem><para>
     SetMaxEnergyForMuons(G4double)
   </para></listitem>
   <listitem><para>
     SetDEDXBinning(G4int)
   </para></listitem>
   <listitem><para>
     SetDEDXBinningForCSDARange(G4int)
   </para></listitem>
   <listitem><para>
     SetLambdaBinning(G4int)
   </para></listitem>
   <listitem><para>
     SetStepFunction(G4double, G4double)
   </para></listitem>
   <listitem><para>
     SetRandomStep(G4bool)
   </para></listitem>
   <listitem><para>
     SetApplyCuts(G4bool)
   </para></listitem>
   <listitem><para>
     SetSpline(G4bool)
   </para></listitem>
   <listitem><para>
     SetBuildCSDARange(G4bool)
   </para></listitem>
   <listitem><para>
     SetVerbose(G4int, const G4String name= "all")
   </para></listitem>
   <listitem><para>
     SetLambdaFactor(G4double)  
   </para></listitem>
   <listitem><para>
     SetLinearLossLimit(G4double)  
   </para></listitem>
   <listitem><para>
     ActivateDeexcitation(G4bool val, const G4Region* r = 0)  
   </para></listitem>
   <listitem><para>
     SetMscStepLimitation(G4MscStepLimitType val)  
   </para></listitem>
   <listitem><para>
     SetMscLateralDisplacement(G4bool val)  
   </para></listitem>
   <listitem><para>
     SetSkin(G4double)  
   </para></listitem>
   <listitem><para>
     SetMscRangeFactor(G4double)  
   </para></listitem>
   <listitem><para>
     SetMscGeomFactor(G4double)  
   </para></listitem>
   <listitem><para>
     SetLPMFlag(G4bool)
   </para></listitem>
   <listitem><para>
     SetBremsstrahlungTh(G4double)
   </para></listitem>
   <listitem><para>
     SetPolarAngleLimit(G4double)
   </para></listitem>
   <listitem><para>
     SetFactorForAngleLimit(G4double)
   </para></listitem>
</itemizedlist>
</para>

<para>
The corresponding UI command can be accessed in the UI subdirectory
"/process/eLoss". The following types of step limitation by multiple scattering 
are available:

<itemizedlist spacing="compact">
   <listitem><para>
     fSimple - simplified step limitation as in g4 7.1 version (used in QGSP_BERT_EMV Physics List)
   </para></listitem>
   <listitem><para>
     fUseSafety - default
   </para></listitem>
   <listitem><para>
     fUseDistanceToBoundary - advance method of step limitation used in EM examples,
     required parameter <emphasis>skin &gt; 0</emphasis>, should be used for
     setup without magnetic field
   </para></listitem>
</itemizedlist>
</para>

<para>
<emphasis role="bold">G4EmCalculator</emphasis> is a class which provides 
access to cross sections and stopping powers. This class can be used 
anywhere in the user code provided the physics list has already been
initialised (G4State_Idle). G4EmCalculator has "Get" methods which
can be applied to materials for which physics tables are already
built, and "Compute" methods which can be applied to any material
defined in the application or existing in the Geant4 internal
database. The public methods of this class are:

<itemizedlist spacing="compact">
   <listitem><para>
     GetDEDX(kinEnergy,particle,material,G4Region region=0)
   </para></listitem>
   <listitem><para>
     GetRangeFromRestrictedDEDX(kinEnergy,particle,material,G4Region* region=0)
   </para></listitem>
   <listitem><para>
     GetCSDARange(kinEnergy,particle,material,G4Region* region=0)
   </para></listitem>
   <listitem><para>
     GetRange(kinEnergy,particle,material,G4Region* region=0)
   </para></listitem>
   <listitem><para>
     GetKinEnergy(range,particle,material,G4Region* region=0)
   </para></listitem>
   <listitem><para>
     GetCrosSectionPerVolume(kinEnergy,particle,material,G4Region* region=0)
   </para></listitem>
   <listitem><para>
     GetMeanFreePath(kinEnergy,particle,material,G4Region* region=0)
   </para></listitem>
   <listitem><para>
     PrintDEDXTable(particle)
   </para></listitem>
   <listitem><para>
     PrintRangeTable(particle)
   </para></listitem>
   <listitem><para>
     PrintInverseRangeTable(particle)
   </para></listitem>
   <listitem><para>
     ComputeDEDX(kinEnergy,particle,process,material,cut=DBL_MAX)
   </para></listitem>
   <listitem><para>
     ComputeElectronicDEDX(kinEnergy,particle,material,cut=DBL_MAX)
   </para></listitem>
   <listitem><para>
     ComputeNuclearDEDX(kinEnergy,particle,material,cut=DBL_MAX)
   </para></listitem>
   <listitem><para>
     ComputeTotalDEDX(kinEnergy,particle,material,cut=DBL_MAX)
   </para></listitem>
   <listitem><para>
     ComputeCrosSectionPerVolume(kinEnergy,particle,process,material,cut=0)
   </para></listitem>
   <listitem><para>
     ComputeCrosSectionPerAtom(kinEnergy,particle,process,Z,A,cut=0)
   </para></listitem>
   <listitem><para>
     ComputeMeanFreePath(kinEnergy,particle,process,material,cut=0)
   </para></listitem>
   <listitem><para>
     ComputeEnergyCutFromRangeCut(range,particle,material)
   </para></listitem>
   <listitem><para>
     FindParticle(const G4String&amp;)
   </para></listitem>
   <listitem><para>
     FindIon(G4int Z, G4int A)
   </para></listitem>
   <listitem><para>
     FindMaterial(const G4String&amp;)
   </para></listitem>
   <listitem><para>
     FindRegion(const G4String&amp;)
   </para></listitem>
   <listitem><para>
     FindCouple(const G4Material*, const G4Region* region=0)
   </para></listitem>
   <listitem><para>
     SetVerbose(G4int)
   </para></listitem>
</itemizedlist>
</para>

<para>
For these interfaces, particles, materials, or processes may be
pointers or strings with names.
</para>

</sect3>


<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.EleMag.LowE">
<title>
Low Energy Electromagnetic Processes
</title>

<para>
A physical interaction is described by a process class which can handle 
physics models, described by model classes. The following is a summary 
of the Low Energy Electromagnetic physics models available in Geant4. 
Further information is available in the web pages of the 
Geant4 Low Energy Electromagnetic Physics Working Group, accessible 
from the Geant4 web site, “who we are” section, then “working groups”. 
</para>

<para>
The physics content of these models is documented in the Geant4 
<ulink url="http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/PhysicsReferenceManual/html/PhysicsReferenceManual.html">
Physics Reference Manual. 
</ulink>
They are based on the Livermore data library, on the 
ICRU73 data tables or on the Penelope Monte Carlo code. They adopt the 
same software design as the "standard" Geant4 electromagnetic models.
</para>

<para>
Examples of the registration of physics constructor with low-energy 
electromagnetic models are shown in Geant4 extended examples 
(<literal>$G4INSTALL/examples/extended/electromagnetic</literal>). 
Advanced examples (<literal>$G4INSTALL/examples/advanced</literal>) 
illustrate alternative instantiation of these processes. 
Both are available as part of the Geant4 release.
</para>

<para>
To use the low energy electromagnetic models, data files need to be 
copied by the user to his/her code repository. These files are 
distributed together with Geant4. The user should set the environment 
variable G4LEDATA to the directory where he/she has copied the files.
</para>

<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.PhysProc.EleMag.LowE.Livemore">
<title>
Livermore based models
</title> 

<para>
<itemizedlist spacing="compact">
  <listitem><para>
    <emphasis role="bold">Photon models</emphasis>
    <itemizedlist spacing="compact">
      <listitem><para>
        Photo-electric effect (class <emphasis>G4LivermorePhotoElectricModel</emphasis>)
      </para></listitem>
      <listitem><para>
        Polarized Photo-electric effect (class <emphasis>G4LivermorePolarizedPhotoElectricModel</emphasis>)
      </para></listitem>
      <listitem><para>
        Compton scattering (class <emphasis>G4LivermoreComptonModel</emphasis>)
      </para></listitem>
      <listitem><para>
        Polarized Compton scattering (class <emphasis>G4LivermorePolarizedComptonModel</emphasis>)
      </para></listitem>
      <listitem><para>
        Rayleigh scattering (class <emphasis>G4LivermoreRayleighModel</emphasis>)
      </para></listitem>
      <listitem><para>
        Polarized Rayleigh scattering (class <emphasis>G4LivermorePolarizedRayleighModel</emphasis>)
      </para></listitem>
      <listitem><para>
        Gamma conversion (also called pair production, class <emphasis>G4LivermoreGammaConversionModel</emphasis>)
      </para></listitem>
      <listitem><para>
        Polarized gamma conversion (class <emphasis>G4LivermorePolarizedGammaConversionModel</emphasis>)
      </para></listitem>
    </itemizedlist>
  </para></listitem>
  <listitem><para>
    <emphasis role="bold">Electron models</emphasis>
    <itemizedlist spacing="compact">
      <listitem><para>
         Bremsstrahlung (class <emphasis>G4LivermoreBremsstrahlungModel</emphasis>)
      </para></listitem>
      <listitem><para>
         Ionisation and delta ray production (class <emphasis>G4LivermoreIonisationModel</emphasis>)
      </para></listitem>
    </itemizedlist>
  </para></listitem>
</itemizedlist>
</para>

<para>
Options can be set in the G4LivermorePhotoElectricModel class, that allow 
the use of alternative photoelectron angular generators:

<itemizedlist spacing="compact">
  <listitem><para>     
    SetAngularGenerator(G4VPhotoElectricAngularDistribution* distribution);
  </para></listitem>
  <listitem><para>
    SetAngularGenerator(const G4String&amp; name);     
  </para></listitem>
</itemizedlist>
</para>

<para>
Currently three angular generators are available: 
G4PhotoElectricAngularGeneratorSimple, G4PhotoElectricAngularGeneratorSauterGavrilla 
and G4PhotoElectricAngularGeneratorPolarized.
G4PhotoElectricAngularGeneratorSauterGavrilla is selected by default.
G4PhotoElectricAngularGeneratorSimple, G4PhotoElectricAngularGeneratorSauterGavrilla 
and G4PhotoElectricAngularGeneratorPolarized can be set using respectively the 
strings "default", "standard" and "polarized".
</para>

<para>
Options are available in the G4LivermoreBremsstrahlungModel class, that allow 
the use of alternative bremsstrahlung angular generators:
<itemizedlist spacing="compact">
  <listitem><para>     
    SetAngularGenerator(G4VBremAngularDistribution* distribution);
  </para></listitem>
  <listitem><para>     
    SetAngularGenerator(const G4String&amp; name);
  </para></listitem>
</itemizedlist>
</para>

<para>
Currently three angular generators are available: G4ModifiedTsai, 
2BNGenerator and 2BSGenerator. G4ModifiedTsai is set by default, but it 
can be forced using the string "tsai". 2BNGenerator and 2BSGenerator
can be set using the strings "2bs" and "2bn". Information regarding 
conditions of use, performance and energy
limits of different models are available in the Physics Reference Manual .
</para>

<para>
Other options G4LivermoreBremsstrahlungModel class are:

<itemizedlist spacing="compact">
  <listitem><para>     
    SetCutForLowEnSecPhotons(G4double)
  </para></listitem>
</itemizedlist>
</para>

<para>
Options are available in the G4LivermoreIonisationModel class:

<itemizedlist spacing="compact">
  <listitem><para>     
    ActivateAuger(G4bool)
  </para></listitem>
  <listitem><para>     
    SetCutForLowEnSecPhotons(G4double)  
  </para></listitem>
  <listitem><para>     
    SetCutForLowEnSecElectrons(G4double)
  </para></listitem>
</itemizedlist>
</para>

</sect4>


<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.PhysProc.EleMag.LowE.ICRU73">
<title>
ICRU73 based ion model
</title> 

<para>
Ionisation and delta ray production (class G4IonParametrisedLossModel)
</para>

<para>
The ion model uses ICRU 73 stopping powers, if corresponding ion-material 
combinations are covered by the ICRU 73 report (up to 1 GeV/nucleon), and 
otherwise applies a Bethe-Bloch based formalism. For compounds, ICRU 73 
stopping powers are employed if the material name coincides with the name 
of Geant4 NIST materials (e.g. G4_WATER). Elemental materials are matched 
to the corresponding ICRU 73 stopping powers by means of the atomic number 
of the material. The material name may be arbitrary in this case. For a 
list of applicable materials, the user is referred to the ICRU 73 report.
</para>

<para>
The model requires data files to be copied by the user to his/her code 
repository. These files are distributed together with the Geant4 release. 
The user should set the environment variable G4LEDATA to the directory where 
he/she has copied the files. 
</para>

<para>
The model is dedicated to be used with the G4ionIonisation process and its 
applicability is restricted to G4GenericIon particles. The ion model is 
not used by default by this process and must be instantiated and registered 
by the user:

<informalexample>
<programlisting>
G4ionIonisation* ionIoni = new G4ionIonisation();
ionIoni -> SetEmModel(new G4IonParametrisedLossModel());
</programlisting>
</informalexample>
</para>

</sect4>

<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.PhysProc.EleMag.LowE.Penelope">
<title>
Penelope based models
</title> 

<para>
<itemizedlist spacing="compact">
  <listitem><para>
    <emphasis role="bold">Photon models</emphasis>
    <itemizedlist spacing="compact">
      <listitem><para>
        Compton scattering (class <emphasis>G4PenelopeComptonModel</emphasis>)
      </para></listitem>
      <listitem><para>
        Rayleigh scattering (class <emphasis>G4PenelopeRayleighModel</emphasis>)
      </para></listitem>
      <listitem><para>
        Gamma conversion (also called pair production, class <emphasis>GPenelopeGammaConversionModel</emphasis>)
      </para></listitem>
      <listitem><para>
        Photo-electric effect (class <emphasis>G4PenelopePhotoElectricModel</emphasis>)
      </para></listitem>
    </itemizedlist>
  </para></listitem>
  <listitem><para>
    <emphasis role="bold">Electron models</emphasis>
    <itemizedlist spacing="compact">
      <listitem><para>
         Bremsstrahlung (class <emphasis>G4PenelopeBremsstrahlungModel</emphasis>)
      </para></listitem>
      <listitem><para>
         Ionisation and delta ray production (class <emphasis>G4PenelopeIonisationModel</emphasis>)
      </para></listitem>
    </itemizedlist>
  </para></listitem>
  <listitem><para>
    <emphasis role="bold">Positron models</emphasis>
    <itemizedlist spacing="compact">
      <listitem><para>
         Bremsstrahlung (class <emphasis>G4PenelopeBremsstrahlungModel</emphasis>)
      </para></listitem>
      <listitem><para>
         Ionisation and delta ray production (class <emphasis>G4PenelopeIonisationModel</emphasis>)
      </para></listitem>
      <listitem><para>
         Positron annihilation (class <emphasis>class G4PenelopeAnnihilationModel</emphasis>)
      </para></listitem>
    </itemizedlist>
  </para></listitem>
</itemizedlist>
</para>

<para>
All Penelope models can be applied up to a maximum energy of 100 GeV, 
although it is advisable not to use them above a few hundreds of MeV.
</para>

<para>
Options are available in the all Penelope Models, allowing to set 
(and retrieve) the verbosity level of the model, namely the amount of 
information which is printed on the screen.

<itemizedlist spacing="compact">
  <listitem><para>     
    SetVerbosityLevel(G4int)
  </para></listitem>
  <listitem><para>     
    GetVerbosityLevel()
  </para></listitem>
</itemizedlist>
</para>

<para>
The default verbosity level is 0 (namely, no textual output on the screen).
The default value should be used in general for normal runs. Higher 
verbosity levels are suggested only for testing and debugging purposes. 
</para>

<para>
The verbosity scale defined for all Penelope processes is the following:

<itemizedlist spacing="compact">
  <listitem><para>     
    0 = no printout on the screen (default)
  </para></listitem>
  <listitem><para>     
    1 = issue warnings only in the case of energy non-conservation in the final state (should never happen)
  </para></listitem>
  <listitem><para>     
    2 = reports full details on the energy budget in the final state
  </para></listitem>
  <listitem><para>     
    3 = writes also informations on cross section calculation, data file opening and sampling of atoms
  </para></listitem>
  <listitem><para>     
    4 = issues messages when entering in methods
  </para></listitem>
</itemizedlist>
</para>

<para>
Options are available in G4PenelopeComptonModel, G4PenelopePhotoElectricModel 
and G4PenelopeIonisationModel to enable or disable the usage of atomic 
de-excitation via the G4AtomicDeexcitation module. 

<itemizedlist spacing="compact">
  <listitem><para>     
    SetDeexcitationFlag(G4bool)
  </para></listitem>
  <listitem><para>     
    DeexcitationFlag()
  </para></listitem>
</itemizedlist>
</para>

<para>
The default is “true”, namely vacancies in atomic shells produced by the 
interaction are handled by the G4AtomicDeexcitation module, possibly with 
the subsequent emission of fluorescence x-rays. If is set to “false” 
by the user, the energy released in the re-arrangement of atomic vacancies 
is treated in the model as a local energy deposit, without emission of 
secondary particles. The methods are actually inherited from G4VEmModel, 
so they work for all Penelope models; by the way, they have effect only 
in G4PenelopeComptonModel, G4PenelopePhotoElectricModel and 
G4PenelopeIonisationModel.
</para>

<para>
An option is also available in these models to enable the production of
Auger electrons by the G4AtomicDeexcitation module ActivateAuger(G4bool).
The default (coming from G4AtomicDeexcitation) is “false”, namely only 
fluorescence x-rays are emitted but not Auger electrons. One should 
notice that this option has effect only if the usage of the atomic 
deexcitation is enabled. A warning message is printed if one tries to 
enable the emission of the Auger electrons after having disabled the 
atomic deexcitation via SetDeexcitationFlag(false).
</para>

</sect4>
</sect3>



<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.EleMag.VeryLowE">
<title>
Very Low energy Electromagnetic Processes (Geant4-DNA extension)
</title> 

<para>
The Geant4 low energy electromagnetic Physics package has been extended 
down to energies of a few electronVolts suitable for the simulation of 
radiation effects in liquid water for applications in microdosimetry at 
the cellular and sub-cellular level. These developments take place in 
the framework of the on-going Geant4-DNA project (see the web pages 
of the 
<ulink url="http://geant4.web.cern.ch/geant4/collaboration/working_groups/LEelectromagnetic/">Geant4 Low Energy Electromagnetic Physics Working Group</ulink>).
</para>

<para>
The Geant4-DNA process and model classes apply to electrons, protons, 
hydrogen, alpha particles and their charge states.
</para>


<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
 Electron processes and models
</bridgehead>
<para>
<itemizedlist spacing="compact">
  <listitem><para>
    Elastic scattering :
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAElastic
      </para></listitem>
      <listitem><para>
        two alternative model classes are : G4DNAScreenedRutherfordElasticModel 
        or G4DNAChampionElasticModel
      </para></listitem>
    </itemizedlist>
  </para></listitem>

  <listitem><para>
    Excitation
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAExcitation 
      </para></listitem>
      <listitem><para>
        model class is G4DNAEmfietzoglouExcitationModel
      </para></listitem>
    </itemizedlist>
  </para></listitem>

  <listitem><para>
    Ionisation
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAIonisation
      </para></listitem>
      <listitem><para>
        model class is G4DNABornIonisationModel
      </para></listitem>
    </itemizedlist>
  </para></listitem>
</itemizedlist>
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
 Proton processes and models
</bridgehead>
<para>
<itemizedlist spacing="compact">
  <listitem><para>
    Excitation
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAExcitation
      </para></listitem>
      <listitem><para>
        two complementary model classes are G4DNAMillerGreenExcitationModel 
        (below 500 keV) and G4DNABornExcitationModel (above)                
      </para></listitem>
    </itemizedlist>
  </para></listitem>

  <listitem><para>
    Ionisation
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAIonisation 
      </para></listitem>
      <listitem><para>
        two complementary model classes are G4DNARuddIonisationModel 
        (below 500 keV) and G4DNABornIonisationModel (above)
      </para></listitem>
    </itemizedlist>
  </para></listitem>

  <listitem><para>
    Charge decrease
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAChargeDecrease
      </para></listitem>
      <listitem><para>
        model class is G4DNADingfelderChargeDecreaseModel
      </para></listitem>
    </itemizedlist>
  </para></listitem>
</itemizedlist>
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
 Hydrogen processes and models
</bridgehead>
<para>
<itemizedlist spacing="compact">
  <listitem><para>
    Ionisation
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAIonisation 
      </para></listitem>
      <listitem><para>
        model class is G4DNARuddIonisationModel        
      </para></listitem>
    </itemizedlist>
  </para></listitem>

  <listitem><para>
    Charge increase
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAChargeIncrease
      </para></listitem>
      <listitem><para>
        model class is G4DNADingfelderChargeIncreaseModel
      </para></listitem>
    </itemizedlist>
  </para></listitem>
</itemizedlist>
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
 Helium (neutral) processes and models
</bridgehead>
<para>
<itemizedlist spacing="compact">
  <listitem><para>
    Excitation
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAExcitation
      </para></listitem>
      <listitem><para>
        model class is G4DNAMillerGreenExcitationModel       
      </para></listitem>
    </itemizedlist>
  </para></listitem>

  <listitem><para>
    Ionisation
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAIonisation         
      </para></listitem>
      <listitem><para>
        model class is G4DNARuddIonisationModel
      </para></listitem>
    </itemizedlist>
  </para></listitem>

  <listitem><para>
    Charge increase
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAChargeIncrease
      </para></listitem>
      <listitem><para>
        model class is G4DNADingfelderChargeIncreaseModel
      </para></listitem>
    </itemizedlist>
  </para></listitem>
</itemizedlist>
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
 Helium+ (ionized once) processes and models
</bridgehead>
<para>
<itemizedlist spacing="compact">
  <listitem><para>
    Excitation
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAExcitation
      </para></listitem>
      <listitem><para>
        model class is G4DNAMillerGreenExcitationModel
      </para></listitem>
    </itemizedlist>
  </para></listitem>

  <listitem><para>
    Ionisation
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAIonisation 
      </para></listitem>
      <listitem><para>
        model classes is G4DNARuddIonisationModel
      </para></listitem>
    </itemizedlist>
  </para></listitem>

  <listitem><para>
    Charge increase
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAChargeIncrease
      </para></listitem>
      <listitem><para>
        model classes is G4DNADingfelderChargeIncreaseModel        
      </para></listitem>
    </itemizedlist>
  </para></listitem>

  <listitem><para>
    Charge decrease
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAChargeDecrease
      </para></listitem>
      <listitem><para>
        model classes is G4DNADingfelderChargeDecreaseModel
      </para></listitem>
    </itemizedlist>
  </para></listitem>
</itemizedlist>
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
 Helium++ (ionised twice) processes and models
</bridgehead>
<para>
<itemizedlist spacing="compact">
  <listitem><para>
    Excitation
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAExcitation
      </para></listitem>
      <listitem><para>
        model classes is G4DNAMillerGreenExcitationModel        
      </para></listitem>
    </itemizedlist>
  </para></listitem>

  <listitem><para>
    Ionisation
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAIonisation 
      </para></listitem>
      <listitem><para>
        model classes is G4DNARuddIonisationModel  
      </para></listitem>
    </itemizedlist>
  </para></listitem>

  <listitem><para>
    Charge decrease
    <itemizedlist spacing="compact">
      <listitem><para>
        process class is G4DNAChargeDecrease
      </para></listitem>
      <listitem><para>
        model classes is G4DNADingfelderChargeDecreaseModel
      </para></listitem>
    </itemizedlist>
  </para></listitem>
</itemizedlist>
</para>

<para>
An example of the registration of these processes in a physics list is 
given here below and may be found in the microdosimetry advanced example.


<informalexample>
<programlisting>
#include "G4DNAElastic.hh"
#include "G4DNAChampionElasticModel.hh"
#include "G4DNAScreenedRutherfordElasticModel.hh"

#include "G4DNAExcitation.hh"
#include "G4DNAEmfietzoglouExcitationModel.hh"
#include "G4DNAMillerGreenExcitationModel.hh"
#include "G4DNABornExcitationModel.hh"

#include "G4DNAIonisation.hh"
#include "G4DNABornIonisationModel.hh"
#include "G4DNARuddIonisationModel.hh"

#include "G4DNAChargeDecrease.hh"
#include "G4DNADingfelderChargeDecreaseModel.hh"

#include "G4DNAChargeIncrease.hh"
#include "G4DNADingfelderChargeIncreaseModel.hh"

//....oooOO0OOooo........oooOO0OOooo........oooOO0OOooo........oooOO0OOooo....

void PhysicsList::ConstructEM()
{
  theParticleIterator-&gt;reset();

  while( (*theParticleIterator)() )
  {

    G4ParticleDefinition* particle = theParticleIterator-&gt;value();
    G4ProcessManager* pmanager = particle-&gt;GetProcessManager();
    G4String particleName = particle-&gt;GetParticleName();

// DNA processes per particle type

    if (particleName == "e-") {

      G4DNAElastic* theDNAElasticProcess = new G4DNAElastic("e-_G4DNAElastic");
      theDNAElasticProcess-&gt;SetModel(new G4DNAChampionElasticModel());
      // or alternative model
      // theDNAElasticProcess-&gt;SetModel(new G4DNAScreenedRutherfordElasticModel());
      pmanager-&gt;AddDiscreteProcess(theDNAElasticProcess);

      pmanager-&gt;AddDiscreteProcess(new G4DNAExcitation("e-_G4DNAExcitation"));
      pmanager-&gt;AddDiscreteProcess(new G4DNAIonisation("e-_G4DNAIonisation"));
            
    } else if ( particleName == "proton" ) {

      pmanager-&gt;AddDiscreteProcess(new G4DNAExcitation("proton_G4DNAExcitation"));
      pmanager-&gt;AddDiscreteProcess(new G4DNAIonisation("proton_G4DNAIonisation"));
      pmanager-&gt;AddDiscreteProcess(new G4DNAChargeDecrease("proton_G4DNAChargeDecrease"));

    } else if ( particleName == "hydrogen" ) {

      pmanager-&gt;AddDiscreteProcess(new G4DNAIonisation("hydrogen_G4DNAIonisation"));
      pmanager-&gt;AddDiscreteProcess(new G4DNAChargeIncrease("hydrogen_G4DNAChargeIncrease"));

    } else if ( particleName == "alpha" ) {

      pmanager-&gt;AddDiscreteProcess(new G4DNAExcitation("alpha_G4DNAExcitation"));
      pmanager-&gt;AddDiscreteProcess(new G4DNAIonisation("alpha_G4DNAIonisation"));
      pmanager-&gt;AddDiscreteProcess(new G4DNAChargeDecrease("alpha_G4DNAChargeDecrease"));

    } else if ( particleName == "alpha+" ) {

      pmanager-&gt;AddDiscreteProcess(new G4DNAExcitation("alpha+_G4DNAExcitation"));
      pmanager-&gt;AddDiscreteProcess(new G4DNAIonisation("alpha+_G4DNAIonisation"));
      pmanager-&gt;AddDiscreteProcess(new G4DNAChargeDecrease("alpha+_G4DNAChargeDecrease"));
      pmanager-&gt;AddDiscreteProcess(new G4DNAChargeIncrease("alpha+_G4DNAChargeIncrease"));
            
    } else if ( particleName == "helium" ) {

      pmanager-&gt;AddDiscreteProcess(new G4DNAExcitation("helium_G4DNAExcitation"));
      pmanager-&gt;AddDiscreteProcess(new G4DNAIonisation("helium_G4DNAIonisation"));
      pmanager-&gt;AddDiscreteProcess(new G4DNAChargeIncrease("helium_G4DNAChargeIncrease"));

    }

  } // Loop on particles
}

//....oooOO0OOooo........oooOO0OOooo........oooOO0OOooo........oooOO0OOooo....
</programlisting>
</informalexample>
</para>

<para>
Note that in the above example, "alpha" particles are helium atoms ionised 
twice and "helium" particles are neutral helium atoms. The definition of 
particles in the physics list may be for example implemented as follows :

<informalexample>
<programlisting>
//....oooOO0OOooo........oooOO0OOooo........oooOO0OOooo........oooOO0OOooo......

#include "G4DNAGenericIonsManager.hh"
void PhysicsList::ConstructBaryons()
{
// construct baryons ---
// Geant4 DNA particles
G4GenericIon::GenericIonDefinition() ;
G4DNAGenericIonsManager * genericIonsManager;
genericIonsManager=G4DNAGenericIonsManager::Instance();
genericIonsManager-&gt;GetIon("alpha++");
genericIonsManager-&gt;GetIon("alpha+");
genericIonsManager-&gt;GetIon("helium");
genericIonsManager-&gt;GetIon("hydrogen");
}

//....oooOO0OOooo........oooOO0OOooo........oooOO0OOooo........oooOO0OOooo......
</programlisting>
</informalexample>
</para>

<para>
To run the Geant4-DNA extension, data files need to be copied by the 
user to his/her code repository. These files are distributed together 
with the Geant4 release. The user should set the environment variable 
G4LEDATA to the directory where he/she has copied the files.
</para>

</sect3>
</sect2>


<!-- ******************* Section (Level#2) ****************** -->
<sect2 id="sect.PhysProc.Had">
<title>
Hadronic Interactions
</title>

<para>
This section briefly introduces the hadronic physics processes
installed in Geant4. For details of the implementation of hadronic
interactions available in Geant4, please refer to the 
<ulink url="http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/PhysicsReferenceManual/html/PhysicsReferenceManual.html">
<emphasis role="bold">Physics Reference Manual</emphasis></ulink>.
</para>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Had.TreatCross">
<title>
Treatment of Cross Sections
</title>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
Cross section data sets
</bridgehead>

<para>
Each hadronic process object (derived from
<emphasis>G4HadronicProcess</emphasis>) may have one or more cross section data
sets associated with it. The term "data set" is meant, in a broad
sense, to be an object that encapsulates methods and data for
calculating total cross sections for a given process. The methods
and data may take many forms, from a simple equation using a few
hard-wired numbers to a sophisticated parameterisation using large
data tables. Cross section data sets are derived from the abstract
class <emphasis>G4VCrossSectionDataSet</emphasis>, and are required to implement
the following methods:

<informalexample>
<programlisting>
    G4bool IsApplicable( const G4DynamicParticle*, const G4Element* )
</programlisting>
</informalexample>
</para>

<para>
This method must return <literal>True</literal> if the data set is able to
calculate a total cross section for the given particle and
material, and <literal>False</literal> otherwise.

<informalexample>
<programlisting>
    G4double GetCrossSection( const G4DynamicParticle*, const G4Element* )
</programlisting>
</informalexample>
</para>

<para>
This method, which will be invoked only if <literal>True</literal> was
returned by <literal>IsApplicable</literal>, must return a cross section, in
Geant4 default units, for the given particle and material.

<informalexample>
<programlisting>
    void BuildPhysicsTable( const G4ParticleDefinition&amp; )
</programlisting>
</informalexample>
</para>

<para>
This method may be invoked to request the data set to recalculate
its internal database or otherwise reset its state after a change
in the cuts or other parameters of the given particle type.


<informalexample>
<programlisting>
    void DumpPhysicsTable( const G4ParticleDefinition&amp; ) = 0
</programlisting>
</informalexample>
</para>

<para>
This method may be invoked to request the data set to print its
internal database and/or other state information, for the given
particle type, to the standard output stream.
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
Cross section data store
</bridgehead>

<para>
Cross section data sets are used by the process for the
calculation of the physical interaction length. A given cross
section data set may only apply to a certain energy range, or may
only be able to calculate cross sections for a particular type of
particle. The class <emphasis>G4CrossSectionDataStore</emphasis> has been
provided to allow the user to specify, if desired, a series of data
sets for a process, and to arrange the priority of data sets so
that the appropriate one is used for a given energy range,
particle, and material. It implements the following public
methods:

<informalexample>
<programlisting>
    G4CrossSectionDataStore()

   ~G4CrossSectionDataStore()
</programlisting>
</informalexample>

and

<informalexample>
<programlisting>
    G4double GetCrossSection( const G4DynamicParticle*, const G4Element* )
</programlisting>
</informalexample>
</para>

<para>
For a given particle and material, this method returns a cross
section value provided by one of the collection of cross section
data sets listed in the data store object. If there are no known
data sets, a <literal>G4Exception</literal> is thrown and <literal>DBL_MIN</literal> is
returned. Otherwise, each data set in the list is queried, in
reverse list order, by invoking its <literal>IsApplicable</literal> method
for the given particle and material. The first data set object that
responds positively will then be asked to return a cross section
value via its <literal>GetCrossSection</literal> method. If no data set
responds positively, a <literal>G4Exception</literal> is thrown and
<literal>DBL_MIN</literal> is returned.
</para>

<para>
<informalexample>
<programlisting>
    void AddDataSet( G4VCrossSectionDataSet* aDataSet )
</programlisting>
</informalexample>

This method adds the given cross section data set to the end of the
list of data sets in the data store. For the evaluation of cross
sections, the list has a LIFO (Last In First Out) priority, meaning
that data sets added later to the list will have priority over
those added earlier to the list. Another way of saying this, is
that the data store, when given a <literal>GetCrossSection</literal> request,
does the <literal>IsApplicable</literal> queries in the reverse list order,
starting with the last data set in the list and proceeding to the
first, and the first data set that responds positively is used to
calculate the cross section.
</para>

<para>
<informalexample>
<programlisting>
    void BuildPhysicsTable( const G4ParticleDefinition&amp; aParticleType )
</programlisting>
</informalexample>

This method may be invoked to indicate to the data store that there
has been a change in the cuts or other parameters of the given
particle type. In response, the data store will invoke the
<literal>BuildPhysicsTable</literal> of each of its data sets.
</para>

<para>
<informalexample>
<programlisting>
    void DumpPhysicsTable( const G4ParticleDefinition&amp; )
</programlisting>
</informalexample>

This method may be used to request the data store to invoke the
<literal>DumpPhysicsTable</literal> method of each of its data sets.
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
Default cross sections
</bridgehead>

<para>
The defaults for total cross section data and calculations have
been encapsulated in the singleton class
<emphasis>G4HadronCrossSections</emphasis>. Each hadronic process:
<emphasis>G4HadronInelasticProcess</emphasis>, 
<emphasis>G4HadronElasticProcess</emphasis>,
<emphasis>G4HadronFissionProcess</emphasis>, 
and <emphasis>G4HadronCaptureProcess</emphasis>,
comes already equipped with a cross section data store and a
default cross section data set. The data set objects are really
just shells that invoke the singleton <emphasis>G4HadronCrossSections</emphasis>
to do the real work of calculating cross sections.
</para>

<para>
The default cross sections can be overridden in whole or in part
by the user. To this end, the base class <emphasis>G4HadronicProcess</emphasis>
has a ``get'' method:

<informalexample>
<programlisting>
    G4CrossSectionDataStore* GetCrossSectionDataStore()
</programlisting>
</informalexample>

which gives public access to the data store for each process. The
user's cross section data sets can be added to the data store
according to the following framework:

<informalexample>
<programlisting>
    G4Hadron...Process aProcess(...)

    MyCrossSectionDataSet myDataSet(...)

    aProcess.GetCrossSectionDataStore()-&gt;AddDataSet( &amp;MyDataSet )
</programlisting>
</informalexample>
</para>

<para>
The added data set will override the default cross section data
whenever so indicated by its <literal>IsApplicable</literal> method.
</para>

<para>
In addition to the ``get'' method, <emphasis>G4HadronicProcess</emphasis> also
has the method

<informalexample>
<programlisting>
    void SetCrossSectionDataStore( G4CrossSectionDataStore* )
</programlisting>
</informalexample>

which allows the user to completely replace the default data
store with a new data store.
</para>

<para>
It should be noted that a process does not send any information
about itself to its associated data store (and hence data set)
objects. Thus, each data set is assumed to be formulated to
calculate cross sections for one and only one type of process. Of
course, this does not prevent different data sets from sharing
common data and/or calculation methods, as in the case of the
<emphasis>G4HadronCrossSections</emphasis> class mentioned above. Indeed,
<emphasis>G4VCrossSectionDataSet</emphasis> specifies only the abstract interface
between physics processes and their data sets, and leaves the user
free to implement whatever sort of underlying structure is
appropriate.
</para>

<para>
The current implementation of the data set
<emphasis>G4HadronCrossSections</emphasis> reuses the total cross-sections for
inelastic and elastic scattering, radiative capture and fission as
used with <emphasis role="bold">GHEISHA</emphasis> to provide cross-sections 
for calculation
of the respective mean free paths of a given particle in a given
material.
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
Cross-sections for low energy neutron transport
</bridgehead>

<para>
The cross section data for low energy neutron transport are
organized in a set of files that are read in by the corresponding
data set classes at time zero. Hereby the file system is used, in
order to allow highly granular access to the data. The ``root''
directory of the cross-section directory structure is accessed
through an environment variable, <literal>NeutronHPCrossSections</literal>,
which is to be set by the user. The classes accessing the total
cross-sections of the individual processes, i.e., the cross-section
data set classes for low energy neutron transport, are
<emphasis>G4NeutronHPElasticData</emphasis>, 
<emphasis>G4NeutronHPCaptureData</emphasis>,
<emphasis>G4NeutronHPFissionData</emphasis>, 
and <emphasis>G4NeutronHPInelasticData</emphasis>.
</para>

<para>
For detailed descriptions of the low energy neutron total
cross-sections, they may be registered by the user as described
above with the data stores of the corresponding processes for
neutron interactions.
</para>

<para>
It should be noted that using these total cross section classes
does not require that the neutron_hp models also be used. It is up
to the user to decide whethee this is desirable or not for his
particular problem.
</para>

<para>
A prototype of the compact version of neutron cross sections derived from HP database 
are provided with new classes <emphasis>G4NeutronHPElasticData</emphasis>, 
<emphasis>G4NeutronCaptureXS</emphasis>,
<emphasis>G4NeutronElasticXS</emphasis>, 
and <emphasis>G4NeutronInelasticXS</emphasis>.
</para>

</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Had.AtRest">
<title>
Hadrons at Rest
</title>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
List of implemented "Hadron at Rest" processes
</bridgehead>

<para>
The following process classes have been implemented:

<itemizedlist spacing="compact">
  <listitem><para>
    pi- absorption (class name <emphasis>G4PionMinusAbsorptionAtRest</emphasis>
    or <emphasis>G4PiMinusAbsorptionAtRest</emphasis>)
  </para></listitem>
  <listitem><para>
    kaon- absorption (class name <emphasis>G4KaonMinusAbsorptionAtRest</emphasis>
    or <emphasis>G4KaonMinusAbsorption</emphasis>)
  </para></listitem>
  <listitem><para>
    neutron capture (class name <emphasis>G4NeutronCaptureAtRest</emphasis>)
  </para></listitem>
  <listitem><para>
    anti-proton annihilation (class name
    <emphasis>G4AntiProtonAnnihilationAtRest</emphasis>)
  </para></listitem>
  <listitem><para>
    anti-neutron annihilation (class name
    <emphasis>G4AntiNeutronAnnihilationAtRest</emphasis>)
  </para></listitem>
  <listitem><para>
    mu- capture (class name <emphasis>G4MuonMinusCaptureAtRest</emphasis>)
  </para></listitem>
  <listitem><para>
    alternative CHIPS model for any negativly charged particle
    (class name <emphasis>G4QCaptureAtRest</emphasis>)
  </para></listitem>
</itemizedlist>
</para>

<para>
Obviously the last process does not, strictly speaking, deal with a
``hadron at rest''. It does, nonetheless, share common features
with the others in the above list because of the implementation
model chosen. The differences between the alternative
implementation for kaon and pion absorption concern the fast part
of the emitted particle spectrum. G4PiMinusAbsorptionAtRest, and
G4KaonMinusAbsorptionAtRest focus especially on a good description
of this part of the spectrum.
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
Implementation Interface to Geant4
</bridgehead>

<para>
All of these classes are derived from the abstract class
<emphasis>G4VRestProcess</emphasis>. In addition to the constructor and
destructor methods, the following public methods of the abstract
class have been implemented for each of the above six
processes:

<itemizedlist spacing="compact">
  <listitem><para>
    <para>
    <literal>AtRestGetPhysicalInteractionLength( const G4Track&amp;,
    G4ForceCondition* )</literal>
    </para>
    <para>
    This method returns the time taken before the interaction actually
    occurs. In all processes listed above, except for muon capture, a
    value of zero is returned. For the muon capture process the muon
    capture lifetime is returned.
    </para>
  </para></listitem>
  <listitem><para>
    <para>
    <literal>AtRestDoIt( const G4Track&amp;, const G4Step&amp;)</literal>
    </para>
    <para>
    This method generates the secondary particles produced by the
    process.
    </para>
  </para></listitem>
  <listitem><para>
    <para>
    <literal>IsApplicable( const G4ParticleDefinition&amp; )</literal>
    </para>
    <para>
    This method returns the result of a check to see if the process is
    possible for a given particle.
    </para>
  </para></listitem>
</itemizedlist>
</para>


<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
Example of how to use a hadron at rest process
</bridgehead>

<para>
Including a ``hadron at rest'' process for a particle, a pi- for
example, into the Geant4 system is straightforward and can be done
in the following way:

<itemizedlist spacing="compact">
  <listitem><para>
    create a process:
    <informalexample>
    <programlisting>
       theProcess = new G4PionMinusAbsorptionAtRest();
    </programlisting>
    </informalexample>
  </para></listitem>
  <listitem><para>
    register the process with the particle's process manager:
    <informalexample>
    <programlisting>
       theParticleDef = G4PionMinus::PionMinus();
       G4ProcessManager* pman = theParticleDef-&gt;GetProcessManager();
       pman-&gt;AddRestProcess( theProcess );
    </programlisting>
    </informalexample>
  </para></listitem>
</itemizedlist>
</para>

</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Had.Flight">
<title>
Hadrons in Flight
</title>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
What processes do you need?
</bridgehead>

<para>
For hadrons in motion, there are four physics process classes.
<xref linkend="table.PhysProc_1" /> shows each process and the 
particles for which it is relevant.

<table id="table.PhysProc_1">
<title>
Hadronic processes and relevant particles.
</title>

<tgroup cols="2">
  <tbody>
  <row>
    <entry>
      <emphasis>G4HadronElasticProcess</emphasis>
    </entry>
    <entry>
      pi+, pi-, K<superscript>+</superscript>, 
      K<superscript>0</superscript><subscript>S</subscript>, 
      K<superscript>0</superscript><subscript>L</subscript>, 
      K<superscript>-</superscript>, 
      p, p-bar, n, n-bar, lambda, lambda-bar, 
      Sigma<superscript>+</superscript>, Sigma<superscript>-</superscript>,
      Sigma<superscript>+</superscript>-bar, 
      Sigma<superscript>-</superscript>-bar, 
      Xi<superscript>0</superscript>, Xi<superscript>-</superscript>, 
      Xi<superscript>0</superscript>-bar, Xi<superscript>-</superscript>-bar
    </entry>
  </row>
  <row>
    <entry>
      <emphasis>G4HadronInelasticProcess</emphasis>
    </entry>
    <entry>
      pi+, pi-, K<superscript>+</superscript>, 
      K<superscript>0</superscript><subscript>S</subscript>,
      K<superscript>0</superscript><subscript>L</subscript>, 
      K<superscript>-</superscript>, 
      p, p-bar, n, n-bar, lambda, lambda-bar, 
      Sigma<superscript>+</superscript>, Sigma<superscript>-</superscript>,
      Sigma<superscript>+</superscript>-bar, 
      Sigma<superscript>-</superscript>-bar, Xi<superscript>0</superscript>,
      Xi<superscript>-</superscript>, Xi<superscript>0</superscript>-bar, 
      Xi<superscript>-</superscript>-bar
    </entry>
  </row>
  <row>
    <entry>
      <emphasis>G4HadronFissionProcess</emphasis>
    </entry>
    <entry>
      all
    </entry>
  </row>
  <row>
    <entry>
      <emphasis>G4CaptureProcess</emphasis>
    </entry>
    <entry>
      n, n-bar
    </entry>
  </row>
  </tbody>
</tgroup>
</table>
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
How to register Models
</bridgehead>

<para>
To register an inelastic process model for a particle, a proton
for example, first get the pointer to the particle's process
manager:

<informalexample>
<programlisting>
   G4ParticleDefinition *theProton = G4Proton::ProtonDefinition();
   G4ProcessManager *theProtonProcMan = theProton-&gt;GetProcessManager();
</programlisting>
</informalexample>
</para>

<para>
Create an instance of the particle's inelastic process:

<informalexample>
<programlisting>
   G4ProtonInelasticProcess *theProtonIEProc = new G4ProtonInelasticProcess();
</programlisting>
</informalexample>
</para>

<para>
Create an instance of the model which determines the secondaries
produced in the interaction, and calculates the momenta of the
particles:

<informalexample>
<programlisting>
   G4LEProtonInelastic *theProtonIE = new G4LEProtonInelastic();
</programlisting>
</informalexample>
</para>

<para>
Register the model with the particle's inelastic process:

<informalexample>
<programlisting>
   theProtonIEProc-&gt;RegisterMe( theProtonIE );
</programlisting>
</informalexample>
</para>

<para>
Finally, add the particle's inelastic process to the list of
discrete processes:

<informalexample>
<programlisting>
   theProtonProcMan-&gt;AddDiscreteProcess( theProtonIEProc );
</programlisting>
</informalexample>
</para>

<para>
The particle's inelastic process class,
<emphasis>G4ProtonInelasticProcess</emphasis> in the example above, derives from
the <emphasis>G4HadronicInelasticProcess</emphasis> class, and simply defines the
process name and calls the <emphasis>G4HadronicInelasticProcess</emphasis>
constructor. All of the specific particle inelastic processes
derive from the <emphasis>G4HadronicInelasticProcess</emphasis> class, which
calls the <literal>PostStepDoIt</literal> function, which returns the
particle change object from the <emphasis>G4HadronicProcess</emphasis> function
<literal>GeneralPostStepDoIt</literal>. This class also gets the mean free
path, builds the physics table, and gets the microscopic cross
section. The <emphasis>G4HadronicInelasticProcess</emphasis> class derives from
the <emphasis>G4HadronicProcess</emphasis> class, which is the top level hadronic
process class. The <emphasis>G4HadronicProcess</emphasis> class derives from the
<emphasis>G4VDiscreteProcess</emphasis> class. The inelastic, elastic, capture,
and fission processes derive from the <emphasis>G4HadronicProcess</emphasis>
class. This pure virtual class also provides the energy range
manager object and the <literal>RegisterMe</literal> access function.
</para>

<para>
A sample case for the proton's inelastic interaction model class
is shown in <xref linkend="programlist_PhysProc_3" />, where
<literal>G4LEProtonInelastic.hh</literal> is the name of the include
file:

<example id="programlist_PhysProc_3">
<title>
An example of a proton inelastic interaction model class.
</title>

<programlisting>
 ----------------------------- include file ------------------------------------------

#include "G4InelasticInteraction.hh"
 class G4LEProtonInelastic : public G4InelasticInteraction
 {
 public:
    G4LEProtonInelastic() : G4InelasticInteraction()
    {
      SetMinEnergy( 0.0 );
      SetMaxEnergy( 25.*GeV );
    }
    ~G4LEProtonInelastic() { }
    G4ParticleChange *ApplyYourself( const G4Track &amp;aTrack,
                                     G4Nucleus &amp;targetNucleus );
 private:
    void CascadeAndCalculateMomenta( required arguments );
 };

 ----------------------------- source file ------------------------------------------

 #include "G4LEProtonInelastic.hh"
 G4ParticleChange *
  G4LEProton Inelastic::ApplyYourself( const G4Track &amp;aTrack,
                                       G4Nucleus &amp;targetNucleus )
  {
    theParticleChange.Initialize( aTrack );
    const G4DynamicParticle *incidentParticle = aTrack.GetDynamicParticle();
    // create the target particle
    G4DynamicParticle *targetParticle = targetNucleus.ReturnTargetParticle();
    CascadeAndCalculateMomenta( required arguments )
    { ... }
    return &amp;theParticleChange;
  }
</programlisting>
</example>
</para>

<para>
The <literal>CascadeAndCalculateMomenta</literal> function is the bulk of
the model and is to be provided by the model's creator. It should
determine what secondary particles are produced in the interaction,
calculate the momenta for all the particles, and put this
information into the <emphasis>ParticleChange</emphasis> object which is
returned.
</para>

<para>
The <emphasis>G4LEProtonInelastic</emphasis> class derives from the
<emphasis>G4InelasticInteraction</emphasis> class, which is an abstract base
class since the pure virtual function <literal>ApplyYourself</literal> is not
defined there. <emphasis>G4InelasticInteraction</emphasis> itself derives from
the <emphasis>G4HadronicInteraction</emphasis> abstract base class. This class is
the base class for all the model classes. It sorts out the energy
range for the models and provides class utilities. The
<emphasis>G4HadronicInteraction</emphasis> class provides the
<literal>Set/GetMinEnergy</literal> and the <literal>Set/GetMaxEnergy</literal>
functions which determine the minimum and maximum energy range for
the model. An energy range can be set for a specific element, a
specific material, or for general applicability:

<informalexample>
<programlisting>
 void SetMinEnergy( G4double anEnergy, G4Element *anElement )
 void SetMinEnergy( G4double anEnergy, G4Material *aMaterial )
 void SetMinEnergy( const G4double anEnergy )
 void SetMaxEnergy( G4double anEnergy, G4Element *anElement )
 void SetMaxEnergy( G4double anEnergy, G4Material *aMaterial )
 void SetMaxEnergy( const G4double anEnergy )
</programlisting>
</informalexample>
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
Which models are there, and what are the defaults
</bridgehead>

<para>
In Geant4, any model can be run together with any other model
without the need for the implementation of a special interface, or
batch suite, and the ranges of applicability for the different
models can be steered at initialisation time. This way, highly
specialised models (valid only for one material and particle, and
applicable only in a very restricted energy range) can be used in
the same application, together with more general code, in a
coherent fashion.
</para>

<para>
Each model has an intrinsic range of applicability, and the
model chosen for a simulation depends very much on the use-case.
Consequently, there are no ``defaults''. However, physics lists are
provided which specify sets of models for various purposes.
</para>

<para>
Three types of hadronic shower models have been implemented:
parametrisation driven models, data driven models, and theory
driven models.

<itemizedlist spacing="compact">
  <listitem><para>
    Parametrisation driven models are used for all processes
    pertaining to particles coming to rest, and interacting with the
    nucleus. For particles in flight, two sets of models exist for
    inelastic scattering; low energy, and high energy models. Both sets
    are based originally on the <emphasis role="bold">GHEISHA</emphasis> 
    package of Geant3.21,
    and the original approaches to primary interaction, nuclear
    excitation, intra-nuclear cascade and evaporation is kept. The
    models are located in the sub-directories
    <literal>hadronics/models/low_energy</literal> and
    <literal>hadronics/models/high_energy</literal>. The low energy models are
    targeted towards energies below 20 GeV; the high energy models
    cover the energy range from 20 GeV to O(TeV). Fission, capture and
    coherent elastic scattering are also modeled through parametrised
    models.
  </para></listitem>
  <listitem><para>
    Data driven models are available for the transport of low
    energy neutrons in matter in sub-directory
    <literal>hadronics/models/neutron_hp</literal>. The modeling is based 
    on the data formats of <emphasis role="bold">ENDF/B-VI</emphasis>, 
    and all distributions of this standard data format are implemented. 
    The data sets used are selected from data libraries that conform to 
    these standard formats. The file system is used in order to allow granular 
    access to, and flexibility in, the use of the cross sections for different
    isotopes, and channels. The energy coverage of these models is from
    thermal energies to 20 MeV.
  </para></listitem>
  <listitem><para>
    Theory driven models are available for inelastic scattering in
    a first implementation, covering the full energy range of LHC
    experiments. They are located in sub-directory
    <literal>hadronics/models/generator</literal>. The current philosophy 
    implies the usage of parton string models at high energies, of
    intra-nuclear transport models at intermediate energies, and of
    statistical break-up models for de-excitation.
  </para></listitem>
</itemizedlist>
</para>

</sect3>
</sect2>

<!-- ******************* Section (Level#2) ****************** -->
<sect2 id="sect.PhysProc.Decay">
<title>
Particle Decay Process
</title>

<para>
This section briefly introduces decay processes installed in
Geant4. For details of the implementation of particle decays,
please refer to the 
<ulink url="http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/PhysicsReferenceManual/html/PhysicsReferenceManual.html">
<emphasis role="bold">Physics Reference Manual</emphasis></ulink>.
</para>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Decay.Class">
<title>
Particle Decay Class
</title>

<para>
Geant4 provides a <emphasis>G4Decay</emphasis> class for both ``at rest'' and
``in flight'' particle decays. <emphasis>G4Decay</emphasis> can be applied to all
particles except:

<variablelist>
  <varlistentry>
    <term>
      massless particles, i.e.,
    </term>
    <listitem>
      <literal>G4ParticleDefinition::thePDGMass &lt;= 0</literal>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term>
      particles with ``negative'' life time, i.e.,
    </term>
    <listitem>
      <literal>G4ParticleDefinition::thePDGLifeTime &lt; 0</literal>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term>
      shortlived particles, i.e.,
    </term>
    <listitem>
      <literal>G4ParticleDefinition::fShortLivedFlag = True</literal>
    </listitem>
  </varlistentry>
</variablelist>
</para>

<para>
Decay for some particles may be switched on or off by using
<literal>G4ParticleDefinition::SetPDGStable()</literal> as well as
<literal>ActivateProcess()</literal> and <literal>InActivateProcess()</literal> 
methods of <emphasis>G4ProcessManager</emphasis>.
</para>

<para>
<emphasis>G4Decay</emphasis> proposes the step length (or step time for
<literal>AtRest</literal>) according to the lifetime of the particle unless
<literal>PreAssignedDecayProperTime</literal> is defined in
<emphasis>G4DynamicParticle</emphasis>.
</para>

<para>
The <emphasis>G4Decay</emphasis> class itself does not define decay modes of
the particle. Geant4 provides two ways of doing this:

<itemizedlist spacing="compact">
  <listitem><para>
    using <emphasis>G4DecayChannel</emphasis> in <emphasis>G4DecayTable</emphasis>, 
    and
  </para></listitem>
  <listitem><para>
    using <literal>thePreAssignedDecayProducts</literal> of
    <emphasis>G4DynamicParticle</emphasis>
  </para></listitem>
</itemizedlist>
</para>

<para>
The <emphasis>G4Decay</emphasis> class calculates the
<literal>PhysicalInteractionLength</literal> and boosts decay products
created by <emphasis>G4VDecayChannel</emphasis> or event generators. See below
for information on the determination of the decay modes.
</para>

<para>
An object of <emphasis>G4Decay</emphasis> can be shared by particles.
Registration of the decay process to particles in the
<literal>ConstructPhysics</literal> method of <emphasis>PhysicsList</emphasis> 
(see <xref linkend="sect.HowToSpecPhysProc.SpecPhysProc" />) 
is shown in <xref linkend="programlist_PhysProc_4" />.

<example id="programlist_PhysProc_4">
<title>
Registration of the decay process to particles in the
<literal>ConstructPhysics</literal> method of <emphasis>PhysicsList</emphasis>.
</title>

<programlisting>
#include "G4Decay.hh"
void ExN02PhysicsList::ConstructGeneral()
{
  // Add Decay Process
  G4Decay* theDecayProcess = new G4Decay();
  theParticleIterator-&gt;reset();
  while( (*theParticleIterator)() ){
    G4ParticleDefinition* particle = theParticleIterator-&gt;value();
    G4ProcessManager* pmanager = particle-&gt;GetProcessManager();
    if (theDecayProcess-&gt;IsApplicable(*particle)) { 
      pmanager -&gt;AddProcess(theDecayProcess);
      // set ordering for PostStepDoIt and AtRestDoIt
      pmanager -&gt;SetProcessOrdering(theDecayProcess, idxPostStep);
      pmanager -&gt;SetProcessOrdering(theDecayProcess, idxAtRest);
    }
  }
}
</programlisting>
</example>
</para>

</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Decay.Table">
<title>
Decay Table
</title>

<para>
Each particle has its <emphasis>G4DecayTable</emphasis>, which stores information
on the decay modes of the particle. Each decay mode, with its
branching ratio, corresponds to an object of various ``decay
channel'' classes derived from <emphasis>G4VDecayChannel</emphasis>. Default
decay modes are created in the constructors of particle classes.
For example, the decay table of the neutral pion has
<emphasis>G4PhaseSpaceDecayChannel</emphasis> and 
<emphasis>G4DalitzDecayChannel</emphasis> as follows:

<informalexample>
<programlisting>
  // create a decay channel
  G4VDecayChannel* mode;
  // pi0 -&gt; gamma + gamma
  mode = new G4PhaseSpaceDecayChannel("pi0",0.988,2,"gamma","gamma");
  table-&gt;Insert(mode);
  // pi0 -&gt; gamma + e+ + e-
  mode = new G4DalitzDecayChannel("pi0",0.012,"e-","e+");
  table-&gt;Insert(mode);
</programlisting>
</informalexample>
</para>

<para>
Decay modes and branching ratios defined in Geant4 are listed in
<xref linkend="sect.Parti.Def" />.
</para>

<para>
Branching ratios and life time can be set in tracking time.
<informalexample>
<programlisting>
  // set lifetime 
  G4Neutron::Neutron()->SetPDGLifeTime(885.7*second);
  // allow neutron decay
  G4Neutron::Neutron()->SetPDGStable(false);
</programlisting>
</informalexample>
</para>

<para>
Branching ratios and life time can be modified by using user commands, also.
</para>

<para>
<emphasis role="bold">Example: Set 100% br for dalitz decay of pi0</emphasis>

<informalexample>
<programlisting>
  Idle&gt; /particle/select pi0
  Idle&gt; /particle/property/decay/select 0
  Idle&gt; /particle/property/decay/br 0
  Idle&gt; /particle/property/decay/select 1
  Idle&gt; /particle/property/decay/br 1
  Idle&gt; /particle/property/decay/dump
        G4DecayTable:  pi0
           0:  BR:  0  [Phase Space]   :   gamma gamma
           1:  BR:  1  [Dalitz Decay]  :   gamma e- e+
</programlisting>
</informalexample>

</para>

</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Decay.PreAssgn">
<title>
Pre-assigned Decay Modes by Event Generators
</title>

<para>
Decays of heavy flavor particles such as B mesons are very complex,
with many varieties of decay modes and decay mechanisms. There are
many models for heavy particle decay provided by various event
generators and it is impossible to define all the decay modes of
heavy particles by using <emphasis>G4VDecayChannel</emphasis>. In other words,
decays of heavy particles cannot be defined by the Geant4 decay
process, but should be defined by event generators or other
external packages. Geant4 provides two ways to do this:
<literal>pre-assigned decay mode</literal> and <literal>external decayer</literal>.
</para>

<para>
In the latter approach, the class <emphasis>G4VExtDecayer</emphasis> is used
for the interface to an external package which defines decay modes
for a particle. If an instance of <emphasis>G4VExtDecayer</emphasis> is attached
to <emphasis>G4Decay</emphasis>, daughter particles will be generated by the
external decay handler.
</para>

<para>
In the former case, decays of heavy particles are simulated by
an event generator and the primary event contains the decay
information. <emphasis>G4VPrimaryGenerator</emphasis> automatically attaches any
daughter particles to the parent particle as the
PreAssignedDecayProducts member of <emphasis>G4DynamicParticle</emphasis>.
<emphasis>G4Decay</emphasis> adopts these pre-assigned daughter particles instead
of asking <emphasis>G4VDecayChannel</emphasis> to generate decay products.
</para>

<para>
In addition, the user may assign a <literal>pre-assigned</literal> decay
time for a specific track in its rest frame (i.e. decay time is
defined in the proper time) by using the
<emphasis>G4PrimaryParticle::SetProperTime()</emphasis> method.
<emphasis>G4VPrimaryGenerator</emphasis> sets the PreAssignedDecayProperTime
member of <emphasis>G4DynamicParticle</emphasis>. <emphasis>G4Decay</emphasis> 
uses this decay time instead of the life time of the particle type.
</para>

</sect3>
</sect2>


<!-- ******************* Section (Level#2) ****************** -->
<sect2 id="sect.PhysProc.PhotoHad">
<title>
Photolepton-hadron Processes
</title>

<para>
To be delivered.
</para>

</sect2>


<!-- ******************* Section (Level#2) ****************** -->
<sect2 id="sect.PhysProc.Photo">
<title>
Optical Photon Processes
</title>

<para>
A photon is considered to be <emphasis>optical</emphasis> when its wavelength
is much greater than the typical atomic spacing. In GEANT4 optical
photons are treated as a class of particle distinct from their
higher energy <emphasis>gamma</emphasis> cousins. This implementation allows the
wave-like properties of electromagnetic radiation to be
incorporated into the optical photon process. Because this
theoretical description breaks down at higher energies, there is no
smooth transition as a function of energy between the optical
photon and gamma particle classes.
</para>

<para>
For the simulation of optical photons to work correctly in
GEANT4, they must be imputed a linear polarization. This is unlike
most other particles in GEANT4 but is automatically and correctly
done for optical photons that are generated as secondaries by
existing processes in GEANT4. Not so, if the user wishes to start
optical photons as primary particles. In this case, the user must
set the linear polarization using particle gun methods, the General
Particle Source, or his/her PrimaryGeneratorAction. For an
unpolarized source, the linear polarization should be sampled
randomly for each new primary photon.
</para>

<para>
The GEANT4 catalogue of processes at optical wavelengths
includes refraction and reflection at medium boundaries, bulk
absorption and Rayleigh scattering. Processes which produce optical
photons include the Cerenkov effect, transition radiation and
scintillation. Optical photons are generated in GEANT4 without
energy conservation and their energy must therefore not be tallied
as part of the energy balance of an event.
</para>

<para>
The optical properties of the medium which are key to the
implementation of these types of processes are stored as entries in
a <literal>G4MaterialPropertiesTable</literal> which is linked to the
<literal>G4Material</literal> in question. These properties may be constants
or they may be expressed as a function of the photon's wavelength.
This table is a private data member of the <literal>G4Material</literal>
class. The <literal>G4MaterialPropertiesTable</literal> is implemented as a
hash directory, in which each entry consists of a <emphasis>value</emphasis> and
a <emphasis>key</emphasis>. The key is used to quickly and efficiently retrieve
the corresponding value. All values in the dictionary are either
instantiations of <literal>G4double</literal> or the class
<literal>G4MaterialPropertyVector</literal>, and all keys are of type
<literal>G4String</literal>.
</para>

<para>
A <literal>G4MaterialPropertyVector</literal> is composed of
instantiations of the class <literal>G4MPVEntry</literal>. The
<literal>G4MPVEntry</literal> is a pair of numbers, which in the case of an
optical property, are the photon momentum and corresponding
property value. The <literal>G4MaterialPropertyVector</literal> is
implemented as a <literal>G4std::vector</literal>, with the sorting operation
defined as 
MPVEntry<subscript>1</subscript> &lt; MPVEntry<subscript>2</subscript> ==
photon_momentum<subscript>1</subscript> &lt; photon_momentum<subscript>2</subscript>. 
This results in all <literal>G4MaterialPropertyVector</literal>s being sorted in
ascending order of photon momenta. It is possible for the user to
add as many material (optical) properties to the material as he
wishes using the methods supplied by the
<literal>G4MaterialPropertiesTable</literal> class. An example of this is
shown in <xref linkend="programlist_PhysProc_5" />.

<example id="programlist_PhysProc_5">
<title>
Optical properties added to a <literal>G4MaterialPropertiesTable</literal> 
and linked to a <literal>G4Material</literal>
</title>

<programlisting>
const G4int NUMENTRIES = 32;

G4double ppckov[NUMENTRIES] = {2.034*eV, ......, 4.136*eV};
G4double rindex[NUMENTRIES] = {1.3435, ......, 1.3608};
G4double absorption[NUMENTRIES] = {344.8*cm, ......, 1450.0*cm];

G4MaterialPropertiesTable *MPT = new G4MaterialPropertiesTable();

MPT -&gt; AddConstProperty("SCINTILLATIONYIELD",100./MeV);

MPT -&gt; AddProperty("RINDEX",ppckov,rindex,NUMENTRIES};
MPT -&gt; AddProperty("ABSLENGTH",ppckov,absorption,NUMENTRIES};

scintillator -&gt; SetMaterialPropertiesTable(MPT);
</programlisting>
</example>
</para>


<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Photo.Cerenkov">
<title>
Generation of Photons in 
<literal>processes/electromagnetic/xrays</literal> - Cerenkov Effect
</title>

<para>
The radiation of Cerenkov light occurs when a charged particle
moves through a dispersive medium faster than the group velocity of
light in that medium. Photons are emitted on the surface of a cone,
whose opening angle with respect to the particle's instantaneous
direction decreases as the particle slows down. At the same time,
the frequency of the photons emitted increases, and the number
produced decreases. When the particle velocity drops below the
local speed of light, the radiation ceases and the emission cone
angle collapses to zero. The photons produced by this process have
an inherent polarization perpendicular to the cone's surface at
production.
</para>

<para>
The flux, spectrum, polarization and emission of Cerenkov
radiation in the <literal>AlongStepDoIt</literal> method of the class
<literal>G4Cerenkov</literal> follow well-known formulae, with two inherent
computational limitations. The first arises from step-wise
simulation, and the second comes from the requirement that
numerical integration calculate the average number of Cerenkov
photons per step. The process makes use of a
<literal>G4PhysicsTable</literal> which contains incremental integrals to
expedite this calculation.
</para>

<para>
The time and position of Cerenkov photon emission are calculated
from quantities known at the beginning of a charged particle's
step. The step is assumed to be rectilinear even in the presence of
a magnetic field. The user may limit the step size by specifying a
maximum (average) number of Cerenkov photons created during the
step, using the <literal>SetMaxNumPhotonsPerStep(const G4int
NumPhotons)</literal> method. The actual number generated will
necessarily be different due to the Poissonian nature of the
production. In the present implementation, the production density
of photons is distributed evenly along the particle's track
segment, even if the particle has slowed significantly during the
step.
</para>

<para>
The frequently very large number of secondaries produced in a
single step (about 300/cm in water), compelled the idea in
GEANT3.21 of suspending the primary particle until all its progeny
have been tracked. Despite the fact that GEANT4 employs dynamic
memory allocation and thus does not suffer from the limitations of
GEANT3.21 with its fixed large initial ZEBRA store, GEANT4
nevertheless provides for an analogous functionality with the
public method <literal>SetTrackSecondariesFirst</literal>. An example of the
registration of the Cerenkov process is given in 
<xref linkend="programlist_PhysProc_6" />.

<example id="programlist_PhysProc_6">
<title>
Registration of the Cerenkov process in <literal>PhysicsList</literal>.
</title>

<programlisting>
#include "G4Cerenkov.hh"

void ExptPhysicsList::ConstructOp(){

  G4Cerenkov*   theCerenkovProcess = new G4Cerenkov("Cerenkov");

  G4int MaxNumPhotons = 300;

  theCerenkovProcess-&gt;SetTrackSecondariesFirst(true);
  theCerenkovProcess-&gt;SetMaxNumPhotonsPerStep(MaxNumPhotons);

  theParticleIterator-&gt;reset();
  while( (*theParticleIterator)() ){
    G4ParticleDefinition* particle = theParticleIterator-&gt;value();
    G4ProcessManager* pmanager = particle-&gt;GetProcessManager();
    G4String particleName = particle-&gt;GetParticleName();
    if (theCerenkovProcess-&gt;IsApplicable(*particle)) {
      pmanager-&gt;AddContinuousProcess(theCerenkovProcess);
    }
  }
}
</programlisting>
</example>
</para>

</sect3>


<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Photo.Scinti">
<title>
Generation of Photons in 
<literal>processes/electromagnetic/xrays</literal> - Scintillation
</title>

<para>
Every scintillating material has a characteristic light yield,
<literal>SCINTILLATIONYIELD</literal>, and an intrinsic resolution,
<literal>RESOLUTIONSCALE</literal>, which generally broadens the statistical
distribution of generated photons. A wider intrinsic resolution is
due to impurities which are typical for doped crystals like NaI(Tl)
and CsI(Tl). On the other hand, the intrinsic resolution can also
be narrower when the Fano factor plays a role. The actual number of
emitted photons during a step fluctuates around the mean number of
photons with a width given by
<literal>ResolutionScale*sqrt(MeanNumberOfPhotons)</literal>. The average
light yield, <literal>MeanNumberOfPhotons</literal>, has a linear dependence
on the local energy deposition, but it may be different for minimum
ionizing and non-minimum ionizing particles.
</para>

<para>
A scintillator is also characterized by its photon emission
spectrum and by the exponential decay of its time spectrum. In
GEANT4 the scintillator can have a fast and a slow component. The
relative strength of the fast component as a fraction of total
scintillation yield is given by the <literal>YIELDRATIO</literal>.
Scintillation may be simulated by specifying these empirical
parameters for each material. It is sufficient to specify in the
user's <literal>DetectorConstruction</literal> class a relative spectral
distribution as a function of photon energy for the scintillating
material. An example of this is shown in 
<xref linkend="programlist_PhysProc_7" />

<example id="programlist_PhysProc_7">
<title>
Specification of scintillation properties in
<literal>DetectorConstruction</literal>.
</title>
<programlisting>
  const G4int NUMENTRIES = 9;
  G4double Scnt_PP[NUMENTRIES] = { 6.6*eV, 6.7*eV, 6.8*eV, 6.9*eV,
                                   7.0*eV, 7.1*eV, 7.2*eV, 7.3*eV, 7.4*eV };

  G4double Scnt_FAST[NUMENTRIES] = { 0.000134, 0.004432, 0.053991, 0.241971, 
                                     0.398942, 0.000134, 0.004432, 0.053991,
                                     0.241971 };
  G4double Scnt_SLOW[NUMENTRIES] = { 0.000010, 0.000020, 0.000030, 0.004000,
                                     0.008000, 0.005000, 0.020000, 0.001000,
                                     0.000010 };

  G4Material* Scnt;
  G4MaterialPropertiesTable* Scnt_MPT = new G4MaterialPropertiesTable();

  Scnt_MPT-&gt;AddProperty("FASTCOMPONENT", Scnt_PP, Scnt_FAST, NUMENTRIES);
  Scnt_MPT-&gt;AddProperty("SLOWCOMPONENT", Scnt_PP, Scnt_SLOW, NUMENTRIES);

  Scnt_MPT-&gt;AddConstProperty("SCINTILLATIONYIELD", 5000./MeV);
  Scnt_MPT-&gt;AddConstProperty("RESOLUTIONSCALE", 2.0);
  Scnt_MPT-&gt;AddConstProperty("FASTTIMECONSTANT",  1.*ns);
  Scnt_MPT-&gt;AddConstProperty("SLOWTIMECONSTANT", 10.*ns);
  Scnt_MPT-&gt;AddConstProperty("YIELDRATIO", 0.8);

  Scnt-&gt;SetMaterialPropertiesTable(Scnt_MPT);
</programlisting>
</example>
</para>

<para>
In cases where the scintillation yield of a scintillator depends
on the particle type, different scintillation processes may be
defined for them. How this yield scales to the one specified for
the material is expressed with the
<literal>ScintillationYieldFactor</literal> in the user's
<literal>PhysicsList</literal> as shown in 
<xref linkend="programlist_PhysProc_8" />. 
In those cases where the fast to slow excitation ratio changes with particle
type, the method <literal>SetScintillationExcitationRatio</literal> can be
called for each scintillation process (see the advanced
underground_physics example). This overwrites the
<literal>YieldRatio</literal> obtained from the
<literal>G4MaterialPropertiesTable</literal>.

<example id="programlist_PhysProc_8">
<title>
Implementation of the scintillation process in
<literal>PhysicsList</literal>.
</title>

<programlisting>
  G4Scintillation* theMuonScintProcess = new G4Scintillation("Scintillation");

  theMuonScintProcess-&gt;SetTrackSecondariesFirst(true);
  theMuonScintProcess-&gt;SetScintillationYieldFactor(0.8);

  theParticleIterator-&gt;reset();
  while( (*theParticleIterator)() ){
    G4ParticleDefinition* particle = theParticleIterator-&gt;value();
    G4ProcessManager* pmanager = particle-&gt;GetProcessManager();
    G4String particleName = particle-&gt;GetParticleName();
    if (theMuonScintProcess-&gt;IsApplicable(*particle)) {
       if (particleName == "mu+") {
          pmanager-&gt;AddProcess(theMuonScintProcess);
          pmanager-&gt;SetProcessOrderingToLast(theMuonScintProcess, idxAtRest);
          pmanager-&gt;SetProcessOrderingToLast(theMuonScintProcess, idxPostStep);
       }
    }
  }
</programlisting>
</example>
</para>

<para>
A Gaussian-distributed number of photons is generated according
to the energy lost during the step. A resolution scale of 1.0
produces a statistical fluctuation around the average yield set
with <literal>AddConstProperty("SCINTILLATIONYIELD")</literal>, while values
&gt; 1 broaden the fluctuation. A value of zero produces no
fluctuation. Each photon's frequency is sampled from the empirical
spectrum. The photons originate evenly along the track segment and
are emitted uniformly into 4&pi; with a random linear polarization
and at times characteristic for the scintillation component.
</para>

</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Photo.WaveShift">
<title>
Generation of Photons in 
<literal>processes/optical</literal> - Wavelength Shifting
</title>

<para>
Wavelength Shifting (WLS) fibers are used in many high-energy
particle physics experiments. They absorb light at one wavelength
and re-emit light at a different wavelength and are used for
several reasons. For one, they tend to decrease the self-absorption
of the detector so that as much light reaches the PMTs as possible.
WLS fibers are also used to match the emission spectrum of the
detector with the input spectrum of the PMT.
</para>

<para>
A WLS material is characterized by its photon absorption and
photon emission spectrum and by a possible time delay between the
absorption and re-emission of the photon. Wavelength Shifting may
be simulated by specifying these empirical parameters for each WLS
material in the simulation. It is sufficient to specify in the
user's <literal>DetectorConstruction</literal> class a relative spectral
distribution as a function of photon energy for the WLS material.
WLSABSLENGTH is the absorption length of the material as a function
of the photon's momentum. WLSCOMPONENT is the relative emission
spectrum of the material as a function of the photon's momentum,
and WLSTIMECONSTANT accounts for any time delay which may occur
between absorption and re-emission of the photon. An example is
shown in <xref linkend="programlist_PhysProc_9" />.

<example id="programlist_PhysProc_9">
<title>
Specification of WLS properties in <literal>DetectorConstruction</literal>.
</title>

<programlisting>
 const G4int nEntries = 9;

 G4double PhotonEnergy[nEntries] = { 6.6*eV, 6.7*eV, 6.8*eV, 6.9*eV,
                                   7.0*eV, 7.1*eV, 7.2*eV, 7.3*eV, 7.4*eV };

 G4double RIndexFiber[nEntries] =
           { 1.60, 1.60, 1.60, 1.60, 1.60, 1.60, 1.60, 1.60, 1.60 };
 G4double AbsFiber[nEntries] =
           {0.1*mm,0.2*mm,0.3*mm,0.4*cm,1.0*cm,10*cm,1.0*m,10.0*m,10.0*m};
 G4double EmissionFiber[nEntries] =
           {0.0, 0.0, 0.0, 0.1, 0.5, 1.0, 5.0, 10.0, 10.0 };

  G4Material* WLSFiber;
  G4MaterialPropertiesTable* MPTFiber = new G4MaterialPropertiesTable();

  MPTFiber-&gt;AddProperty("RINDEX",PhotonEnergy,RIndexFiber,nEntries);
  MPTFiber-&gt;AddProperty("WLSABSLENGTH",PhotonEnergy,AbsFiber,nEntries);
  MPTFiber-&gt;AddProperty("WLSCOMPONENT",PhotonEnergy,EmissionFiber,nEntries);
  MPTFiber-&gt;AddConstProperty("WLSTIMECONSTANT", 0.5*ns);

  WLSFiber-&gt;SetMaterialPropertiesTable(MPTFiber);
</programlisting>
</example>
</para>

<para>
The process is defined in the PhysicsList in the usual way. The
process class name is G4OpWLS. It should be instantiated with
theWLSProcess = new G4OpWLS("OpWLS") and attached to the process
manager of the optical photon as a DiscreteProcess. The way the
WLSTIMECONSTANT is used depends on the time profile method chosen
by the user. If in the PhysicsList
theWLSProcess-&gt;UseTimeGenerator("exponential") option is set,
the time delay between absorption and re-emission of the photon is
sampled from an exponential distribution, with the decay term equal
to WLSTIMECONSTANT. If, on the other hand,
theWLSProcess-&gt;UseTimeGenerator("delta") is chosen, the time
delay is a delta function and equal to WLSTIMECONSTANT. The default
is "delta" in case the G4OpWLS::UseTimeGenerator(const G4String
name) method is not used.
</para>

</sect3>


<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Photo.Track">
<title>
Tracking of Photons in <literal>processes/optical</literal>
</title>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
Absorption
</bridgehead>

<para>
The implementation of optical photon bulk absorption,
<literal>G4OpAbsorption</literal>, is trivial in that the process merely
kills the particle. The procedure requires the user to fill the
relevant <literal>G4MaterialPropertiesTable</literal> with empirical data for
the absorption length, using <literal>ABSLENGTH</literal> as the property key
in the public method <literal>AddProperty</literal>. The absorption length is
the average distance traveled by a photon before being absorpted by
the medium; i.e. it is the mean free path returned by the
<literal>GetMeanFreePath</literal> method.
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
Rayleigh Scattering
</bridgehead>

<para>
The differential cross section in Rayleigh scattering,
&sigma;/&omega;, is proportional 
to cos<superscript>2</superscript>(&thetas;),
where &thetas; is the polar of the new polarization vector with
respect to the old polarization vector. The <literal>G4OpRayleigh</literal>
scattering process samples this angle accordingly and then
calculates the scattered photon's new direction by requiring that
it be perpendicular to the photon's new polarization in such a way
that the final direction, initial and final polarizations are all
in one plane. This process thus depends on the particle's
polarization (spin). The photon's polarization is a data member of
the <literal>G4DynamicParticle</literal> class.
</para>

<para>
A photon which is not assigned a polarization at production,
either via the <literal>SetPolarization</literal> method of the
<literal>G4PrimaryParticle</literal> class, or indirectly with the
<literal>SetParticlePolarization</literal> method of the
<literal>G4ParticleGun</literal> class, may not be Rayleigh scattered.
Optical photons produced by the <literal>G4Cerenkov</literal> process have
inherently a polarization perpendicular to the cone's surface at
production. Scintillation photons have a random linear polarization
perpendicular to their direction.
</para>

<para>
The process requires a <literal>G4MaterialPropertiesTable</literal> to be
filled by the user with Rayleigh scattering length data. The
Rayleigh scattering attenuation length is the average distance
traveled by a photon before it is Rayleigh scattered in the medium
and it is the distance returned by the <literal>GetMeanFreePath</literal>
method. The <literal>G4OpRayleigh</literal> class provides a
<literal>RayleighAttenuationLengthGenerator</literal> method which calculates
the attenuation coefficient of a medium following the
Einstein-Smoluchowski formula whose derivation requires the use of
statistical mechanics, includes temperature, and depends on the
isothermal compressibility of the medium. This generator is
convenient when the Rayleigh attenuation length is not known from
measurement but may be calculated from first principles using the
above material constants. For a medium named <emphasis>Water</emphasis> and no
Rayleigh scattering attenutation length specified by the user, the
program automatically calls the
<literal>RayleighAttenuationLengthGenerator</literal>
which calculates it for 10 degrees Celsius liquid water.
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
Boundary Process
</bridgehead>

<para>
Reference: E. Hecht and A. Zajac, Optics
<citation>
<xref linkend="biblio.hecht1974" endterm="biblio.hecht1974.abbrev" />
</citation>
</para>

<para>
For the simple case of a perfectly smooth interface between two
dielectric materials, all the user needs to provide are the
refractive indices of the two materials stored in their respective
<literal>G4MaterialPropertiesTable</literal>. In all other cases, the optical
boundary process design relies on the concept of <emphasis>surfaces</emphasis>.
The information is split into two classes. One class in the
material category keeps information about the physical properties
of the surface itself, and a second class in the geometry category
holds pointers to the relevant physical and logical volumes
involved and has an association to the physical class. Surface
objects of the second type are stored in a related table and can be
retrieved by either specifying the two ordered pairs of physical
volumes touching at the surface, or by the logical volume entirely
surrounded by this surface. The former is called a <emphasis>border
surface</emphasis> while the latter is referred to as the <emphasis>skin
surface</emphasis>. This second type of surface is useful in situations
where a volume is coded with a reflector and is placed into many
different mother volumes. A limitation is that the skin surface can
only have one and the same optical property for all of the enclosed
volume's sides. The border surface is an ordered pair of physical
volumes, so in principle, the user can choose different optical
properties for photons arriving from the reverse side of the same
interface. For the optical boundary process to use a border
surface, the two volumes must have been positioned with
<literal>G4PVPlacement</literal>. The ordered combination can exist at many
places in the simulation. When the surface concept is not needed,
and a perfectly smooth surface exists beteen two dielectic
materials, the only relevant property is the index of refraction, a
quantity stored with the material, and no restriction exists on how
the volumes were positioned.
</para>

<para>
The physical surface object also specifies which model the
boundary process should use to simulate interactions with that
surface. In addition, the physical surface can have a material
property table all its own. The usage of this table allows all
specular constants to be wavelength dependent. In case the surface
is painted or wrapped (but not a cladding), the table may include
the thin layer's index of refraction. This allows the simulation of
boundary effects at the intersection between the medium and the
surface layer, as well as the Lambertian reflection at the far side
of the thin layer. This occurs within the process itself and does
not invoke the <literal>G4Navigator</literal>. Combinations of surface finish
properties, such as <emphasis>polished</emphasis> or 
<emphasis>ground</emphasis> and <emphasis>front
painted</emphasis> or <emphasis>back painted</emphasis>, enumerate the different
situations which can be simulated.
</para>

<para>
When a photon arrives at a medium boundary its behavior depends
on the nature of the two materials that join at that boundary.
Medium boundaries may be formed between two dielectric materials or
a dielectric and a metal. In the case of two dielectric materials,
the photon can undergo total internal reflection, refraction or
reflection, depending on the photon's wavelength, angle of
incidence, and the refractive indices on both sides of the
boundary. Furthermore, reflection and transmission probabilites are
sensitive to the state of linear polarization. In the case of an
interface between a dielectric and a metal, the photon can be
absorbed by the metal or reflected back into the dielectric. If the
photon is absorbed it can be detected according to the
photoelectron efficiency of the metal.
</para>

<para>
As expressed in Maxwell's equations, Fresnel reflection and
refraction are intertwined through their relative probabilities of
occurrence. Therefore neither of these processes, nor total
internal reflection, are viewed as individual processes deserving
separate class implementation. Nonetheless, an attempt was made to
adhere to the abstraction of having independent processes by
splitting the code into different methods where practicable.
</para>

<para>
One implementation of the <literal>G4OpBoundaryProcess</literal> class
employs the 
<ulink url="http://geant4.slac.stanford.edu/UsersWorkshop/G4Lectures/Peter/moisan.ps">
UNIFIED model</ulink>
 [A. Levin and C. Moisan, A More Physical Approach
to Model the Surface Treatment of Scintillation Counters and its
Implementation into DETECT, TRIUMF Preprint TRI-PP-96-64, Oct.
1996] of the DETECT program [G.F. Knoll, T.F. Knoll and T.M.
Henderson, Light Collection Scintillation Detector Composites for
Neutron Detection, IEEE Trans. Nucl. Sci., 35 (1988) 872.]. It
applies to dielectric-dielectric interfaces and tries to provide a
realistic simulation, which deals with all aspects of surface
finish and reflector coating. The surface may be assumed as smooth
and covered with a metallized coating representing a specular
reflector with given reflection coefficient, or painted with a
diffuse reflecting material where Lambertian reflection occurs. The
surfaces may or may not be in optical contact with another
component and most importantly, one may consider a surface to be
made up of micro-facets with normal vectors that follow given
distributions around the nominal normal for the volume at the
impact point. For very rough surfaces, it is possible for the
photon to inversely aim at the same surface again after reflection
of refraction and so multiple interactions with the boundary are
possible within the process itself and without the need for
relocation by <literal>G4Navigator</literal>.
</para>

<para>
The UNIFIED model provides for a range of different reflection
mechanisms. The specular lobe constant represents the reflection
probability about the normal of a micro facet. The specular spike
constant, in turn, illustrates the probability of reflection about
the average surface normal. The diffuse lobe constant is for the
probability of internal Lambertian reflection, and finally the
back-scatter spike constant is for the case of several reflections
within a deep groove with the ultimate result of exact
back-scattering. The four probabilities must add up to one, with
the diffuse lobe constant being implicit. The reader may consult
the reference for a thorough description of the model.

<example id="programlist_PhysProc_10">
<title>
Dielectric-dielectric surface properties 
defined via the <emphasis>G4OpticalSurface</emphasis>.
</title>

<programlisting>
G4VPhysicalVolume* volume1;
G4VPhysicalVolume* volume2;

G4OpticalSurface* OpSurface = new G4OpticalSurface("name");

G4LogicalBorderSurface* Surface = new
  G4LogicalBorderSurface("name",volume1,volume2,OpSurface);

G4double sigma_alpha = 0.1;

OpSurface -&gt; SetType(dielectric_dielectric);
OpSurface -&gt; SetModel(unified);
OpSurface -&gt; SetFinish(groundbackpainted);
OpSurface -&gt; SetSigmaAlpha(sigma_alpha);

const G4int NUM = 2;

G4double pp[NUM] = {2.038*eV, 4.144*eV};
G4double specularlobe[NUM] = {0.3, 0.3};
G4double specularspike[NUM] = {0.2, 0.2};
G4double backscatter[NUM] = {0.1, 0.1};
G4double rindex[NUM] = {1.35, 1.40};
G4double reflectivity[NUM] = {0.3, 0.5};
G4double efficiency[NUM] = {0.8, 0.1};

G4MaterialPropertiesTable* SMPT = new G4MaterialPropertiesTable();

SMPT -&gt; AddProperty("RINDEX",pp,rindex,NUM);
SMPT -&gt; AddProperty("SPECULARLOBECONSTANT",pp,specularlobe,NUM);
SMPT -&gt; AddProperty("SPECULARSPIKECONSTANT",pp,specularspike,NUM);
SMPT -&gt; AddProperty("BACKSCATTERCONSTANT",pp,backscatter,NUM);
SMPT -&gt; AddProperty("REFLECTIVITY",pp,reflectivity,NUM);
SMPT -&gt; AddProperty("EFFICIENCY",pp,efficiency,NUM);

OpSurface -&gt; SetMaterialPropertiesTable(SMPT);
</programlisting>
</example>
</para>

<para>
The original 
<ulink url="http://wwwasdoc.web.cern.ch/wwwasdoc/geant_html3/node231.html">
GEANT3.21 implementation</ulink>  of this process is also available via
the GLISUR methods flag. [GEANT Detector Description and Simulation
Tool, Application Software Group, Computing and Networks Division,
CERN, PHYS260-6 tp 260-7.].

<example id="programlist_PhysProc_11">
<title>
Dielectric metal surface properties defined via the
<emphasis>G4OpticalSurface</emphasis>.
</title>

<programlisting>
G4LogicalVolume* volume_log;

G4OpticalSurface* OpSurface = new G4OpticalSurface("name");

G4LogicalSkinSurface* Surface = new
  G4LogicalSkinSurface("name",volume_log,OpSurface);

OpSurface -&gt; SetType(dielectric_metal);
OpSurface -&gt; SetFinish(ground);
OpSurface -&gt; SetModel(glisur);

G4double polish = 0.8;

G4MaterialPropertiesTable *OpSurfaceProperty = new G4MaterialPropertiesTable();

OpSurfaceProperty -&gt; AddProperty("REFLECTIVITY",pp,reflectivity,NUM);
OpSurfaceProperty -&gt; AddProperty("EFFICIENCY",pp,efficiency,NUM);

OpSurface -&gt; SetMaterialPropertiesTable(OpSurfaceProperty);
</programlisting>
</example>
</para>

<para>
The reflectivity off a metal surface can also be calculated by way of a complex 
index of refraction. Instead of storing the REFLECTIVITY directly, the user 
stores the real part (REALRINDEX) and the imaginary part (IMAGINARYRINDEX) as 
a function of photon energy separately in the G4MaterialPropertyTable. Geant4 
then 
<ulink url="./AllResources/TrackingAndPhysics/physicsProcessOptical.src/GetReflectivity.pdf">
calculates the reflectivity 
</ulink>
depending on the incident angle, photon energy, degree of TE and TM
polarization, and this complex refractive index.
</para>

<para>
The program defaults to the GLISUR model and <emphasis>polished</emphasis>
surface finish when no specific model and surface finish is
specified by the user. In the case of a dielectric-metal interface,
or when the GLISUR model is specified, the only surface finish
options available are <emphasis>polished</emphasis> or <emphasis>ground</emphasis>. For
dielectric-metal surfaces, the <literal>G4OpBoundaryProcess</literal> also
defaults to unit reflectivity and zero detection efficiency. In
cases where the user specifies the UNIFIED model, but does not
otherwise specify the model reflection probability constants, the
default becomes Lambertian reflection.
</para>

<para>
Martin Janecek and Bill Moses (Lawrence Berkeley National Laboratory) 
built an instrument for measuring the angular reflectivity distribution 
inside of BGO crystals with common surface treatments and reflectors 
applied. These results have been incorporate into the Geant4 code. A 
third class of reflection type besides dielectric_metal and 
dielectric_dielectric is added: dielectric_LUT. The distributions have 
been converted to 21 look-up-tables (LUT); so far for 1 scintillator 
material (BGO) x 3 surface treatments x 7 reflector materials.  The 
modified code allows the user to specify the surface treatment 
(rough-cut, chemically etched, or mechanically polished), the attached 
reflector (Lumirror, Teflon, ESR film, Tyvek, or TiO2 paint), and the 
bonding type (air-coupled or glued). The glue used is MeltMount, and the 
ESR film used is VM2000. Each LUT consists of measured angular 
distributions with 4º by 5º resolution in theta and phi, respectively, 
for incidence angles from 0º to 90º degrees, in 1º-steps. The code might 
in the future be updated by adding more LUTs, for instance, for other 
scintillating materials (such as LSO or NaI). To use these LUT the user 
has to download them from 
<ulink url="http://geant4.web.cern.ch/geant4/support/download.shtml">
Geant4 Software Download</ulink> and set an environment variable, 
<literal>G4REALSURFACEDATA</literal>, to the directory of 
<literal>geant4/data/RealSurface1.0</literal>. For details see: 

<ulink url="./AllResources/TrackingAndPhysics/physicsProcessOptical.src/Janecek-TNS-00249-2009R1.pdf">
M. Janecek, W. Moses IEEE Transactions on Nuclear Science 
</ulink>.
</para>

<para>
The enumeration G4OpticalSurfaceFinish has been extended to include 
(what follows should be a 2 column table): 

<informalexample>
<programlisting>
  polishedlumirrorair,         // mechanically polished surface, with lumirror 
  polishedlumirrorglue,        // mechanically polished surface, with lumirror &amp; meltmount 
  polishedair,                 // mechanically polished surface 
  polishedteflonair,           // mechanically polished surface, with teflon 
  polishedtioair,              // mechanically polished surface, with tio paint 
  polishedtyvekair,            // mechanically polished surface, with tyvek 
  polishedvm2000air,           // mechanically polished surface, with esr film 
  polishedvm2000glue,          // mechanically polished surface, with esr film &amp; meltmount 
  etchedlumirrorair,           // chemically etched surface, with lumirror 
  etchedlumirrorglue,          // chemically etched surface, with lumirror &amp; meltmount 
  etchedair,                   // chemically etched surface 
  etchedteflonair,             // chemically etched surface, with teflon 
  etchedtioair,                // chemically etched surface, with tio paint 
  etchedtyvekair,              // chemically etched surface, with tyvek 
  etchedvm2000air,             // chemically etched surface, with esr film 
  etchedvm2000glue,            // chemically etched surface, with esr film &amp; meltmount 
  groundlumirrorair,           // rough-cut surface, with lumirror 
  groundlumirrorglue,          // rough-cut surface, with lumirror &amp; meltmount 
  groundair,                   // rough-cut surface 
  groundteflonair,             // rough-cut surface, with teflon 
  groundtioair,                // rough-cut surface, with tio paint 
  groundtyvekair,              // rough-cut surface, with tyvek 
  groundvm2000air,             // rough-cut surface, with esr film 
  groundvm2000glue             // rough-cut surface, with esr film &amp; meltmount 
</programlisting>
</informalexample>
</para>

<para>
To use a look-up-table, all the user needs to specify for an 
<literal>G4OpticalSurface</literal> is: 
<literal>SetType(dielectric_LUT), SetModel(LUT)</literal> and for example, 
<literal>SetFinish(polishedtyvekair)</literal>.
</para>

</sect3>
</sect2>


<!-- ******************* Section (Level#2) ****************** -->
<sect2 id="sect.PhysProc.Param">
<title>
Parameterization
</title>

<para>
In this section we describe how to use the parameterization or
"fast simulation" facilities of GEANT4. Examples are provided in
the <emphasis role="bold">examples/novice/N05 directory</emphasis>.
</para>


<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Param.Gene">
<title>
Generalities:
</title>

<para>
The Geant4 parameterization facilities allow you to shortcut the
detailed tracking in a given volume and for given particle types in
order for you to provide your own implementation of the physics and
of the detector response.
</para>

<para>
Parameterisations are bound to a 
<emphasis role="bold"><literal>G4Region</literal></emphasis>
object, which, in the case of fast simulation is also called an
<emphasis role="bold">envelope</emphasis>. Prior to release 8.0, 
parameterisations were bound
to a <literal>G4LogicalVolume</literal>, the root of a volume hierarchy.
These root volumes are now attributes of the <literal>G4Region</literal>.
Envelopes often correspond to the volumes of sub-detectors:
electromagnetic calorimeters, tracking chambers, etc. With GEANT4
it is also possible to define envelopes by overlaying a parallel or
"ghost" geometry as discussed in <xref linkend="sect.PhysProc.Param.Ghost" />.
</para>

<para>
In GEANT4, parameterisations have three main features. You must
specify:

<itemizedlist spacing="compact">
  <listitem><para>
    the particle types for which your parameterisation is valid;
  </para></listitem>
  <listitem><para>
    the dynamics conditions for which your parameterisation is
    valid and must be triggered;
  </para></listitem>
  <listitem><para>
    the parameterisation itself: where the primary will be killed
    or moved, whether or not to create it or create secondaries, etc.,
    and where the detector response will be computed.
  </para></listitem>
</itemizedlist>
</para>

<para>
GEANT4 will message your parameterisation code for each step
starting in any root G4LogicalVolume (including daughters.
sub-daughters, etc. of this volume) of the <literal>G4Region</literal>.
It will proceed by first asking the available parameterisations for
the current particle type if one of them (and only one) wants to
issue a trigger. If so it will invoke its parameterisation. In this
case, the tracking 
<emphasis role="bold"><emphasis>will not apply physics</emphasis></emphasis> 
to the particle in the step. Instead, the UserSteppingAction will be
invoked.
</para>

<para>
Parameterisations look like a "user stepping action" but are more
advanced because:

<itemizedlist spacing="compact">
  <listitem><para>
    parameterisation code is messaged only in the
    <literal>G4Region</literal> to which it is bound;
  </para></listitem>
  <listitem><para>
    parameterisation code is messaged anywhere in the
    <literal>G4Region</literal>, that is, any volume in which the track is
    located;
  </para></listitem>
  <listitem><para>
    GEANT4 will provide information to your parameterisation code
    about the current root volume of the <literal>G4Region</literal> 
    in which the track is travelling.
  </para></listitem>
</itemizedlist>
</para>

</sect3>


<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Param.OvComp">
<title>
Overview of Parameterisation Components
</title>

<para>
The GEANT4 components which allow the implementation and control
of parameterisations are:

<variablelist>
  <varlistentry>
    <term>
      <literal><emphasis role="bold">G4VFastSimulationModel</emphasis></literal> 
    </term>
    <listitem><para>
      This is the abstract class for the implementation of parameterisations. 
      You must inherit from it to implement your concrete parameterisation model.
    </para></listitem>
  </varlistentry>
  <varlistentry>
    <term>
      <literal><emphasis role="bold">G4FastSimulationManager</emphasis></literal>
    </term>
    <listitem><para>
      The G4VFastSimulationModel objects are attached to the
      <literal>G4Region</literal> through a G4FastSimulationManager. 
      This object will manage the list of models and will message them at 
      tracking time.
    </para></listitem>
  </varlistentry>
  <varlistentry>
    <term>
      <literal><emphasis role="bold">G4Region/Envelope</emphasis></literal>
    </term>
    <listitem><para>
      As mentioned before, an envelope in GEANT4 is a 
      <literal><emphasis role="bold">G4Region</emphasis></literal>. 
      The parameterisation is bound to the <literal>G4Region</literal> by 
      setting a <literal>G4FastSimulationManager</literal> pointer to it.
      </para>
      <para>
      The figure below shows how the <literal>G4VFastSimulationModel</literal>
      and <literal>G4FastSimulationManager</literal> objects are bound to the
      <literal>G4Region</literal>. Then for all root G4LogicalVolume's held by
      the G4Region, the fast simulation code is active.

      <mediaobject>
        <imageobject role="fo">
          <imagedata fileref="./AllResources/TrackingAndPhysics/physicsProcessPARAM.src/ComponentsWithRegion.jpg" 
                     format="JPG" contentwidth="7.0cm" align="center" />
        </imageobject>
        <imageobject role="html">
          <imagedata fileref="./AllResources/TrackingAndPhysics/physicsProcessPARAM.src/ComponentsWithRegion.jpg" 
                     format="JPG" align="center" />
        </imageobject>
        <caption>
        </caption>
      </mediaobject>

    </para></listitem>
  </varlistentry>
  <varlistentry>
    <term>
      <literal><emphasis role="bold">G4FastSimulationManagerProcess</emphasis></literal>
    </term>
    <listitem><para>
      This is a <literal>G4VProcess</literal>. It provides the interface 
      between the tracking and the parameterisation. It must be set in the 
      process list of the particles you want to parameterise.
    </para></listitem>
  </varlistentry>
  <varlistentry>
    <term>
      <literal><emphasis role="bold">G4GlobalFastSimulationManager</emphasis></literal>
    </term>
    <listitem><para>
      This a singleton class which provides the management of the
      <literal>G4FastSimulationManager</literal> objects and some ghost
      facilities.
    </para></listitem>
  </varlistentry>
</variablelist>    
</para>

</sect3>


<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Param.FastSimModel">
<title>
The <literal>G4VFastSimulationModel</literal> Abstract Class
</title>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
Constructors:
</bridgehead>

<para>
The <literal>G4VFastSimulationModel</literal> class has two constructors.
The second one allows you to get started quickly:

<variablelist>
  <varlistentry>
    <term>
      <emphasis role="bold"><literal>G4VFastSimulationModel(
       const G4String&amp; aName)</literal></emphasis>:
    </term>
    <listitem><para>
      Here <literal>aName</literal> identifies the parameterisation model.
    </para></listitem>
  </varlistentry>
  <varlistentry>
    <term>
      <emphasis role="bold"><literal>G4VFastSimulationModel(const G4String&amp; 
       aName, G4Region*, G4bool IsUnique=false):</literal></emphasis>
    </term>
    <listitem><para>
      In addition to the model name, this constructor accepts a G4Region pointer. 
      The needed G4FastSimulationManager object is constructed if necessary,
      passing to it the G4Region pointer and the boolean value. If it
      already exists, the model is simply added to this manager. Note
      that the <emphasis>G4VFastSimulationModel object will not keep track of
      the G4Region passed in the constructor</emphasis>.
      The boolean argument is there for optimization purposes: if you
      know that the G4Region has a unique root G4LogicalVolume, uniquely
      placed, you can set the boolean value to "true".
    </para></listitem>
  </varlistentry>
</variablelist>
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
Virtual methods:
</bridgehead>

<para>
The G4VFastSimulationModel has three pure virtual methods which
must be overriden in your concrete class:

<variablelist>
  <varlistentry>
    <term>
      <emphasis role="bold"><literal>G4VFastSimulationModel(
      <emphasis>const G4String&amp; aName</emphasis>):</literal></emphasis>
    </term>
    <listitem><para>
      Here aName identifies the parameterisation model.
    </para></listitem>
  </varlistentry>
  <varlistentry>
    <term>
      <emphasis role="bold"><literal>G4bool ModelTrigger(
      <emphasis>const G4FastTrack&amp;</emphasis>):</literal></emphasis>
    </term>
    <listitem><para>
      You must return "true" when the dynamic conditions to trigger your 
      parameterisation are fulfilled.
      G4FastTrack provides access to the current G4Track, gives simple
      access to the current root G4LogicalVolume related features (its
      G4VSolid, and G4AffineTransform references between the global and
      the root G4LogicalVolume local coordinates systems) and simple
      access to the position and momentum expressed in the root
      G4LogicalVolume coordinate system. Using these quantities and the
      G4VSolid methods, you can for example easily check how far you are
      from the root G4LogicalVolume boundary.
    </para></listitem>
  </varlistentry>
  <varlistentry>
    <term>
      <emphasis role="bold"><literal>G4bool IsApplicable(
      <emphasis>const G4ParticleDefinition&amp;</emphasis>):</literal></emphasis>
    </term>
    <listitem><para>
      In your implementation, you must return "true" when your model is 
      applicable to the G4ParticleDefinition passed to this method. The
      G4ParticleDefinition provides all intrinsic particle information
      (mass, charge, spin, name ...).
      </para>
      <para>
      If you want to implement a model which is valid only for certain
      particle types, it is recommended for efficiency that you use the
      static pointer of the corresponding particle classes.
      </para>
      <para>
      As an example, in a model valid for <emphasis>gamma</emphasis>s only, 
      the IsApplicable() method should take the form:

      <informalexample>
      <programlisting>
      #include "G4Gamma.hh"

      G4bool MyGammaModel::IsApplicable(const G4ParticleDefinition&amp; partDef)
      {
        return &amp;partDef == G4Gamma::GammaDefinition();
      }
      </programlisting>
      </informalexample>
    </para></listitem>
  </varlistentry>
  <varlistentry>
    <term>
      <emphasis role="bold"><literal>G4bool ModelTrigger(
      <emphasis>const G4FastTrack&amp;</emphasis>):</literal></emphasis> 
    </term>
    <listitem><para>
      You must return "true" when the dynamic conditions to trigger your 
      parameterisation are fulfilled.
      The G4FastTrack provides access to the current G4Track, gives
      simple access to envelope related features (G4LogicalVolume,
      G4VSolid, and G4AffineTransform references between the global and
      the envelope local coordinates systems) and simple access to the
      position and momentum expressed in the envelope coordinate system.
      Using these quantities and the G4VSolid methods, you can for
      example easily check how far you are from the envelope boundary.
    </para></listitem>
  </varlistentry>
  <varlistentry>
    <term>
      <emphasis role="bold"><literal>void DoIt(
      <emphasis>const G4FastTrack&amp;, G4FastStep&amp;</emphasis>):</literal></emphasis>
    </term>
    <listitem><para>
      The details of your parameterisation will be implemented in this method. 
      The G4FastTrack reference provides the input information, and the final
      state of the particles after parameterisation must be returned
      through the G4FastStep reference. Tracking for the final state
      particles is requested after your parameterisation has been invoked.
    </para></listitem>
  </varlistentry>
</variablelist>
</para>

</sect3>


<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Param.FastSimMan">
<title>
The <literal>G4FastSimulationManager</literal> Class:
</title>

<para>
G4FastSimulationManager functionnalities regarding the use of ghost
volumes are explained in <xref linkend="sect.PhysProc.Param.Ghost" />.
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
Constructor:
</bridgehead>

<para>
<variablelist>
  <varlistentry>
    <term>
      <literal><emphasis role="bold">G4FastSimulationManager(
      <emphasis>G4Region *anEnvelope, G4bool IsUnique=false</emphasis>):
      </emphasis></literal> 
    </term>
    <listitem><para>
      This is the only constructor. You specify the G4Region by providing 
      its pointer. The G4FastSimulationManager object will bind itself 
      to this G4Region. If you know that this G4Region has a single root 
      G4LogicalVolume, placed only once, you can set the IsUnique boolean 
      to "true" to allow some optimization.
      </para>
      <para>
      Note that if you choose to use the G4VFastSimulationModel(const
      G4String&amp;, G4Region*, G4bool) constructor for your model, the
      G4FastSimulationManager will be constructed using the given
      G4Region* and G4bool values of the model constructor.
    </para></listitem>
  </varlistentry>
</variablelist>
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
G4VFastSimulationModel object management:
</bridgehead>

<para>
The following two methods provide the usual management
functions.

<itemizedlist spacing="compact">
  <listitem><para>
    <literal><emphasis role="bold">void AddFastSimulationModel(
    G4VFastSimulationModel*)</emphasis></literal>
  </para></listitem>
  <listitem><para>
    <literal><emphasis role="bold">RemoveFastSimulationModel(
    G4VFastSimulationModel*)</emphasis></literal>
  </para></listitem>
</itemizedlist>
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
Interface with the G4FastSimulationManagerProcess:
</bridgehead>

<para>
This is described in the User's Guide for Toolkit Developers
(
<!-- !!! xref linkend=""/ or ulink url="" -->
section 3.9.6
<!-- !! /ulink (remove this tag for xref) -->
)
</para>

</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Param.FastSimManProc">
<title>
The <literal>G4FastSimulationManagerProcess</literal> Class
</title>

<para>
This G4VProcess serves as an interface between the tracking and the
parameterisation. At tracking time, it collaborates with the
G4FastSimulationManager of the current volume, if any, to allow the
models to trigger. If no manager exists or if no model issues a
trigger, the tracking goes on normally.
</para>

<para>
<emphasis>In the present implementation, you must set this process in
the G4ProcessManager of the particles you parameterise to enable
your parameterisation.</emphasis>
</para>

<para>
The processes ordering is:

<informalexample>
<programlisting>
    [n-3] ...
    [n-2] Multiple Scattering
    [n-1] G4FastSimulationManagerProcess
    [ n ] G4Transportation
</programlisting>
</informalexample>
</para>

<para>
This ordering is important if you use ghost geometries, since the
G4FastSimulationManagerProcess will provide navigation in the ghost
world to limit the step on ghost boundaries.
</para>

<para>
The G4FastSimulationManager must be added to the process list of a
particle as a continuous and discrete process if you use ghost
geometries for this particle. You can add it as a discrete process
if you don't use ghosts.
</para>

<para>
The following code registers the G4FastSimulationManagerProcess
with all the particles as a discrete and continuous process:

<informalexample>
<programlisting>
void MyPhysicsList::addParameterisation()
{
  G4FastSimulationManagerProcess*
    theFastSimulationManagerProcess = new G4FastSimulationManagerProcess();
  theParticleIterator-&gt;reset();
  while( (*theParticleIterator)() )
    {
      G4ParticleDefinition* particle = theParticleIterator-&gt;value();
      G4ProcessManager* pmanager = particle-&gt;GetProcessManager();
      pmanager-&gt;AddProcess(theFastSimulationManagerProcess, -1, 0, 0);
    }
}
</programlisting>
</informalexample>
</para>

</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Param.FastSimManSing">
<title>
The <literal>G4GlobalFastSimulationManager</literal> Singleton Class
</title>

<para>
This class is a singleton which can be accessed as follows:

<informalexample>
<programlisting>
#include "G4GlobalFastSimulationManager.hh"
...
...
G4GlobalFastSimulationManager* globalFSM;
globalFSM = G4GlobalFastSimulationManager::getGlobalFastSimulationManager();
...
...
</programlisting>
</informalexample>
</para>

<para>
Presently, you will mainly need to use the
GlobalFastSimulationManager if you use ghost geometries.
</para>

</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Param.Ghost">
<title>
Parameterisation Using Ghost Geometries
</title>

<para>
In some cases, volumes of the tracking geometry do not allow
envelopes to be defined. This may be the case with a geometry
coming from a CAD system. Since such a geometry is flat, a parallel
geometry must be used to define the envelopes.
</para>

<para>
Another interesting case involves defining an envelope which groups
the electromagnetic and hadronic calorimeters of a detector into
one volume. This may be useful when parameterizing the interaction
of charged pions. You will very likely not want electrons to see
this envelope, which means that ghost geometries have to be
organized by particle flavours.
</para>

<para>
Using ghost geometries implies some more overhead in the
parameterisation mechanism for the particles sensitive to ghosts,
since navigation is provided in the ghost geometry by the
G4FastSimulationManagerProcess. Usually, however, only a few
volumes will be placed in this ghost world, so that the geometry
computations will remain rather cheap.
</para>

<para>
In the existing implementation (temporary implementation with
G4Region but before parallel geometry implementation), you may only
consider ghost G4Regions with just one root G4LogicalVolume. The
G4GlobalFastSimulationManager provides the construction of the
ghost geometry by making first an empty "clone" of the world for
tracking provided by the construct() method of your
G4VUserDetectorConstruction concrete class. You provide the
placement of the G4Region root G4LogicalVolume relative to the
ghost world coordinates in the G4FastSimulationManager objects. A
ghost G4Region is recognized by the fact that its associated
G4FastSimulationManager retains a non-empty list of placements.
</para>

<para>
The G4GlobalFastSimulationManager will then use both those
placements and the IsApplicable() methods of the models attached to
the G4FastSimulationManager objects to build the flavour-dependant
ghost geometries.
</para>

<para>
Then at the beginning of the tracking of a particle, the
appropriate ghost world, if any, will be selected.
</para>

<para>
The steps required to build one ghost G4Region are:

<orderedlist spacing="compact">
  <listitem><para>
    built the ghost G4Region : myGhostRegion;
  </para></listitem>
  <listitem><para>
    build the root G4LogicalVolume: myGhostLogical, set it to
    myGhostRegion;
  </para></listitem>
  <listitem><para>
    build a G4FastSimulationManager object, myGhostFSManager,
    giving myGhostRegion as argument of the constructor;
  </para></listitem>
  <listitem><para>
    <para>
    give to the G4FastSimulationManager the placement of the
    myGhostLogical, by invoking for the G4FastSimulationManager method:
    <informalexample>
    <programlisting>
     AddGhostPlacement(G4RotationMatrix*, const G4ThreeVector&amp;);
    </programlisting>
    </informalexample>
    or:
    <informalexample>
    <programlisting>
     AddGhostPlacement(G4Transform3D*);
    </programlisting>
    </informalexample>

    where the rotation matrix and translation vector of the 3-D
    transformation describe the placement relative to the ghost world
    coordinates.
    </para>
  </para></listitem>
  <listitem><para>
    build your G4VFastSimulationModel objects and add them to the
    myGhostFSManager.
    <emphasis>The IsApplicable() methods of your models will be used by the
    G4GlobalFastSimulationManager to build the ghost geometries
    corresponding to a given particle type.</emphasis>
  </para></listitem>
  <listitem><para>
    <para>
    Invoke the G4GlobalFastSimulationManager method:

    <informalexample>
    <programlisting>
     G4GlobalFastSimulationManager::getGlobalFastSimulationManager()-&gt;

          CloseFastSimulation();
    </programlisting>
    </informalexample>
    </para>
  </para></listitem>
</orderedlist>
</para>

<para>
This last call will cause the G4GlobalFastSimulationManager to
build the flavour-dependent ghost geometries. This call must be
done before the RunManager closes the geometry. (It is foreseen
that the run manager in the future will invoke the
CloseFastSimulation() to synchronize properly with the closing of
the geometry).
</para>

<para>
Visualization facilities are provided for ghosts geometries. After
the CloseFastSimulation() invocation, it is possible to ask for the
drawing of ghosts in an interactive session. The basic commands
are:

<itemizedlist spacing="compact">
  <listitem><para>
    <para>
    /vis/draw/Ghosts particle_name
    </para>
    <para>
    which makes the drawing of the ghost geometry associated with the
    particle specified by name in the command line.
    </para>
  </para></listitem>
  <listitem><para>
    /vis/draw/Ghosts
    <para>
    which draws all the ghost geometries.
    </para>
  </para></listitem>
</itemizedlist>
</para>

</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Param.GFlash">
<title>
Gflash Parameterization
</title>

<para>
This section describes how to use the Gflash library. Gflash is a
concrete parameterization which is based on the equations and
parameters of the original Gflash package from H1(hep-ex/0001020,
Grindhammer &amp; Peters, see physics manual) and uses the "fast
simulation" facilities of GEANT4 described above. Briefly, whenever
a e-/e+ particle enters the calorimeter, it is parameterized if it
has a minimum energy and the shower is expected to be contained in
the calorimeter (or " parameterization envelope"). If this is
fulfilled the particle is killed, as well as all secondaries, and
the energy is deposited according to the Gflash equations. An
example, provided in
<emphasis role="bold">examples/extended/parametrisation/gflash/</emphasis>, 
shows how to interface Gflash to your application. The simulation time is
measured, so the user can immediately see the speed increase
resulting from the use of Gflash.
</para>

</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.PhysProc.Param.UsingGFlash">
<title>
Using the Gflash Parameterisation
</title>

<para>
To use Gflash "out of the box" the following steps are necessary:

<itemizedlist spacing="compact">
  <listitem><para>
    The user must add the fast simulation process to his process
    manager:

    <informalexample>
    <programlisting>
  void MyPhysicsList::addParameterisation()
  {
    G4FastSimulationManagerProcess*
      theFastSimulationManagerProcess = new G4FastSimulationManagerProcess();
    theParticleIterator-&gt;reset();
    while( (*theParticleIterator)() )
      {
        G4ParticleDefinition* particle = theParticleIterator-&gt;value();
        G4ProcessManager* pmanager = particle-&gt;GetProcessManager();
        pmanager-&gt;AddProcess(theFastSimulationManagerProcess, -1, 0, 0);
      }
  }
    </programlisting>
    </informalexample>
  </para></listitem>
  <listitem><para>
    <para>
    The envelope in which the parameterization should be performed
    must be specified (below: G4Region m_calo_region) and the
    GFlashShowerModel must be assigned to this region. Furthermore, the
    classes GFlashParticleBounds (which provides thresholds for the
    parameterization like minimal energy etc.), GflashHitMaker(a helper
    class to generate hits in the sensitive detector) and
    GFlashHomoShowerParamterisation (which does the computations) must
    be constructed (by the user at the moment) and assigned to the
    GFlashShowerModel. Please note that at the moment only homogeneous
    calorimeters are supported.
    </para>
    <para>
    <informalexample>
    <programlisting>
  m_theFastShowerModel = new GFlashShowerModel("fastShowerModel",m_calo_region);
  m_theParametrisation = new GFlashHomoShowerParamterisation(matManager-&gt;getMaterial(mat));
  m_theParticleBounds  = new GFlashParticleBounds();
  m_theHMaker          = new GFlashHitMaker();
  m_theFastShowerModel-&gt;SetParametrisation(*m_theParametrisation);
  m_theFastShowerModel-&gt;SetParticleBounds(*m_theParticleBounds) ;
  m_theFastShowerModel-&gt;SetHitMaker(*m_theHMaker);
    </programlisting>
    </informalexample>
    </para>
    <para>
    The user must also set the material of the calorimeter, since the
    computation depends on the material.
    </para>
  </para></listitem>
  <listitem><para>
    <para>
    It is mandatory to use G4VGFlashSensitiveDetector as
    (additional) base class for the sensitive detector.
    </para>
    <para>
    <informalexample>
    <programlisting>
  class ExGflashSensitiveDetector: public G4VSensitiveDetector ,public G4VGFlashSensitiveDetector 
    </programlisting>
    </informalexample>
    </para>
    <para>
    Here it is necessary to implement a separate interface, where the
    GFlash spots are processed.
    </para>
    <para>
    <informalexample>
    <programlisting>
  (ProcessHits(G4GFlashSpot*aSpot ,G4TouchableHistory* ROhist))
    </programlisting>
    </informalexample>
    </para>
    <para>
    A separate interface is used, because the Gflash spots naturally
    contain less information than the full simulation.
    </para>
  </para></listitem>
</itemizedlist>
</para>

<para>
Since the parameters in the Gflash package are taken from fits to
full simulations with Geant3, some retuning might be necessary for
good agreement with Geant4 showers. For experiment-specific
geometries some retuning might be necessary anyway. The tuning is
quite complicated since there are many parameters (some correlated)
and cannot be described here (see again hep-ex/0001020). For brave
users the Gflash framework already forsees the possibility of
passing a class with the (users)
parameters,<emphasis role="bold">GVFlashHomoShowerTuning</emphasis>, 
to the GFlashHomoShowerParamterisation constructor. 
The default parameters are the original Gflash parameters:

<informalexample>
<programlisting>
GFlashHomoShowerParameterisation(G4Material * aMat, GVFlashHomoShowerTuning * aPar = 0);
</programlisting>
</informalexample>
</para>

<para>
Now there is also a preliminary implemenation of a parameterization
for sampling calorimeters.
</para>

<para>
The user must specify the active and passive material, as well as
the thickness of the active and passive layer.
</para>

<para>
The sampling structure of the calorimeter is taken into account by
using an "effective medium" to compute the shower shape.
</para>

<para>
All material properties needed are calculated automatically. If
tuning is required,  the user can pass his own parameter set in
the class 
<emphasis role="bold">GFlashSamplingShowerTuning</emphasis>. 
Here the user can also set his calorimeter resolution.
</para>

<para>
All in all the constructor looks the following:

<informalexample>
<programlisting>
GFlashSamplingShowerParamterisation(G4Material * Mat1, G4Material * Mat2,G4double d1,G4double d2,
GVFlashSamplingShowerTuning * aPar = 0);
</programlisting>
</informalexample>
</para>

<para>
An implementation of some tools that should help the user to tune
the parameterization is forseen.
</para>

</sect3>
</sect2>


<!-- ******************* Section (Level#2) ****************** -->
<sect2 id="sect.PhysProc.Trans">
<title>
Transportation Process
</title>

<para>
To be delivered by J. Apostolakis (<email>John.Apostolakis@cern.ch</email>).
</para>


</sect2>
</sect1>