source: trunk/documents/UserDoc/DocBookUsersGuides/ForApplicationDeveloper/xml/Fundamentals/biasing.xml@ 1324

<!-- ******************************************************** -->
<!--                                                          -->
<!--  [History]                                               -->
<!--    New section on Reverse MC: L. Desorgher, Dec-2009     -->
<!--    Converted to DocBook: Katsuya Amako, Aug-2006         -->
<!--    Changed by: Dennis Wright, 25-Jun-2002                -->
<!--                                                          -->
<!-- ******************************************************** -->


<!-- ******************* Section (Level#1) ****************** -->
<sect1 id="sect.EvtBias">
<title>
Event Biasing Techniques
</title>

<!-- ******************* Section (Level#2) ****************** -->
<sect2 id="sect.EvtBias.ScorImpRoul">
<title>
Scoring, Geometrical Importance Sampling and Weight Roulette
</title>

<para>
Geant4 provides event biasing techniques which may be used to save
computing time in such applications as the simulation of radiation
shielding. These are <emphasis>geometrical splitting
</emphasis> and <emphasis>Russian roulette</emphasis> 
(also called geometrical importance sampling), and
<emphasis>weight roulette</emphasis>. Scoring is carried out by <emphasis>G4MultiFunctionalDetector</emphasis> (see <xref
linkend="sect.Hits.G4Multi" /> and <xref linkend="sect.Hits.G4VPrim" />) using the standard Geant4 scoring technique.
Biasing specific scorers have been implemented and are described within
<emphasis>G4MultiFunctionDetector</emphasis> documentation. In this chapter, it is assumed that
the reader is familiar with both the usage of Geant4 and the
concepts of importance sampling. More detailed documentation may be
found in the documents
<ulink url="http://geant4.cern.ch/collaboration/working_groups/geometry/biasing/Sampling.html">
'Scoring, geometrical importance sampling and weight roulette'
</ulink>. 
A detailed description of different use-cases which employ the sampling 
and scoring techniques can be found in the document
<ulink url="http://geant4.cern.ch/collaboration/working_groups/geometry/biasing/BiasScoreUseCases.html">
'Use cases of importance sampling and scoring in Geant4'
</ulink>.
</para>

<para>
The purpose of importance sampling is to save computing time by
sampling less often the particle histories entering "less
important" geometry regions, and more often in more "important"
regions. Given the same amount of computing time, an
importance-sampled and an analogue-sampled simulation must show
equal mean values, while the importance-sampled simulation will
have a decreased variance.
</para>

<para>
The implementation of scoring is independent of the implementation
of importance sampling. However both share common concepts.
<emphasis>Scoring and importance sampling apply to particle types chosen
by the user</emphasis>, which should be borne in mind when interpreting the
output of any biased simulation.
</para>

<para>
Examples on how to use scoring and importance sampling may be found
in <literal>examples/extended/biasing</literal>.
</para>


<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.EvtBias.ScorImpRoul.Geom">
<title>
Geometries
</title>

<para>
The kind of scoring referred to in this note and the importance
sampling apply to spatial cells provided by the user.
</para>

<para>
A <emphasis role="bold">cell</emphasis> is a physical volume (further specified 
by it's replica number, if the volume is a replica). Cells may be defined
in two kinds of geometries:

<orderedlist spacing="compact">
  <listitem><para>
    <emphasis role="bold">mass geometry</emphasis>: the geometry setup of the 
    experiment to be simulated. Physics processes apply to this geometry.
  </para></listitem>
  <listitem><para>
    <emphasis role="bold">parallel-geometry</emphasis>: a geometry constructed 
    to define the physical volumes according to which scoring and/or importance
    sampling is applied.
  </para></listitem>
</orderedlist>
</para>

<para>
The user has the choice to score and/or sample by importance the
particles of the chosen type, according to mass geometry or to
parallel geometry. It is possible to utilize several parallel
geometries in addition to the mass geometry. This provides the user
with a lot of flexibility to define separate geometries for
different particle types in order to apply scoring or/and
importance sampling.
</para>

<para>
<note>
  Parallel geometries should be constructed using the implementation as
  described in <xref linkend="sect.ParaGeom"/>.

  There are a few conditions for parallel geometries:

  <itemizedlist spacing="compact">
  <listitem><para>
    The world volume for parallel and mass geometries must be identical copies.
  </para></listitem>
  <listitem><para>
    Scoring and importance cells must not share boundaries with the world volume.
  </para></listitem>
  </itemizedlist>
</note>
</para>

</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.EvtBias.ScorImpRoul.ChgSamp">
<title>
Changing the Sampling
</title>

<para>
Samplers are higher level tools which perform the necessary
changes of the Geant4 sampling in order to apply importance
sampling and weight roulette. 
</para>

<para>
Variance reduction (and scoring through the
<emphasis>G4MultiFunctionalDetector</emphasis>) 
may be combined arbitrarily for chosen particle types and may be applied to the
mass or to parallel geometries. 
</para>

<para>
The <literal>G4GeometrySampler</literal> can be applied equally to mass or
parallel geometries with an abstract interface supplied by <literal>G4VSampler</literal>.
<literal>G4VSampler</literal> provides
<literal>Prepare...</literal> methods and a <literal>Configure</literal>
method:

<anchor id="anchor_EvtBias_G4VSampler" />
<informalexample>
<programlisting>
 class G4VSampler
 {
   public:  
    G4VSampler();
    virtual ~G4VSampler();
    virtual void PrepareImportanceSampling(G4VIStore *istore,
                                           const G4VImportanceAlgorithm 
                                           *ialg = 0) = 0;
    virtual void PrepareWeightRoulett(G4double wsurvive = 0.5,
                                      G4double wlimit = 0.25,
                                      G4double isource = 1) = 0;
    virtual void PrepareWeightWindow(G4VWeightWindowStore *wwstore,
                                     G4VWeightWindowAlgorithm *wwAlg = 0,
                                     G4PlaceOfAction placeOfAction = 
                                     onBoundary) = 0;
    virtual void Configure() = 0;
    virtual void ClearSampling() = 0;
    virtual G4bool IsConfigured() const = 0;
 };
</programlisting>
</informalexample>
</para>

<para>
The methods for setting up the desired combination need specific
information:

<itemizedlist spacing="compact">
  <listitem><para>
    Importance sampling: message <literal>PrepareImportanceSampling</literal>
    with a 
    <link linkend="anchor_EvtBias_G4VIStore">
    <literal>G4VIStore</literal></link>
    and optionally a <literal>G4VImportanceAlgorithm</literal>
  </para></listitem>
  <listitem><para>
    Weight window: message <literal>PrepareWeightWindow</literal> with the
    arguments:
    <itemizedlist spacing="compact">
      <listitem><para>
        <emphasis>*wwstore</emphasis>: a 
        <literal>G4VWeightWindowStore</literal> for retrieving the lower 
        weight bounds for the energy-space cells
      </para></listitem>
      <listitem><para>
        <emphasis>*wwAlg</emphasis>: a
        <literal>G4VWeightWindowAlgorithm</literal> if a customized algorithm 
        should be used
      </para></listitem>
      <listitem><para>
        <emphasis>placeOfAction</emphasis>: a
        <literal>G4PlaceOfAction</literal> specifying where to perform the
        biasing
      </para></listitem>
    </itemizedlist>
  </para></listitem>
  <listitem><para>
    Weight roulette: message <literal>PrepareWeightRoulett</literal> with the
    optional parameters:
    <itemizedlist spacing="compact">
      <listitem><para>
        <emphasis>wsurvive</emphasis>: survival weight
      </para></listitem>
      <listitem><para>
        <emphasis>wlimit</emphasis>: minimal allowed
        value of weight * source importance / cell importance
      </para></listitem>
      <listitem><para>
        <emphasis>isource</emphasis>: importance of the source cell
      </para></listitem>
    </itemizedlist>
  </para></listitem>
</itemizedlist>
</para>

<para>
Each object of a sampler class is responsible for one particle
type. The particle type is given to the constructor of the sampler
classes via the particle type name, e.g. "neutron". Depending on
the specific purpose, the <literal>Configure()</literal> of a sampler will
set up specialized processes (derived from <literal>G4VProcess</literal>) for
transportation in the parallel geometry, importance
sampling and weight roulette for the given particle type. When
<literal>Configure()</literal> is invoked the sampler places the processes in
the correct order independent of the order in which user invoked
the <literal>Prepare...</literal> methods.
</para>

<para>
<note>
  <para>
  <itemizedlist spacing="compact">
  <listitem><para>
    The <literal>Prepare...()</literal> functions may each only be invoked
    once.
  </para></listitem>
  <listitem><para>
    To configure the sampling the function <literal>Configure()</literal>
    must be called <emphasis>after</emphasis> the
    <literal>G4RunManager</literal> has been initialized and the PhysicsList has
    been instantiated.
  </para></listitem>
  </itemizedlist>
  </para>
</note>
</para>




<para>
The interface and framework are demonstrated in the
<literal>examples/extended/biasing</literal> directory, with the main changes being to the
G4GeometrySampler class and the fact that in the parallel case the WorldVolume
is a copy of the Mass World.

The parallel geometry now has to inherit from
<emphasis>G4VUserParallelWorld</emphasis> which also has the <emphasis>GetWorld()</emphasis> method
in order to retrieve a copy of the mass geometry WorldVolume.

<informalexample>
<programlisting>
  class B02ImportanceDetectorConstruction : public G4VUserParallelWorld
  ghostWorld = GetWorld();
</programlisting>
</informalexample>

</para>

<para>
The constructor for <emphasis>G4GeometrySampler</emphasis> takes a pointer to
the physical world volume and the particle type name (e.g. "neutron") as arguments. 
In a single mass geometry the sampler is created as follows:

<informalexample>
<programlisting>
  G4GeometrySampler mgs(detector->GetWorldVolume(),"neutron");
  mgs.SetParallel(false);
</programlisting>
</informalexample>


Whilst the following lines of code are required in order to set up the sampler for the
parallel geometry case:

<informalexample>
<programlisting>
  G4VPhysicalVolume* ghostWorld = pdet->GetWorldVolume();

  G4GeometrySampler pgs(ghostWorld,"neutron");

  pgs.SetParallel(true);
</programlisting>
</informalexample>


Also note that the preparation and configuration of the samplers has to be
carried out <emphasis>after</emphasis> the instantiation of the UserPhysicsList
and after the initialisation of the <emphasis>G4RunManager</emphasis>:

<informalexample>
<programlisting>
  pgs.PrepareImportanceSampling(&amp;aIstore, 0);
  pgs.Configure();
</programlisting>
</informalexample>

Due to the fact that biasing is a process and has to be inserted after all the
other processes have been created.
</para>


</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.EvtBias.ScorImpRoul.ImpSamp">
<title>
Importance Sampling
</title>

<para>
Importance sampling acts on particles crossing boundaries
between "importance cells". The action taken depends on the
importance values assigned to the cells. In general a particle
history is either split or Russian roulette is played if the
importance increases or decreases, respectively. A weight assigned
to the history is changed according to the action taken.
</para>

<para>
The tools provided for importance sampling require the user to
have a good understanding of the physics in the problem. This is
because the user has to decide which particle types require
importance sampled, define the cells, and assign importance values
to the cells. If this is not done properly the results cannot be
expected to describe a real experiment.
</para>

<para>
The assignment of importance values to a cell is done using an
importance store described below.
</para>

<para>
An "importance store" with the interface <literal>G4VIStore</literal> is
used to store importance values related to cells. In order to do
importance sampling the user has to create an object (e.g. of class
<literal>G4IStore</literal>) of type <literal>G4VIStore</literal>. The samplers may be
given a <literal>G4VIStore</literal>. The user fills the store with cells and
their importance values.
</para>

<para>
An importance store has to be constructed with a reference to
the world volume of the geometry used for importance sampling. This
may be the world volume of the mass or of a parallel geometry.
Importance stores derive from the interface <literal>G4VIStore</literal>:

<anchor id="anchor_EvtBias_G4VIStore" />
<informalexample>
<programlisting>
 class  G4VIStore
 {
   public: 
     G4VIStore();
     virtual  ~G4VIStore();
     virtual G4double GetImportance(const G4GeometryCell &amp;gCell) const = 0;
     virtual G4bool IsKnown(const G4GeometryCell &amp;gCell) const = 0;
     virtual const G4VPhysicalVolume &amp;GetWorldVolume() const = 0;
 };
</programlisting>
</informalexample>
</para>

<para>
A concrete implementation of an importance store is provided by
the class <literal>G4VStore</literal>. The <emphasis>public</emphasis>
part of the class is:

<informalexample>
<programlisting>
 class G4IStore : public G4VIStore
 {
   public:
     explicit G4IStore(const G4VPhysicalVolume &amp;worldvolume);
     virtual ~G4IStore();
     virtual G4double GetImportance(const G4GeometryCell &amp;gCell) const;
     virtual G4bool IsKnown(const G4GeometryCell &amp;gCell) const;
     virtual const G4VPhysicalVolume &amp;GetWorldVolume() const;
     void AddImportanceGeometryCell(G4double importance,
                              const G4GeometryCell &amp;gCell);
     void AddImportanceGeometryCell(G4double importance,
                              const G4VPhysicalVolume &amp;,
                                    G4int aRepNum = 0);
     void ChangeImportance(G4double importance,
                           const G4GeometryCell &amp;gCell);
     void ChangeImportance(G4double importance,
                           const G4VPhysicalVolume &amp;,
                                 G4int aRepNum = 0);
     G4double GetImportance(const G4VPhysicalVolume &amp;,
                                  G4int aRepNum = 0) const ;
   private: .....
 };
</programlisting>
</informalexample>
</para>

<para>
The member function <literal>AddImportanceGeometryCell()</literal> enters
a cell and an importance value into the importance store. The
importance values may be returned either according to a physical
volume and a replica number or according to a
<literal>G4GeometryCell</literal>. The user must be aware of the
interpretation of assigning importance values to a cell.
If scoring is also implemented then this is attached to logical volumes, in
which case the physical volume and replica number method should be used for
assigning importance values. See <literal>examples/extended/biasing
B01</literal> and <literal>B02</literal> for examples of this.
</para>

<para>
<note>
  <para>
  <itemizedlist spacing="compact">
  <listitem><para>
    An importance value must be assigned to every cell.
  </para></listitem>
  </itemizedlist>
  </para>
</note>
</para>

<para>
The different cases:

<itemizedlist spacing="compact">
  <listitem><para>
    <emphasis>Cell is not in store</emphasis>
    <para>
    Not filling a certain cell in the store will cause an
    exception.
    </para>
  </para></listitem>
  <listitem><para>
    <emphasis>Importance value = zero</emphasis>
    <para>
    Tracks of the chosen particle type will be killed.
    </para>
  </para></listitem>
  <listitem><para>
    <emphasis>importance values &gt; 0</emphasis>
    <para>
    Normal allowed values
    </para>
  </para></listitem>
  <listitem><para>
    <emphasis>Importance value smaller zero</emphasis>
    <para>
    Not allowed!
    </para>
  </para></listitem>
</itemizedlist>
</para>

</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.EvtBias.ScorImpRoul.SampAlgor">
<title>
The Importance Sampling Algorithm
</title>

<para>
Importance sampling supports using a customized importance
sampling algorithm. To this end, the sampler interface 
<link linkend="anchor_EvtBias_G4VSampler">
<literal>G4VSampler</literal></link>
may be given a pointer to the interface 
<literal>G4VImportanceAlgorithm</literal>:

<informalexample>
<programlisting>      
 class G4VImportanceAlgorithm
 {
   public:  
     G4VImportanceAlgorithm();
     virtual ~G4VImportanceAlgorithm();
     virtual G4Nsplit_Weight Calculate(G4double ipre,
                                       G4double ipost,
                                       G4double init_w) const = 0;
 };
</programlisting>
</informalexample>      
</para>

<para>
The method <literal>Calculate()</literal> takes the arguments:

<itemizedlist spacing="compact">
  <listitem><para>
    <emphasis>ipre, ipost</emphasis>: importance
    of the previous cell and the importance of the current cell,
    respectively.
  </para></listitem>
  <listitem><para>
    <emphasis>init_w</emphasis>: the particles weight
  </para></listitem>
</itemizedlist>
</para>

<para>
It returns the struct:

<informalexample>
<programlisting>      
 class G4Nsplit_Weight
 {
   public:

   G4int fN;
   G4double fW;
 };
</programlisting>
</informalexample>      

<itemizedlist spacing="compact">
  <listitem><para>
    <emphasis>fN</emphasis>: the calculated
    number of particles to exit the importance sampling
  </para></listitem>
  <listitem><para>
    <emphasis>fW</emphasis>: the weight of the particles
  </para></listitem>
</itemizedlist>
</para>

<para>
The user may have a customized algorithm used by providing a
class inheriting from <literal>G4VImportanceAlgorithm</literal>.
</para>

<para>
If no customized algorithm is given to the sampler the default
importance sampling algorithm is used. This algorithm is
implemented in <literal>G4ImportanceAlgorithm</literal>.
</para>

</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.EvtBias.ScorImpRoul.WeightWin">
<title>
The Weight Window Technique
</title>

<para>
The weight window technique is a weight-based alternative to
importance sampling:

<itemizedlist spacing="compact">
  <listitem><para>
    applies splitting and Russian roulette depending on space
    (cells) and energy
  </para></listitem>
  <listitem><para>
    user defines weight windows in contrast to defining importance
    values as in importance sampling
  </para></listitem>
</itemizedlist>
</para>

<para>
In contrast to importance sampling this technique is not weight
blind. Instead the technique is applied according to the particle
weight with respect to the current energy-space cell.
</para>

<para>
Therefore the technique is convenient to apply in combination
with other variance reduction techniques such as cross-section
biasing and implicit capture.
</para>

<para>
A weight window may be specified for every cell and for several
energy regions: <emphasis>space-energy cell</emphasis>.

<figure id="fig.EvtBias.WeightWindow">
<title>
  Weight window concept
</title>

<mediaobject>
 <imageobject role="fo">
    <imagedata fileref="./AllResources/Fundamentals/wwconcept.jpg"
               format="JPG" contentwidth="9.0cm" align="center" />
  </imageobject>
  <imageobject role="html">
    <imagedata fileref="./AllResources/Fundamentals/wwconcept.jpg"
               format="JPG" align="center" />
  </imageobject>
  <textobject>
    <phrase>Weight window concept</phrase>
  </textobject>
</mediaobject>
</figure>
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
Weight window concept
</bridgehead>

<para>
  The user specifies a <emphasis>lower weight bound W_L</emphasis> 
  for every space-energy cell.

  <itemizedlist spacing="compact">
    <listitem><para>
      The upper weight bound W_U and the survival weight W_S are
      calculated as:
      <para>
      W_U = C_U <emphasis>W_L</emphasis> and
      </para>
      <para>
      W_S = C_S <emphasis>W_L</emphasis>.
      </para>
    </para></listitem>
    <listitem><para>
      The user specifies C_S and C_U once for the whole problem.
    </para></listitem>
    <listitem><para>
      The user may give different sets of energy bounds for every cell
      or one set for all geometrical cells
    </para></listitem>
    <listitem><para>
      Special case: if C_S = C_U = 1 for all energies then weight
      window is equivalent to importance sampling
    </para></listitem>
    <listitem><para>
      The user can choose to apply the technique: at boundaries, on
      collisions or on boundaries and collisions
    </para></listitem>
  </itemizedlist>
</para>

<para>
The energy-space cells are realized by <literal>G4GeometryCell</literal>
as in importance sampling. The cells are stored in a weight window
store defined by <literal>G4VWeightWindowStore</literal>:

<informalexample>
<programlisting>
 class  G4VWeightWindowStore {
  public:  
    G4VWeightWindowStore();
    virtual  ~G4VWeightWindowStore();
    virtual G4double GetLowerWeitgh(const G4GeometryCell &amp;gCell, 
                                  G4double partEnergy) const = 0;
    virtual G4bool IsKnown(const G4GeometryCell &amp;gCell) const = 0;
    virtual const G4VPhysicalVolume &amp;GetWorldVolume() const = 0;
 };
</programlisting>
</informalexample>
</para>

<para>
A concrete implementation is provided:

<informalexample>
<programlisting>
  class G4WeightWindowStore: public G4VWeightWindowStore {
   public:  
     explicit G4WeightWindowStore(const G4VPhysicalVolume &amp;worldvolume);
     virtual ~G4WeightWindowStore();
     virtual G4double GetLowerWeitgh(const G4GeometryCell &amp;gCell, 
                                     G4double partEnergy) const;
     virtual G4bool IsKnown(const G4GeometryCell &amp;gCell) const;
     virtual const G4VPhysicalVolume &amp;GetWorldVolume() const;
     void AddLowerWeights(const G4GeometryCell &amp;gCell,
                          const std::vector&lt;G4double&gt; &amp;lowerWeights);
     void AddUpperEboundLowerWeightPairs(const G4GeometryCell &amp;gCell,
                                         const G4UpperEnergyToLowerWeightMap&amp;
                                         enWeMap);
     void SetGeneralUpperEnergyBounds(const 
         std::set&lt;G4double, std::less&lt;G4double&gt; &gt; &amp; enBounds);
  
   private::
   ...  
  };
</programlisting>
</informalexample>
</para>

<para>
The user may choose equal energy bounds for all cells. In this
case a set of upper energy bounds must be given to the store using
the method <literal>SetGeneralUpperEnergyBounds</literal>. If a general set
of energy bounds have been set <literal>AddLowerWeights</literal> can be used
to add the cells.
</para>

<para>
Alternatively, the user may chose different energy regions for
different cells. In this case the user must provide a mapping of
upper energy bounds to lower weight bounds for every cell using the
method <literal>AddUpperEboundLowerWeightPairs</literal>.
</para>

<para>
Weight window algorithms implementing the interface class
<literal>G4VWeightWindowAlgorithm</literal> can be used to define a
customized algorithm:

<informalexample>
<programlisting>
 class G4VWeightWindowAlgorithm {
  public:  
    G4VWeightWindowAlgorithm();
    virtual ~G4VWeightWindowAlgorithm();
    virtual G4Nsplit_Weight Calculate(G4double init_w,
                                      G4double lowerWeightBound) const = 0;
 };
</programlisting>
</informalexample>
</para>

<para>
A concrete implementation is provided and used as a default:

<informalexample>
<programlisting>
 class G4WeightWindowAlgorithm : public G4VWeightWindowAlgorithm {
  public:  
    G4WeightWindowAlgorithm(G4double upperLimitFaktor = 5,
                            G4double survivalFaktor = 3,
                            G4int maxNumberOfSplits = 5);
    virtual ~G4WeightWindowAlgorithm();
    virtual G4Nsplit_Weight Calculate(G4double init_w,
                                      G4double lowerWeightBound) const;
  private:
   ...
};
</programlisting>
</informalexample>
</para>

<para>
The constructor takes three parameters which are used to:
calculate the upper weight bound (upperLimitFaktor), calculate the
survival weight (survivalFaktor), and introduce a maximal number
(maxNumberOfSplits) of copies to be created in one go.
</para>

<para>
In addition, the inverse of the maxNumberOfSplits is used to
specify the minimum survival probability in case of Russian
roulette.
</para>

</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.EvtBias.ScorImpRoul.WeigRoul">
<title>
The Weight Roulette Technique
</title>

<para>
Weight roulette (also called weight cutoff) is usually applied
if importance sampling and implicit capture are used together.
Implicit capture is not described here but it is useful to note
that this procedure reduces a particle weight in every collision
instead of killing the particle with some probability.
</para>

<para>
Together with importance sampling the weight of a particle may
become so low that it does not change any result significantly.
Hence tracking a very low weight particle is a waste of computing
time. Weight roulette is applied in order to solve this
problem.
</para>

<!-- ******* Bridgehead ******* -->
<bridgehead renderas='sect4'>
The weight roulette concept
</bridgehead>

<para>
Weight roulette takes into account the importance "Ic" of the
current cell and the importance "Is" of the cell in which the
source is located, by using the ratio "R=Is/Ic".
</para>

<para>
Weight roulette uses a relative minimal weight limit and a
relative survival weight. When a particle falls below the weight
limit Russian roulette is applied. If the particle survives,
tracking will be continued and the particle weight will be set to
the survival weight.
</para>

<para>
The weight roulette uses the following parameters with their
default values:

<itemizedlist spacing="compact">
  <listitem><para>
    <emphasis>wsurvival</emphasis>: 0.5
  </para></listitem>
  <listitem><para>
    <emphasis>wlimit</emphasis>: 0.25
  </para></listitem>
  <listitem><para>
    <emphasis>isource</emphasis>: 1
  </para></listitem>
</itemizedlist>
</para>

<para>
The following algorithm is applied:
</para>

<para>
If a particle weight "w" is lower than R*wlimit:

<itemizedlist spacing="compact">
  <listitem><para>
    the weight of the particle will be changed to "ws = wsurvival*R"
  </para></listitem>
  <listitem><para>
    the probability for the particle to survive is "p = w/ws"
  </para></listitem>
</itemizedlist>
</para>

</sect3>
</sect2>


<!-- ******************* Section (Level#2) ****************** -->
<sect2 id="sect.EvtBias.PhysBias">
<title>
Physics Based Biasing
</title>

<para>
Geant4 supports physics based biasing through a number of general
use, built in biasing techniques. A utility class,
G4WrapperProcess, is also available to support user defined
biasing.
</para>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.EvtBias.PhysBias.BuiltInOpt">
<title>
Built in Biasing Options
</title>

<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.EvtBias.PhysBias.BuiltInOpt.PrimPart">
<title>
Primary Particle Biasing
</title>

<para>
Primary particle biasing can be used to increase the number of
primary particles generated in a particular phase space region of
interest. The weight of the primary particle is modified as
appropriate. A general implementation is provided through the
G4GeneralParticleSource class. It is possible to bias position,
angular and energy distributions.
</para>

<para>
G4GeneralParticleSource is a concrete implementation of
G4VPrimaryGenerator. To use, instantiate G4GeneralParticleSource in
the G4VUserPrimaryGeneratorAction class, as demonstrated below.

<informalexample>
<programlisting>
   MyPrimaryGeneratorAction::MyPrimaryGeneratorAction() { 
      generator = new G4GeneralParticleSource; 
   } 

   void 
   MyPrimaryGeneratorAction::GeneratePrimaries(G4Event*anEvent){ 
      generator-&gt;GeneratePrimaryVertex(anEvent); 
   }
</programlisting>
</informalexample>
</para>

<para>
The biasing can be configured through interactive commands.
Extensive documentation can be found in 
<ulink url="http://reat.space.qinetiq.com/gps/">
Primary particle biasing</ulink>.  Examples are also distributed
with the Geant4 distribution in
<emphasis role="bold">examples/extended/eventgenerator/exgps</emphasis>.
</para>

</sect4>

<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.EvtBias.PhysBias.BuiltInOpt.RadDcy">
<title>
Radioactive Decay Biasing
</title>

<para>
The G4RadioactiveDecay class simulates the decay of radioactive
nuclei and implements the following biasing options:

<itemizedlist spacing="compact">
  <listitem><para>
    Increase the sampling rate of radionuclides within observation
    times through a user defined probability distribution function
  </para></listitem>
  <listitem><para>
    Nuclear splitting, where the parent nuclide is split into a
    user defined number of nuclides
  </para></listitem>
  <listitem><para>
    Branching ratio biasing where branching ratios are sampled with
    equal probability
  </para></listitem>
</itemizedlist>
</para>

<para>
G4RadioactiveDecay is a process which must be registered with a
process manager, as demonstrated below.

<informalexample>
<programlisting>
   void MyPhysicsList::ConstructProcess() 
   { 
      ... 
      G4RadioactiveDecay* theRadioactiveDecay = 
         new  G4RadioactiveDecay(); 

      G4ProcessManager* pmanager = ... 
      pmanager -&gt;AddProcess(theRadioactiveDecay); 
      ... 
   }
</programlisting>
</informalexample>
</para>

<para>
The biasing can be controlled either in compiled code or through
interactive commands. Extensive documentation can be found in

<ulink url="http://reat.space.qinetiq.com/septimess/exrdm/">
Radioactive decay biasing example
</ulink>
 and 
<ulink url="http://www.space.qinetiq.com/geant4/rdm.html">
Radioactive decay biasing
</ulink>. 
</para>

<para>
Radioactive decay biasing examples are also distributed with the Geant4
distribution in
<emphasis role="bold">examples/extended/radioactivedecay/exrdm</emphasis>.
</para>

</sect4>

<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.EvtBias.PhysBias.BuiltInOpt.HadLeadPar">
<title>
Hadronic Leading Particle Biasing
</title>

<para>
One hadronic leading particle biasing technique is
implemented in the G4HadLeadBias utility. This method keeps only
the most important part of the event, as well as representative
tracks of each given particle type. So the track with the highest
energy as well as one of each of Baryon, pi0, mesons and leptons.
As usual, appropriate weights are assigned to the particles.
Setting the <emphasis role="bold">SwitchLeadBiasOn</emphasis> 
environmental variable will activate this utility.
</para>

</sect4>

<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.EvtBias.PhysBias.BuiltInOpt.HadCrsSect">
<title>
Hadronic Cross Section Biasing
</title>

<para>
Cross section biasing artificially enhances/reduces the cross
section of a process. This may be useful for studying thin layer
interactions or thick layer shielding. The built in hadronic cross
section biasing applies to photon inelastic, electron nuclear and
positron nuclear processes.
</para>

<para>
The biasing is controlled through the
<emphasis role="bold">BiasCrossSectionByFactor</emphasis> method 
in G4HadronicProcess, as demonstrated below. 

<informalexample>
<programlisting>
   void MyPhysicsList::ConstructProcess() 
   { 
      ... 
      G4ElectroNuclearReaction * theElectroReaction = 
         new G4ElectroNuclearReaction; 

      G4ElectronNuclearProcess theElectronNuclearProcess;    
      theElectronNuclearProcess.RegisterMe(theElectroReaction); 
      theElectronNuclearProcess.BiasCrossSectionByFactor(100);
  
      pManager-&gt;AddDiscreteProcess(&amp;theElectronNuclearProcess); 
      ...  
   }
</programlisting>
</informalexample>
</para>

</sect4>
</sect3>


<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.EvtBias.PhysBias.">
<title>
G4WrapperProcess
</title>

<para>
G4WrapperProcess can be used to implement user defined event
biasing. G4WrapperProcess, which is a process itself, wraps an
existing process. By default, all function calls are forwared to
the wrapped process. It is a non-invasive way to modify the
behaviour of an existing process.
</para>

<para>
To use this utility, first create a derived class inheriting
from G4WrapperProcess. Override the methods whose behaviour you
would like to modify, for example, PostStepDoIt, and register the
derived class in place of the process to be wrapped. Finally,
register the wrapped process with G4WrapperProcess. The code
snippets below demonstrate its use.

<informalexample>
<programlisting>
   class MyWrapperProcess  : public G4WrapperProcess { 
   ... 
    G4VParticleChange* PostStepDoIt(const G4Track&amp; track, 
                                    const G4Step&amp; step) { 
       // Do something interesting 
    } 
   }; 


   void MyPhysicsList::ConstructProcess() 
   { 
   ... 
      G4LowEnergyBremsstrahlung* bremProcess = 
         new G4LowEnergyBremsstrahlung(); 

      MyWrapperProcess* wrapper = new MyWrapperProcess(); 
      wrapper-&gt;RegisterProcess(bremProcess); 

      processManager-&gt;AddProcess(wrapper, -1, -1, 3); 
   } 
</programlisting>
</informalexample>
</para>

</sect3>

</sect2>

<!-- ******************* Section (Level#2) ****************** -->
<sect2 id="sect.EvtBias.ReverseMC">
<title>
Adjoint/Reverse Monte Carlo
</title>

<para>
Another powerful biasing technique available in Geant4 is the Reverse Monte Carlo (RMC) method, 
also known as the Adjoint Monte Carlo method. In this method  particles are generated  on the external 
boundary  of the sensitive  part of the  geometry and then are tracked backward in the geometry till they 
reach  the external source surface, 
or exceed an energy threshold. By this way the computing time is focused only on particle tracks 
that are contributing to the tallies.
The RMC  method is much rapid than the Forward MC method when the sensitive part of the geometry is 
small compared to the rest of the geometry and to the external source,  that has to be  extensive and 
not beam like. At the moment the RMC method is implemented in Geant4 only for some electromagnetic 
processes (see <xref linkend="sect.EvtBias.ReverseMC.InG4.Process" />). An example illustrating the use 
of the Reverse MC method in Geant4 is distributed within the Geant4
toolkit in <emphasis role="bold">examples/extended/biasing/ReverseMC01</emphasis>.
</para>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.EvtBias.ReverseMC.InG4">
<title>
Treatment of the  Reverse MC method in Geant4 
</title>

<para>
Different G4Adjoint classes have been implemented into the Geant4 
toolkit in order to run an adjoint/reverse simulation in a Geant4 application.
This implementation is illustrated in  <xref linkend="fig.EvtBias.ReverseMC.InG4_1" />.
An adjoint run is divided in a serie of alternative adjoint and forward tracking  of adjoint and normal particles.
One Geant4 event treats one of this tracking phase. 
</para>

<figure id="fig.EvtBias.ReverseMC.InG4_1">
<title>
 Schematic view of an adjoint/reverse simulation in Geant4 
</title>
<mediaobject>
  <imageobject role="fo">
    <imagedata fileref="./AllResources/Fundamentals/ReverseMC_tracking.png" 
               format="png"  align="center" />
  </imageobject>
  <imageobject role="html">
    <imagedata fileref="./AllResources/Fundamentals/ReverseMC_tracking.png" 
               format="png"  align="center" />
  </imageobject>
</mediaobject>
</figure>


<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.EvtBias.ReverseMC.InG4.AdjointTracking">
<title>
Adjoint tracking phase 
</title>

<para>
 Adjoint particles (adjoint_e-, adjoint_gamma,...) are generated  one by one on the so called adjoint source
with  random position,  energy (1/E distribution) and direction. The adjoint source is the 
external surface of a user defined volume or of a user defined sphere. The adjoint
source should contain one or several sensitive volumes and should be small compared to the entire geometry.
The user can set the minimum and maximum energy of the adjoint source. After its
generation the adjoint primary  particle is tracked backward in the geometry till a user  defined
 external surface 
(spherical or boundary of a volume) or is killed before if it reaches a user defined  upper energy limit that 
represents the maximum energy of the external source. During the reverse tracking, reverse
processes take place where  the adjoint particle being tracked can be either scattered
or transformed in another type of adjoint particle. During the reverse tracking the
G4AdjointSimulationManager replaces the user defined primary, run, stepping, ... actions, by its own actions.
A reverse tracking phase corresponds to one Geant4 event.
</para>

</sect4>

<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.EvtBias.ReverseMC.InG4.ForwardTracking">
<title>
Forward tracking phase 
</title>

<para>
When an adjoint particle reaches the external surface its weight, type,  position, 
and direction are registered and a  normal primary particle, with a type equivalent to the last generated primary
adjoint, is generated with the same energy, position but opposite direction  and is  tracked in the forward direction 
in the sensitive region as in a forward MC simulation. 
During this forward tracking phase the  
event, stacking, stepping, tracking actions defined by the user for his forward simulation are used. 
By this clear separation between
adjoint and forward tracking phases, the code of the user developed for a forward simulation 
should be only slightly  modified to adapt it for an adjoint simulation (see <xref linkend="sect.EvtBias.ReverseMC.UserCoding" />). 
Indeed  the computation of the signals is done by the same actions 
or classes that the one used in the forward simulation mode.   
A forward tracking phase corresponds to one G4 event.
</para>

</sect4>

<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.EvtBias.ReverseMC.InG4.Process">
<title>
Reverse processes 
</title>

<para>
During the reverse tracking, reverse processes act on the adjoint particles.
The reverse processes that are at the moment available in Geant4 are the:
<itemizedlist spacing="compact">
        <listitem><para>
        Reverse discrete  ionization for e-, proton and ions
        </para></listitem>
        <listitem><para>
        Continuous gain of energy by ionization and bremsstrahlung for e- and by ionization for protons and ions
        </para></listitem>
        <listitem><para>
        Reverse discrete e- bremsstrahlung
        </para></listitem>
        <listitem><para> 
        Reverse photo-electric effect 
        </para></listitem>
        <listitem><para> 
        Reverse Compton scattering
        </para></listitem>
        <listitem><para>
        Approximated multiple scattering  (see comment in <xref linkend="sect.EvtBias.ReverseMC.Limitation.ReverseMS"/>)
        </para></listitem>
</itemizedlist>
It is important to note that the electromagnetic reverse processes are cut dependent 
as their equivalent forward processes. The implementation of the reverse processes is based on 
the forward processes implemented in the G4 standard electromagnetic package.                
</para>

</sect4>

<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.EvtBias.ReverseMC.InG4.RemarkOnNbEvents">
<title>
Nb of adjoint particle types and nb of G4 events of an adjoint simulation
</title>

<para>
The list of type of adjoint and forward particles that are generated on the adjoint source 
and considered in the simulation  is a function of the adjoint processes declared in the physics list.
For example if only the e- and gamma electromagnetic processes are considered, 
only adjoint e- and adjoint gamma will be considered as primaries.
In this case an adjoint event will be divided in four G4 event consisting in  the reverse tracking of an adjoint e-, 
the forward tracking of its equivalent forward e-, the reverse tracking of 
an adjoint gamma, and the forward tracking of its equivalent forward gamma. 
In this case a run of 100 adjoint events will consist into 400 Geant4 events.
If the proton ionization is also considered adjoint and forward protons are also generated as primaries 
and 600 Geant4 events are processed for  100 adjoint events.
</para>  

</sect4>

</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.EvtBias.ReverseMC.UserCoding">
<title>
How to update a G4 application  to use the reverse Monte Carlo mode 
</title>

<para>
Some modifications are needed  to an existing  Geant4 application in order to adapt 
it for the use of the reverse simulation mode 
(see also the G4 example <emphasis role="bold">examples/extended/biasing/ReverseMC01</emphasis>).
It consists into the:

<itemizedlist spacing="compact">
        <listitem><para>
        Creation of  the adjoint simulation manager in the main code
        </para></listitem>
        <listitem><para>
        Optional declaration of user actions that will be used during the adjoint tracking phase
        </para></listitem>
        <listitem><para>
        Use of a special physics lists that combine the adjoint and forward processes
        </para></listitem>
        <listitem><para>
        Modification of the user analysis part of the code
        </para></listitem>
</itemizedlist>
</para>


<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.EvtBias.ReverseMC.UserCoding.Main">
<title>
Creation of   G4AdjointSimManager in the main
</title>
<para>
The class G4AdjointSimManager represents the manager  of an adjoint simulation. 
This static class should be created somewhere in the main code. The way to do that is illustrated below 
<informalexample>
<programlisting>
   int main(int argc,char** argv) { 
      ... 
      G4AdjointSimManager* theAdjointSimManager = G4AdjointSimManager::GetInstance();
      ... 
   }
</programlisting>
</informalexample> 
By doing this  the G4 application  can be   run in the reverse  MC mode as well 
 as in the forward MC mode.  
It is important to note that G4AdjointSimManager
is not a new G4RunManager and that the creation of G4RunManager in the main  and the declaration of the geometry,
 physics list,  and user actions to G4RunManager is still needed.
The   definition of  the adjoint and external sources and the start of an adjoint simulation can be controlled
by   G4UI  commands in the directory  <emphasis role="bold">/adjoint</emphasis>.
</para>
</sect4>


<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.EvtBias.ReverseMC.UserCoding.AdjointActions">
<title>
Optional declaration of adjoint user actions
</title>
<para>
During an adjoint  simulation the user stepping, tracking, stacking and event  actions declared to G4RunManager
 are used only during the G4 events dedicated to the forward tracking of normal particles in the sensitive region, 
 while during the events where  adjoint particles are tracked backward the   following happen concerning these actions:
    
<itemizedlist spacing="compact">
<listitem><para>
The user stepping action is replaced by G4AdjointSteppingAction that is reponsible to stop an adjoint track when
it reaches the external source,  exceed the maximum energy of the external source, or cross the adjoint source surface. 
If needed the user can declare its own stepping action  that will be called by  G4AdjointSteppingAction after the 
check of stopping track conditions. This stepping action can be different that the stepping action used for the 
forward simulation. It is declared to G4AdjointSimManager by the following lines of code :
        
<informalexample><programlisting>
   G4AdjointSimManager* theAdjointSimManager = G4AdjointSimManager::GetInstance();
   theAdjointSimManager-&gt;SetAdjointSteppingAction(aUserDefinedSteppingAction); 
</programlisting></informalexample>
                  
</para></listitem>

<listitem><para>
No stacking, tracking and event actions are considered by default. If needed the user can declare to G4AdjointSimManager
stacking, tracking and event actions that will be used only during the adjoint tracking phase. 
The following lines of code show how to declare these adjoint actions to G4AdjointSimManager:

<informalexample><programlisting>
   G4AdjointSimManager* theAdjointSimManager = G4AdjointSimManager::GetInstance();
   theAdjointSimManager-&gt;SetAdjointEventAction(aUserDefinedEventAction);
   theAdjointSimManager-&gt;SetAdjointStackingAction(aUserDefinedStackingAction);
   theAdjointSimManager-&gt;SetAdjointTrackingAction(aUserDefinedTrackingAction);
</programlisting></informalexample>

</para></listitem>
        
</itemizedlist>
By default no user run action is considered in an adjoint simulation but if needed such action can be declared to 
 G4AdjointSimManager as such:
<informalexample><programlisting>
   G4AdjointSimManager* theAdjointSimManager = G4AdjointSimManager::GetInstance();
   theAdjointSimManager-&gt;SetAdjointRunAction(aUserDefinedRunAction);
</programlisting></informalexample> 

</para>

</sect4>

<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.EvtBias.ReverseMC.UserCoding.PhysicsList">
<title>
Physics list for reverse and forward electromagnetic processes 
</title>

<para>
To run an adjoint simulation a specific physics list should be used where existing G4 adjoint electromagnetic processes
and their forward equivalent have to be declared.
 An example of such physics list is provided by the class G4AdjointPhysicsLits in the  G4 example 
 <emphasis role="bold">extended/biasing/ReverseMC01</emphasis>.
</para>

</sect4>

<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.EvtBias.ReverseMC.UserCoding.Analysis">
<title>
Modification in the analysis part of the code
</title>

<para>
The  user code should be modified to  normalize the signals computed during the forward tracking phase to the weight of the last adjoint particle
that reaches the external surface. 
This weight represents the  statistical weight  that the last full adjoint tracks (from the adjoint source 
to the external source)  would have in a forward  simulation.   If multiplied by a signal  and registered in function of energy 
and/or direction the simulation results will give an answer matrix of this signal.
 To normalize it to a given spectrum it has to be furthermore multiplied by a directional differential flux  
 corresponding to this spectrum 
   
The weight, direction, position , kinetic energy and type of the last adjoint particle that reaches the 
 external source, and that would represents the primary of a forward simulation,  can be   get from G4AdjointSimManager by using for example the following line of codes
<informalexample><programlisting>
   
   G4AdjointSimManager* theAdjointSimManager = G4AdjointSimManager::GetInstance();
   G4String particle_name = theAdjointSimManager-&gt;GetFwdParticleNameAtEndOfLastAdjointTrack();
   G4int PDGEncoding= theAdjointSimManager-&gt;GetFwdParticlePDGEncodingAtEndOfLastAdjointTrack();
   G4double weight = theAdjointSimManager-&gt;GetWeightAtEndOfLastAdjointTrack();
   G4double Ekin  = theAdjointSimManager-&gt;GetEkinAtEndOfLastAdjointTrack();
   G4double Ekin_per_nuc=theAdjointSimManager-&gt;GetEkinNucAtEndOfLastAdjointTrack(); // in case of ions
   G4ThreeVector dir =  theAdjointSimManager-&gt;GetDirectionAtEndOfLastAdjointTrack();
   G4ThreeVector pos = theAdjointSimManager-&gt;GetPositionAtEndOfLastAdjointTrack();
   
</programlisting></informalexample> 

</para>

<para>
In order to have a code working for both forward and adjoint simulation mode, the extra code needed in user actions or analysis 
manager  for the adjoint
simulation mode can be separated to the code needed only for the normal forward  simulation by using the following public method
of G4AdjointSimManager:
<informalexample><programlisting>
G4bool GetAdjointSimMode();
</programlisting></informalexample> 
that returns true if   an adjoint simulation is running and false if not.

</para>

<para>
The following   code example shows how  to normalize a detector signal and compute an answer matrix 
in the case of an adjoint simulation.
 <example id="sect.EvtBias.ReverseMC.UserCoding.Analysis_1">
<title>
Normalization in the case of an adjoint simulation. The detector signal S computed during the forward tracking 
phase is normalized to a primary source of e-  with a differential directional flux given by the function F. 
An answer matrix of the signal is also computed.  
</title>

<programlisting>
   
   G4double S = ...; // signal   in the sensitive volume computed during a forward tracking phase

   //Normalization of the signal for an adjoint simulation
   G4AdjointSimManager* theAdjSimManager =    G4AdjointSimManager::GetInstance();
   if (theAdjSimManager->GetAdjointSimMode()) {
        G4double normalized_S=0.; //normalized to a given  e- primary spectrum
        G4double S_for_answer_matrix=0.; //for e- answer matrix
        
        if (theAdjSimManager->GetFwdParticleNameAtEndOfLastAdjointTrack() == "e-"){
            G4double ekin_prim = theAdjSimManager-&gt;GetEkinAtEndOfLastAdjointTrack();
            G4ThreeVector dir_prim =  theAdjointSimManager-&gt;GetDirectionAtEndOfLastAdjointTrack();
            G4double weight_prim = theAdjSimManager->GetWeightAtEndOfLastAdjointTrack();
            S_for_answer_matrix = S*weight_prim;
            normalized_S = S_for_answer_matrix*F(ekin_prim,dir); //F(ekin_prim,dir_prim) gives the differential directional flux of primary e-
        }  
       //follows the code where normalized_S  and S_for_answer_matrix are  registered or whatever 
        ....
   }
   
   //analysis/normalization code for forward simulation 
   else { 
     ...
   }
   ...
</programlisting>
</example> 

</para>

</sect4>

</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.EvtBias.ReverseMC.Control">
<title>
Control of an adjoint simulation
</title>

<para>
The G4UI  commands in the directory  
<ulink url="./AllResources/Control/UIcommands/_adjoint_.html">/adjoint</ulink>.
allow the user to :
<itemizedlist spacing="compact">
        <listitem><para>
        Define the adjoint source where adjoint primaries are generated
        </para></listitem>
        <listitem><para>
        Define the external source till which adjoint particles are  tracked 
        </para></listitem>
        <listitem><para>
        Start an adjoint simulation
        </para></listitem>
</itemizedlist>
</para>
</sect3>

<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.EvtBias.ReverseMC.Limitation">
<title>
Known issues in the Reverse MC mode  
</title>

<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.EvtBias.ReverseMC.Limitation.Weight">
<title>
Occasional wrong high weight in the adjoint simulation
</title>

<para>
In rare cases an adjoint track may get a wrong high weight when  reaching the external source.
While this happens not often it may corrupt the simulation results significantly. This happens 
in some tracks where  both  reverse photo-electric and bremsstrahlung processes take place at low energy.
We still need some investigations to remove this problem  at the level of physical adjoint/reverse processes. 
However  this problem can be solved  at the level of event actions or analysis in the user code by adding a test on the 
normalized signal during an adjoint simulation. An example of such test has been implemented in the Geant4 example 
<emphasis role="bold"> extended/biasing/ReverseMC01 </emphasis>. 
In this implementation  an event is rejected when the relative error of the computed  normalized energy deposited
increases during one event by more than 50% while the computed precision  is already below 10%.
</para>

</sect4>

<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.EvtBias.ReverseMC.Limitation.ReverseBrem">
<title>
Reverse bremsstrahlung
</title> 

<para>
A difference between the differential cross sections used in the adjoint and forward bremsstrahlung 
 models is the source of a higher flux of >100 keV gamma in the reverse simulation compared to the forward simulation mode.
In principle the adjoint processes/models should make use of the direct differential cross section to sample
 the adjoint  secondaries and compute the adjoint cross section. However due to the way the effective differential cross section is 
 considered in the forward model G4eBremsstrahlungModel this was not possible to achieve for the reverse bremsstrahlung.
Indeed the differential cross section used in G4AdjointeBremstrahlungModel  is obtained by the numerical derivation
over the cut energy of the direct cross section provided  by G4eBremsstrahlungModel. 
This would be a correct procedure if the  distribution of secondary in   G4eBremsstrahlungModel  
would match this differential cross section. Unfortunately it is not the case as independent  parameterization are used 
 in   G4eBremsstrahlungModel  for both the cross sections and the sampling of secondaries. (It means that in the forward case 
 if one would integrate the effective differential cross section considered  in the simulation we would not find back 
 the used cross section). 
 In the future we plan to correct this problem by using an extra weight correction factor after the occurrence of a reverse
 bremsstrahlung. This weight factor should be the ratio between the differential CS used in the adjoint simulation and the 
one effectively used in the forward processes. As it is impossible to have a simple and direct  access to the forward differential CS 
 in G4eBremsstrahlungModel we  are investigating the feasibility to use  the differential CS considered in  
 G4Penelope models.
</para> 

</sect4>

<!-- ******************* Section (Level#4) ****************** -->
<sect4 id="sect.EvtBias.ReverseMC.Limitation.ReverseMS">
<title>
Reverse multiple scattering
</title> 
  
<para>
For the reverse multiple scattering  the same model is used than  in the forward case.
This approximation makes that the discrepancy between the adjoint and forward 
simulation cases can get to a level of ~ 10-15% relative differences in the test cases that we have considered. 
In the future we plan to improve   the adjoint multiple scattering models  by forcing the computation of 
 multiple scattering effect at the end of an adjoint step.
</para>
 
</sect4>

</sect3>
</sect2>
</sect1>