Kamil Sedlak 2009-05-22

Few tiny modifications:
  1) added doc/run file for easier processing of the musrSim.tex file
  2) updated documentation (musrSim.pdf)
  3) removed one of two definitions of "lightblue" in musrDetectorConstruction.cc
  4) added the volume "G4Para" in musrDetectorConstruction.cc
  5) corrected small bug for "2DBOperaXY" type of field in musrTabulatedElementField.cc

doc/musrSim.tex

@@ -61,7 +61,7 @@ Geant4}. The root output variables are also described.
         muon is generated {\bf uniformly} in the interval of ($x0-$ {\it xSigma}, $x0+$ {\it xSigma}).\\
 	If {\it xSigma} $= 0$ ... no smearing on the $x$ coordinate is applied.\\
 	Similar is true for {\it ySigma} and {\it zSigma}. \\
-	This variables are ignored when TURTLE input is requested.
+	(Ignored by the TURTLE input).	
 
 \item{\bf /gun/vertexboundary \emph{R\_max} \emph{z\_min} \emph{z\_max} \emph{unit}}\\
 	Set maximum allowed radius, and minimum and maximum z coordinate of the generated particles (muons).
@@ -74,14 +74,16 @@ Geant4}. The root output variables are also described.
 	is applied on the initial particles, while \emph{z\_min} and \emph{z\_max} are ignored.
 
 \item{\bf /gun/kenergy \emph{kineticEnergy} \emph{unit}}\\
-	Set the mean kinetic energy of the initial particles (muons).
+	Set the mean kinetic energy of the initial particles (muons).\\
+	(Ignored by the TURTLE input).	
 
 \item{\bf /gun/momentum \emph{momentum} \emph{unit}}\\
-	Set the mean momentum of the initial particles (muons).
+	Set the mean momentum of the initial particles (muons).\\
+	(Ignored by the TURTLE input).	
 
 \item{\bf /gun/momentumsmearing  \emph{momentumSigma} \emph{unit}}\\
 	Set $\sigma$, i.e. the standard deviation (RMS), of the momentum spread, which
-        is aplied randomly to each generated initial particle (muon). It is the magnitude
+        is applied randomly to each generated initial particle (muon). It is the magnitude
 	of the momentum, which is smeared. \\
 	(Ignored by the TURTLE input.  However,
 	a similar command ``/gun/turtleMomentumBite'' can be used for the TURTLE input file.)
@@ -108,7 +110,7 @@ Geant4}. The root output variables are also described.
 	The angle given as \emph{pitch} will be applied to a particle generated 1\,mm away from the
 	beam centre, i.e. the particle generated 7\,mm away from the beam axis will be assigned
         the angle of $7\cdot pitch$.
-	The pitch allows the user to focus or defocuse the initial particle
+	The pitch allows the user to focus or defocus the initial particle
 	beam. Particles will be focused for positive pitch and defocused for the negative pitch.\\
 	(Applicable also to TURTLE input).
 
@@ -128,13 +130,13 @@ Geant4}. The root output variables are also described.
 	If \emph{polarisFraction} is set to 1,  all muons are polarised in the direction 
 	of polarisation vector defined by ``/gun/muonPolarizVector''.\\
 	If \emph{polarisFraction} is set to 0,  half of the muons are polarised in the direction 
-	of polarisation vector, the second half is polarised in the oposite dirrection, so
+	of polarisation vector, the second half is polarised in the opposite direction, so
 	in the end the muon beam should act as unpolarised.\\
 	If \emph{polarisFraction} is set to -1,  all muons are polarised in the direction 
-	oposite to the polarisation vector.\\
+	opposite to the polarisation vector.\\
 	{\bf If \emph{polarisFraction} is set to 0.9, then 95\% of the muons is polarised
 	in in the direction of polarisation vector, and 5\% of them is polarised in the 
-	oposite dirrection!}.\\
+	opposite direction!}.\\
 	{\bf This command is ignored if magnitude of polarisation vector defined by
 	``/gun/muonPolarizVector'' is smaller than 1e-8!} \\
 	(Applicable also to TURTLE input).
@@ -151,12 +153,21 @@ Geant4}. The root output variables are also described.
 	(Applicable also to TURTLE input).
 
 \item{\bf /gun/turtlefilename \emph{turtleFileName}}\\
-	Set the filename of the TURTLE input file.  If this varialble is set, TURTLE file 
+	Set the filename of the TURTLE input file.  If this variable is set, TURTLE file 
-        will be used to initiate muons.  Otherwise the mouns would be generated randomly.
+        will be used to initiate muons.  Otherwise the muons would be generated randomly.
+	If the end of the TURTLE file is reached (because the user requested to simulate
+	more events than saved in the TURTLE file), the TURTLE file be be rewind to its
+	beginning.  Note that this does not mean that the same events will be simulated
+	after the rewind, because the random seed will be set differently than at the
+	beginning of the simulation.  Note that the muons initialised
+	at the same position and with the same momentum will have completely different
+	(random) multiple scattering, penetration depths, decay times,
+	decay positron energies and angles, ..., and therefore will be (almost completely) 
+	different events not affecting the statistical quality of the sample.
 
 \item{\bf /gun/turtleZ0position  \emph{z0\_InitialTurtle}  \emph{unit}}\\
 	Set the z-position which has been used to generate the TURTLE file.\\
-	If this value differes from the $z0$ value of the ``/gun/vertex'' command,
+	If this value differs from the $z0$ value of the ``/gun/vertex'' command,
 	than the particle initial position is extrapolated from $z0\_InitialTurtle$ 
 	to the point corresponding to $z0$, using the direction of its momenta.\\
 	MORE DETAILS:\\
@@ -171,19 +182,40 @@ Geant4}. The root output variables are also described.
 	
 \item{\bf /gun/turtleMomentumBite \emph{turtleMomentumP0} \emph{turtleSmearingFactor} \emph{dummy} }\\
 	Modify the smearing of the momentum bite specified in the TURTLE input file.  
-	Normally the muon momentum is defined already in the turtle input file.  This command allows the user
+	Normally the muon momentum is defined already in the TURTLE input file.  This command allows the user
 	to modify the momentum smearing (momentum bite) of the muon beam.
 	The variable \emph{turtleMomentumP0} will be taken as the mean momentum (in MeV/c), around which
 	the momentum will be increased/decreased. It does not have to be the real mean value of the initial muon momentum distribution.
         The variable \emph{turtleSmearingFactor} is the smearing factor in per cent, by which the momentum bite
 	will be increased/decreased around the \emph{turtleMomentumP0}.  The following equation is used to change the
-	muon momentum: $p^{new}$ = {\it turtleMomentumP0} - ({\it turtleMomentumP0}-$p^{TURTLE}$)$\cdot$0.01$\cdot${\it turtleSmearingFactor}.\\
+	muon momentum: $p_{new}$ = {\it turtleMomentumP0} - ({\it turtleMomentumP0}-$p_{TURTLE}$)$\cdot$0.01$\cdot${\it turtleSmearingFactor}.\\
 	This means that:\\
 	{\it turtleSmearingFactor} = 100 ... the muon beam momentum will not be modified.\\
 	{\it turtleSmearingFactor} = 0 ~~... the muon beam momentum will be set to the constant value of {\it turtleMomentumP0}.\\
 	{\it turtleSmearingFactor} = 200 ... the muon beam will have two times broader distribution compared to the original TURTLE file.
 
 \item{\bf /gun/turtleFirstEventNr \emph{lineNumberOfTurtleFile} }\\
+	Set the line number that should be taken as the first event from the TURTLE input file.
+	This option is needed when the user wants to reproduce the simulation of an event
+        using the same random number generator and TURTLE initial particle as in some previous
+        run, however he wants to skip some (uninteresting) events at the beginning of the simulation.
+
+\item{\bf /gps/*} \\
+	In most cases, musrSim uses the so called ``G4ParticleGun'' to generate the primary
+	particles (muons).  The commands for G4ParticleGun were summarised previously, 
+	they start with /gun/ keyword.\\
+	However, there is an alternative particle generator
+	called ``GPS (General Particle Source)'', which is useful when simulating
+	the decays of radioactive atoms and for other purposes.
+	Whenever the /gps/ keyword is used, the ``G4ParticleGun'' is not initiated
+	(and all /gun/* commands are ignored).
+	The description of GPS can be found on the web, some of the useful commands are:\\
+	/gps/particle ion\\
+	/gps/ion 38 90 0 0\\
+	/gps/position 0 0 0\\
+	/gps/energy 0 keV\\
+	/gps/ang/maxtheta 2 deg\\
+	/gps/ang/maxphi 2 deg\\
 
 \end{description}
 
@@ -191,107 +223,249 @@ Geant4}. The root output variables are also described.
 \section{Detector construction}
 
 \begin{description}
-%
+
 \item{\bf /musr/command rotation \emph{matrixName} $\alpha$ $\beta$ $\gamma$} \\
 	{\bf /musr/command rotation \emph{matrixName} \emph{vx} \emph{vy} \emph{vz} \emph{angle}}\\
-	These commands define a rotation matrix of the name ``matrixName'' that can be used later on
+	These commands define a rotation matrix of the name \emph{matrixName} that can be used later on
 	during the definition of the detector geometry (see command ``/musr/command construct'').
 	It can be defined either by the Euler angles (if there are three float parameters behind the
         \emph{matrixName}) or by the vector \emph{(vx,vy,vz)} and an \emph{angle} of rotation around this
 	vector (if the fourth float parameter behind the \emph{matrixName} is non-zero).
 	All angles are specified in degrees.
-%
+
-\item{\bf /musr/command construct \emph{solid}=string \emph{name}=string \emph{dimensions}=float ... \emph{material}=string 
+\item{\bf /musr/command construct \emph{solid} \emph{name} \emph{dimensions} ... \emph{material} 
-	\emph{x}=float \emph{y}=float \emph{z}=float \emph{motherVolume}=string \emph{rotationMatrix}=string 
+	\emph{x} \emph{y} \emph{z} \emph{motherVolume} \emph{matrixName} 
-	\emph{sensitiveClass}=string \emph{idNumber}=int }\\
+	\emph{sensitiveClass} \emph{idNumber} }\\
 	This command defines a volume in {\sc Geant4} (It comprises three steps of {\sc Geant4}: defines a solid,
-        logical volume and physical volume.  More details have to be found in {\sc Geant4} manual). \\
+        logical volume and physical volume.  Details can to be found in {\sc Geant4} manual). \\
 	\begin{itemize}
-	\item \emph{solid} can be one of the G4VSolid.cc particular types, presently ``tubs'', ``box'', ``sphere'',
+	\item \emph{solid} (string) can be one of the G4VSolid.cc particular types, presently ``tubs'', ``cons'',
+	             ``box'', ``trd'', ``sphere'', ``para'',
 	             or it can be one of the specifically implemented solids by our program as ``uprofile'' 
 	             (an U-profiled bar), ``alcSupportPlate'' (shape specific to ALC support plate), ``tubsbox'' 
-	             (a tube with a rectangular hole along its axis) and "tubsboxsegm" 
+	             (a tube with a rectangular hole along its axis), "tubsboxsegm" 
-	             (a volume that looks like an intersection of tube and box).  Not all G4VSolids are
+	             (a volume that looks like an intersection of tube and box) and 
+                     ``trd90y'' (a trd volume rotated by 90 degrees around $y$ axis in addition
+                     to the rotation requested by \emph{matrixName}).  Not all G4VSolids are
                      presently supported, but it is relatively easy to implement a new kind of solids
                      in the musrDetectorConstruction.cc class.
-	\item \emph{name} stands for the name of the volume.  As the ``/musr/command construct'' construct
+	\item \emph{name} (string) stands for the name of the volume.  As the command 
-	             three kinds of classes (volumes) -- the solid, logical volume and physical 
+		     ``/musr/command construct'' constructs
-	             volume -- there are three names of the concrete volume used internally inside 
+	             three kinds of classes/volumes (the solid, logical volume and physical 
-                     the program: sol\_\emph{name}, log\_\emph{name} and phys\_\emph{name}.
+	             volume), there are three names of the concrete volume used internally inside 
+                     musrSim: sol\_\emph{name}, log\_\emph{name} and phys\_\emph{name}.
 	              The main volume, inside which all other volumes are positioned, has to be called  ``World''.
-	\item \emph{dimensions} define the size of the required solid.  They are kept equivalent to the
+	\item \emph{dimensions} (floats) define the size of the required solid.  They are kept equivalent to the
 	             dimensions of solids as used in {\sc Geant4}.  For example the ``box'' is defined
-	             by its halfwidths along $x$, $y$ and $z$ coordinates.  Note that the number of
+	             by its {\bf halflengths} along $x$, $y$ and $z$ coordinates.  Note that the number of
-	             \emph{dimensions} varies for each type of solid.
+	             \emph{dimensions} varies for each type of solid.  The units are mm for lengths
-	\item \emph{material} one of the materials defined in {\sc Geant4}, namely in the file 
+		     and degrees for angles.
+	\item \emph{material} (float) one of the materials defined in {\sc Geant4}, namely in the file 
 	             \$G4INSTALL/source/materials/src/G4NistMaterialBuilder.cc (e.g. ``G4\_Galactic'' for
-	             vacuum, ``G4\_Cu'' for copper, ``G4\_AIR'' for air and 
+	             vacuum, ``G4\_Cu'' for copper, ``G4\_AIR'' for air, 
-                     ``G4\_PLASTIC\_SC\_VINYLTOLUENE'' for a scintillator).
+                     ``G4\_PLASTIC\_SC\_VINYLTOLUENE'' for a scintillator, ...).
 	             One can also define a new material inside the function 
                      musrDetectorConstruction::DefineMaterials().  Presently ``Mylar'', ``Brass'' 
-                     and ``Steel'' are defined there.
+                     ``Steel'', ``Macor'', ``MCPglass'', ``MgO'', ``SiO2'', ``K2O'' and ``B2O3'' are defined there.
-	\item \emph{x, y, z} -- coordinates of the volume, used to position the volume within
+	\item \emph{x, y, z} (floats) -- coordinates of the volume, used to position the volume within
                      its mother volume (as used by the G4PVPlacement).  
-	\item \emph{motherVolume} -- name of the mother volume, in which the given volume should be
+		     Thus these coordinates are interpreted in the local coordinate system of the \emph{motherVolume}.
+	\item \emph{motherVolume} (string) -- name of the mother volume, in which the given volume should be
 	             positioned.  Note that the mother volume has to be defined first (before its
                      daughter), and that the name of mother starts with a string {\bf log\_}\emph{name},
 	             following the naming convention defined above.  
 	             When the ``World'' volume is defined, its \emph{motherVolume} should be set to ``no\_logical\_volume''.
-	\item \emph{rotationMatrix} -- name of the rotation matrix that will be used to position
+	\item \emph{matrixName} (string) -- name of the rotation matrix that will be used to position
-	             the volume inside its mother volume (as used in member function G4PVPlacement()).  
+	             the volume inside its mother volume (as used in member function G4PVPlacement).  
 	             Use string ``norot'' if no rotation is required for the given volume.
 	             Otherwise the rotation matrix has to be defined by the command line 
-	             ``/musr/command rotation'' {\bf before} the given is defined. 
+	             ``/musr/command rotation'' {\bf before} the given volume is defined. 
-        \item \emph{sensitiveClass} -- specifies whether the volume is sensitive or not.
+        \item \emph{sensitiveClass} (string) -- specifies whether the volume is sensitive detector or
-	             Use the string ``dead'' for the non-senstive volume (i.e.\ for the dead material),
+		     just a piece of a ``dead'' material.
+	             Use the string ``dead'' for the latter,
 	             and the string ``musr/ScintSD'' for a scintillator (a sensitive volume, i.e.\
                      a volume where hits are observed).  No other detector type
 	             (other than ``dead'' and ``musr/ScintSD'') is supported at the moment, but
 	             the program might be extended in the future (e.g. to properly include also the
 	             semiconductor tracking detectors, etc.).
-	\item \emph{idNumber} -- idNumber serves as a unique identifier of the volume.  It is primarily
+	\item \emph{idNumber} (int) -- serves as a unique identifier of the volume.  It is primarily
-	             used in the output Root tree to identify the volume: 1) in which muons stop 
+	             used in the output Root tree to identify the volume: 1) in which a muon stopped 
 	             (tree variable ``muDecayDetID''), 
 	             2) in which hits were deposited in case of sensitive volume 
                      (the variable ``det\_ID[det\_n]'').
 	\end{itemize}	
-%tubs beampipeA      0   128 500 0 360 G4_Galactic  0 0 -800 log_World norot dead 232
 
-\item{\bf /musr/command logicalVolumeToBeReweighted mu \emph{logicalVolume}=string \emph{weight}=int }\\
+\item{\bf /musr/command region define  \emph{regionName} \emph{logicalVolume}}\\
-	(default: not defined; no reweighting is done unless explicitly requested by this command.) \\
+	The ``G4Region'' can be created using this command, and a logical volume of the
-	Events can be reweighted by this command.  If muon {\bf stops and decays} in the
+	name \emph{logicalVolume} will be assigned to it.  If the G4Region of the name 
-	volume \emph{logicalVolume}, the event will be reweighted using the requested \emph{weight}.  
+	\emph{regionName} does not exist (i.e.\ the command ``/musr/command region define''
-	Namely, only each $n^{th}$ event will be stored ($n=$\emph{weight}) with the parameter
+	is called for the first time for this particular \emph{regionName}), the G4Region will
-	``weight'' in the Root output tree set to \emph{weight}, while other (non-$n^{th}$) events
+	be created first, otherwise the logical volume \emph{logicalVolume} will be just assigned
-	will be aborted. (The decision which event is to be stored and which to be aborted is
+	to the already existing G4Region.  \\
-	done at random).  This reweighting might be usefull in the cases when the user wants to speed-up the
+	G4Region can be useful namely for setting some special Geant4 parameters (production cuts)
-	simulation (respectively to reduce the number of fully simulated events), while keeping
+	just in some part of the detector (e.g.\ where a finer simulation is needed).
-	the high number of events interesting for the analysis.  For example, one can set
+	See Geant4 manual for more details.
-	the reweighting of events in which muons stop in the collimator.  One should then
-	use the \emph{weight} stored in the Root tree when filling histograms.  
-	Compared to the simulation with no weighting applied, the histograms with weighted events
-	will have larger errors, but the distribution should not differ more then within the
-	statistical errors.\\
-	Note that the \emph{weight} parameter is integer, and ``mu'' stands for ``muons''
-	(at the moment reweighting based on electrons or positrons is not supported).
 
+\item{\bf /musr/command region setProductionCut \emph{regionName} \emph{gammaCut} \emph{electronCut} \emph{positronCut}}\\
+	Set the so-called ``production cuts'' in the G4Region called \emph{regionName}.
+	The variables \emph{gammaCut, electronCut} and \emph{positronCut} are given in mm.
+\end{description}
+Three special volumes ``Target, M0, M1 and M2''.
 
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\section{Electric and magnetic fields}
+\begin{description}
+\item{\bf /musr/command globalfield \emph{fieldName} \emph{half\_x} \emph{half\_y} \emph{half\_z} uniform 
+	\emph{X} \emph{Y} \emph{Z} \emph{logicalVolume} \emph{Bx} \emph{By} \emph{Bz} \emph{Ex} \emph{Ey} \emph{Ez}} \\
+	or \\
+	{\bf /musr/command globalfield \emph{fieldName} \emph{X} \emph{Y} \emph{Z} fromfile
+	\emph{fieldTableType} \emph{fieldInputFileName} \emph{logicalVolume} \emph{fieldValue} 
+	\emph{[fieldValueFinal]} \emph{[fieldNrOfSteps]}} \\
+	This command specifies the electric and/or magnetic fields, which are (in some sense)
+	independent of any logical volume and can overlap with each other.
+	In the case of tabulated field read in from and external field map file the
+	field values used internally by the Geant4 are linearly interpolated using
+	eight (3D) or four (2D) grid points surrounding the point of interest.
+%
+	\begin{itemize}
+	   \item \emph{fieldName} (string) -- name of the field (important mainly for the user and 
+		print-out messages of the musrSim.
+	   \item \emph{half\_x}, \emph{half\_y}, \emph{half\_z} (floats) -- the (half) dimensions
+		of the box, within which the uniform field is defined.
+	   \item {\bf uniform / fromfile} -- specifies whether the field is uniform within
+		some volume or whether it is read in from an external file as a field-map.
+	   \item \emph{X}, \emph{Y}, \emph{Z} (floats) -- position of the centre of the field
+		in the {\bf global} coordinate system. IMPORTANT: For some technical internal
+		Geant4 reasons, this POSITION HAS TO LAY WITHIN THE \emph{logicalVolume}!
+		(Note that the logical volume may be positioned somewhere deep in a volume
+                 structure, not directly within the ``World'' volume, and
+		therefore the (local) coordinates in the definition of the the logical volume
+		do not have to match the (global) coordinates \emph{X}, \emph{Y} and \emph{Z}.
+	   \item \emph{logicalVolume} (string) -- specifies the logical volume, to which
+		the field is ``assigned''.  One may ask, why a logical volume is needed for a field
+		``independent'' of any Geant4 volume?  The reason is purely technical - the
+		logical volume is used to allow the field to be rotated the same way as
+		the assigned logical volume. 
+		The field can be smaller or larger than the logical
+		volume, to which it is assigned.  
+		The field extending out of the logical volume will 
+		also be used in the Geant4 calculations (will be not truncated).
+		The only limitation is that the centre
+		of the volume has to lay within the assigned logical volume (see above).
+		Sometimes it might be useful to create a very small volume (e.g. of the order of 0.01\,mm)
+		to position a rotated field into a (differently rotated or unrotated) 
+		larger volume.  The volume can also be made of vacuum (i.e.\ G4\_Galactic).
+	   \item \emph{Bx}, \emph{By}, \emph{Bz}, \emph{Ex}, \emph{Ey}, \emph{Ez} (float) -- the vector
+		of the uniform electromagnetic field.  The units are tesla, for the first three
+		components, and kilovolt/mm for the last three components.
+	   \item \emph{fieldTableType} (string) -- specifies the format in which the field map is
+		written in the file.  In general, the field is specified in a grid of
+		three space coordinates $x$, $y$ and $z$ (3D).
+		Sometimes it is convenient to use the symmetry of the field
+		and to reduce the field description to $R$ and $z$ (2D) only.  
+		In the following, we use this terms: \\
+		\emph{nx, ny, nz} or \emph{nR, nz} -- the number of divisions of the grid in
+		\emph{x, y, z} or \emph{R, z}.
+		\emph{length unit} -- the unit in which the grid coordinates are specified, usually
+		cm or m.\\
+		\emph{field normalisation factor} -- a multiplicative factor applied to the values
+		of the field map to normalise the field (usually to 1\,tesla or to 1\,kV/mm in the
+		centre of the field map).\\
+		\emph{minimumx, maximumx, minimumy, maximumy, minimumz, maximumz} -- the
+		minimum and maximum value in x, y and z coordinates.  These values can be usually easily
+		calculated from the field map itself, however the field can also be specified
+		in a compact format in which case the $x$, $y$ and $z$ coordinates are removed from
+		the field map file,
+		and the maxima and minima of coordinates have to be specified.\\
+		The following formats are supported:\\
+		{\bf 3DB, 3DE} -- magnetic or electric field specified in $x$, $y$ and $z$
+			coordinate system.  The first line of the file has to contain
+			the information about \emph{nx, ny, nz, length unit} and 
+			\emph{field normalisation factor}.  Optionally, a compact form
+			of the field map can be specified, in which case
+			\emph{minimumx, maximumx, minimumy, maximumy, minimumz, maximumz}
+			has to be added to the first line of the file.
+			The next few lines of the field map file beginning with
+			the character ``\%'' are comments.
+			The following lines specify the \emph{x, y, z, Field\_x, Field\_y, Field\_z}
+			values (non-compact format) or \emph{Field\_x, Field\_y, Field\_z} values
+			(compact format).\\
+		{\bf 3DBOpera} -- 3D magnetic field in the form of OPERA output.
+			It is expected that the \emph{length unit} is 1\,m, and
+			the \emph{field normalisation factor} is 1. (Note that this is
+			different from 2DBOpera and 2DBOperaXY options).\\
+		{\bf 2DB, 2DE} -- magnetic or electric field specified in $R$ and $z$
+			coordinate system.  The first line of the file has to contain
+			the information about \emph{nR,  nz, length unit} and 
+			\emph{field normalisation factor}. The compact form of the field
+			map (see 3DB case) is not supported.
+			The next few lines of the field map file beginning with
+			the character ``\%'' are comments.
+			The following lines specify the \emph{R, z, Field\_R} \emph{Field\_z}
+			values.\\
+		{\bf 2DBOpera} -- 2D magnetic field in the form of OPERA output.
+			It is expected that the \emph{length unit} is 1\,cm, and
+			the \emph{field normalisation factor} is 0.00001 (Note that this is
+			different from 3DBOpera option).
+			The data in the field map OPERA file are ordered as
+			\emph{R, dummy, z, Field\_R, Field\_z, dummy}\\
+		{\bf 2DBOperaXY} -- same as 2DBOpera except that the 
+			data in the field map OPERA file are ordered as
+			\emph{R, z, dummy, Field\_R, Field\_z, dummy}\\
+	   \item \emph{fieldInputFileName} (string) -- Name of the field map file.
+	   \item \emph{fieldValue} (float) -- the value of the field at some reference point
+		(usually in the centre of the field).  It serves as some multiplicative
+		factor.  The units are tesla for the magnetic field and  kV/mm
+		for the electric field.
+	   \item \emph{[fieldValueFinal]} and \emph{[fieldNrOfSteps]} (floats) 
+		-- an experimental feature, which allows the user to ramp up (down) the field
+		during a single run.  The \emph{fieldValue} serves as the initial field value,
+		the \emph{[fieldValueFinal]} is the final value and \emph{[fieldNrOfSteps]}
+		specifies number of steps, in which the rump up/down will happen.
+	\end{itemize}
+
+\item{\bf /musr/command globalfield \emph{fieldName} \emph{X} \emph{Y} \emph{Z} quadrupole
+	\emph{halfLength} \emph{fieldRadius} \emph{fringeFactor} \emph{logicalVolume} 
+	\emph{gradientValue} \emph{[gradientValueFinal]} \emph{[gradientNrOfSteps]} }\\
+	Set up the field of a quadrupole magnet including the Enge function approximation of the
+	fringe fields.  The description is similar to the uniform field and to the tabulated fields.
+	See ``musrDetectorConstruction.cc'' and ``BLEngeFunction.hh'' for the details.
+
+\item{\bf /musr/command globalfield setparameter \emph{parameterName} \emph{parameterValue} }\\
+	Set up some parameters used internally by Geant4 when calculating the motion
+	of charged particles in the magnetic field.\\
+	\emph{parameterName} (string) -- one of the following parameters: ``SetDeltaIntersection''
+	``SetDeltaOneStep'', ``SetMinimumEpsilonStep'', ``SetMaximumEpsilonStep'',
+	``SetLargestAcceptableStep'' and ``SetMaxLoopCount''.  The exact meaning of
+	these parameters can be found in Geant4 manual.
+
+\item{\bf /musr/command globalfield printparameters} \\
+	Print out the accuracy parameters (see ``/musr/command globalfield setparameter'').
+
+\item{\bf /musr/command globalfield printFieldValueAtPoint \emph{x} \emph{y} \emph{z}} \\
+	Print out the field value at the point $(x, y, z)$ (given in the global 
+	coordinate system.
 \end{description}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \section{Visualisation}
 
 \begin{description}
-\item{\bf /musr/command visattributes \emph{volumeName} \emph{color}}\\
+\item{\bf /musr/command visattributes \emph{volumeName} \emph{colour}}\\
-     {\bf /musr/command visattributes \emph{materialName} \emph{color}}\\
+     {\bf /musr/command visattributes \emph{materialName} \emph{colour}}\\
 	In case of visualisation,	
-	one can set the color of a logical volume \emph{volumeName} or of all volumes made
+	one can set the colour of a logical volume \emph{volumeName} or of all volumes made
 	of the material with the name \emph{materialName}.  The distinction between the
 	two options is by the first four letters of the \emph{volumeName} -- if it contains
 	the string ``log\_'', it is considered as \emph{volumeName}, otherwise it is
 	considered to be a material with \emph{materialName}.
 
-	Presently the following colors are predefined: ``invisible'', ``white'', ``black'', 
+	Presently the following colours are predefined: ``invisible'', ``white'', ``black'', 
-	``red'', ``green'', ``blue'', ``lightblue'', ``yellow'', ``gray'', ``cyan'' and ``magenta''.
+	``red'', ``darkred'', ``green'', 
+	``blue'', ``lightblue'', ``darkblue'', ``blue\_style'', ``fblue\_style'',
+	``yellow'', ``gray'', ``cyan'', ``magenta'',
+	``oxsteel'', ``MCP\_style'', ``MACOR\_style'', ``SCINT\_style'',
+	``dSCINT\_style'', ``VTBB\_style'', ``Grid\_style'' and ``RA\_style''.
+
 	New colours can be easily added, if needed, in the member function
 	``musrDetectorConstruction::SetColourOfLogicalVolume''.
 
@@ -300,17 +474,20 @@ Geant4}. The root output variables are also described.
 \section{Physics processes}
 
 \begin{description}
-\item{\bf /musr/command process addDiscreteProcess \emph{particle}=string \emph{process}=string }\\
+\item{\bf /musr/command process addDiscreteProcess \emph{particle} \emph{process}}\\
-{\bf /musr/command process addProcess \emph{particle}=string \emph{process}=string \emph{ordAtRestDoIt}=int \emph{ordAlongSteptDoIt}=int \emph{ordPostStepDoIt}=int }\\
+{\bf /musr/command process addProcess \emph{particle} \emph{process} \emph{ordAtRestDoIt} \emph{ordAlongSteptDoIt} \emph{ordPostStepDoIt}}\\
-	Adds processes for particles.  See {\sc Geant4} manual for more details.  Look in the
+	Adds processes for particles. \\
-	file musrPhysicsList.cc for the list of defined processes (e.g. G4MultipleScattering,
+	\emph{particle} (string) -- name of the particle to which a process is applied.\\
-	G4eIonisation, ...)
+	\emph{process} (string) -- name of the process to be assigned.\\
+	\emph{ordAtRestDoIt, ordAlongSteptDoIt, ordPostStepDoIt} (int) -- priority switches.\\
+	See the file musrPhysicsList.cc for the list of defined processes (e.g. G4MultipleScattering,
+	G4eIonisation, ...) and Geant4 manual for the detail description of the processes.
 
 	There is one special process, combined from G4MultipleScattering and G4CoulombScattering,
 	defined by the following command:\\
-{\bf /musr/command process addProcess  \emph{particle}=string MultipleAndCoulombScattering \emph{ordAtRestDoIt}=int \emph{ordAlongSteptDoIt}=int \emph{ordPostStepDoIt}=int \emph{G4Region1}=string  [\emph{G4Region2}=string]  [\emph{G4Region3}=string] }\\
+{\bf /musr/command process addProcess  \emph{particle} MultipleAndCoulombScattering \emph{ordAtRestDoIt} \emph{ordAlongSteptDoIt} \emph{ordPostStepDoIt} \emph{G4Region1}  [\emph{G4Region2}]  [\emph{G4Region3}]}\\
 	The G4MultipleScattering (rough but very fast approximation of scattering) will be applied
-	elswhere in the detector, except for the \emph{G4Region1} (and eventually \emph{G4Region2}
+	elsewhere in the detector, except for the \emph{G4Region1} (and eventually \emph{G4Region2}
 	and \emph{G4Region3}), where more precise but very slow process G4CoulombScattering
 	will be applied instead of G4MultipleScattering.  Note that up to three
 	G4Regions are supported at the moment, but this limitation is not intrinsic to {\sc Geant4}
@@ -319,7 +496,112 @@ Geant4}. The root output variables are also described.
 
 \end{description}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\clearpage
+\section{Some other parameters}
+%
+\begin{description}
+\item{\bf /run/beamOn \emph{nrOfEvents}}\\
+	Specify how many events will be simulated in this run/job.\\
+	\emph{nrOfEvents} (int) -- number of events to be simulated.\\
+	(This is a default Geant4 command, which has to be specified in any simulation run).
+
+\item{\bf /musr/command logicalVolumeToBeReweighted mu \emph{logicalVolume} \emph{weight} }\\
+	(default: not defined; no reweighting is done unless explicitly requested by this command.) \\
+	Events can be reweighted by this command.  If muon {\bf stops and decays} in the
+	volume \emph{logicalVolume}, the event will be reweighted using the requested \emph{weight}.  
+	Namely, only each $n^{th}$ event will be stored in the output Root tree ($n=$\emph{weight})
+	with the Root tree output variable 
+	``weight'' set to \emph{weight}, while other (non-$n^{th}$) events
+	will be aborted. (The decision which event is to be stored and which to be aborted is
+	done at random).  This reweighting might be useful in the cases when the user wants to speed-up the
+	simulation (respectively to reduce the number of fully simulated events), while keeping
+	the high number of events interesting for the analysis.  For example, one can set
+	the reweighting of events in which muons stop in the collimator.  The user should then
+	use the \emph{weight} stored in the Root tree when analysing the simulated data (i.e. when 
+	filling histograms).  
+	Compared to the simulation with no weighting applied, the histograms with weighted events
+	will have larger errors, but the distributions should not differ more then within the
+	statistical errors.\\
+	Note that the \emph{weight} parameter is integer, and ``mu'' stands for ``muons''
+	(at the moment reweighting based on electrons or positrons is not supported).
+
+\item{\bf /musr/command SetUserLimits \emph{logicalVolume} \emph{ustepMax} \emph{utrakMax} \emph{utimeMax} \emph{uekinMin} \emph{urangMin}}\\
+	Set the so-called user limits (G4UserLimits) in a volume  \emph{logicalVolume}.
+	The five last parameters correspond to the Geant4 methods
+	``SetMaxAllowedStep'', ``SetUserMaxTrackLength'', ``SetUserMaxTime'',
+	``SetUserMinEkine'' and ``SetUserMinRange''.
+
+\item{\bf /musr/command storeOnlyEventsWithHits false}\\
+	By default, only the events in which at least one hit in an active
+	volume (detector) has been recorded are saved to the output Root tree,
+	because the events with no hit in any detector will anyway not contribute
+	to the real measurement (even not to the pileup background).
+	However, the user has a possibility to use this command
+	to store all events for some technical study, e.g. to learn where
+	the muons stop in collimators, etc.
+
+\item{\bf /musr/command storeOnlyEventsWithHitInDetID \emph{volumeID}}\\
+	This command is similar to the previous one.  Only the events,
+	in which there was at least one hit in the volume with the
+	\emph{volumeID} will be saved into the output Root tree.
+	This command might be useful in some technical studies, it might
+	introduce some bias in a physics study.
+
+\item{\bf /musr/command storeOnlyTheFirstTimeHit true}\\
+	This command specifies that only the hit that happens first will be
+	saved, while all the other hits will be ignored.
+	This command might be useful in some technical studies, it would
+	be harmful in most physics studies.
+
+\item{\bf /musr/command killAllPositrons true}\\
+	It might be useful in some technical studies to abandon all positron
+	tracks (to ignore all positrons).  For example if the user wants
+	to study where the muon hit detectors and where do they stop and
+	decay, this command might help him to get rid of all hits
+	caused by the decay positron.  This command would be
+	harmful in most physics studies.
+
+\item{\bf /musr/command killAllGammas true}\\
+	See ``/musr/command killAllPositrons true'' for the explanation.
+
+\item{\bf /musr/command killAllNeutrinos false}\\
+	By default the neutrino tracks are ``killed'' in the musrSim to
+	speed up the simulation, because
+	the neutrinos anyway do not interact with the detectors.
+	(This ``killing'' of neutrinos does not affect the muon decay in
+	any way).
+	However, it might be useful not to kill the neutrinos when the
+	user wants to display the complete muon decay event.
+	This command allows one not to kill the neutrinos.
+
+\item{\bf /musr/command getDetectorMass \emph{logicalVolume}}\\
+	This command prints out the mass of a given volume (detector)
+	including all its daughter volumes (components).
+
+\item{\bf /musr/command signalSeparationTime \emph{timeSeparation}}\\
+	There is some time for each detectors, during which it can not distinguish
+	two subsequent hits.  The command mimics such feature.
+	If there are two energy deposits that happen in the same
+	active volume (detector) within the time \emph{timeSeparation}
+	(in ns), then these two energy deposits are summed up into
+	a single hit.  Otherwise they will form two different hits.
+	This is true regardless on whether the two energy deposits were
+	induced by the same particle or by different particles.
+	Presently the parameter \emph{timeSeparation} is common to all
+	scintillator detectors in the system, which means it is not
+	possible to set different \emph{timeSeparation} for a slow
+	and fast scintillator detectors of the instrument.
+
+\item{\bf /musr/command maximumRunTimeAllowed \emph{timeMax}}\\
+	If a musrSim job is run on a pc farm with a time limit on the job execution,
+	and the job exceeds the time limit, the simulation will be killed.
+	The output Root tree will be not closed properly, and the
+	information stored in the Root vector ``geantParametersD''
+	will be not saved.  To avoid the hard abort,
+	the job will be terminated gently if its physical execution time
+	exceeds \emph{timeMax}.  
+	Note that the units of \emph{timeMax} are seconds,
+	and the default value is set to 85000\,s (23\,hours, 37\,minutes).
+\end{description}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \section{Output root tree variables}
 The value of -999 or -1000 indicates that the given variable could not be filled
@@ -327,19 +609,36 @@ The value of -999 or -1000 indicates that the given variable could not be filled
 For example if the variable ``muTargetTime'' is set to -1000 it means that the initial muon missed the sample, 
 and therefore no time can be assigned to the sample hit.
 
+The user can choose which variables should not be stored in the output file using the command
+\begin{description}
+\item{\bf /musr/command rootOutput \emph{variableName} off} \\
+	The \emph{variableName} is identical with the variable names stored in the Root tree
+	(see below).  Presently the exception is ``save'' volume, for which all variables
+	will be stored in the Root tree, if such a ``save'' volume is requested.
+	Another exception are the Root tree variables ``nFieldNomVal'' and ``fieldNomVal[nFieldNomVal]'',
+	which are both suppressed using the keyword ``fieldNomVal''.
+	The last exceptions are the variables ``fieldIntegralBx'',
+	``fieldIntegralBy'', ``fieldIntegralBz'', ``fieldIntegralBz1'', 
+	``fieldIntegralBz2'', ``fieldIntegralBz3'', which are usually not required
+	in an analysis program, and they are therefore not written out to the Root tree by default.  
+	This can be changed using the command ``/musr/command rootOutput \emph{variableName} on''.
+\end{description}
+
+The list of variables that can be stored in the Root tree:
 \begin{description}
 \item{\bf runID} (Int\_t) -- run ID number.        
 \item{\bf eventID} (Int\_t) -- event ID number.
 \item{\bf weight} (Double\_t) -- event weight.
 \item{\bf BFieldAtDecay\_Bx, BFieldAtDecay\_By, BFieldAtDecay\_Bz, BFieldAtDecay\_B3, BFieldAtDecay\_B4, BFieldAtDecay\_B5} (Double\_t) --
 	value of the 6 coordinates of the electromagnetic field at the position and time where and when the muon decayed.
-        The first three coordinates correspond to the magnetic field, the last three to the electric field.
+        The first three coordinates correspond to the magnetic field (in tesla), the last three to the electric field
+	(in kV/mm).
 \item{\bf muIniPosX, muIniPosY, muIniPosZ}  (Double\_t) -- initial position where muon was generated (in mm).
 \item{\bf muIniMomX, muIniMomY, muIniMomZ}  (Double\_t) -- initial momentum of the muon when it was generated (in MeV/c).
 \item{\bf muIniPolX, muIniPolY, muIniPolZ}  (Double\_t) -- initial polarisation of the muon when it was generated.
 \item{\bf muDecayDetID} (Int\_t) -- ID number of the detector in which the muon stopped and decayed.
-\item{\bf muDecayPosX, muDecayPosY, muDecayPosZ}  (Double\_t) -- the position where the muon stopped and decayed (in mm).
 \item{\bf muDecayTime} (Double\_t) -- the time at which the muon stopped and decayed (in $\mu$s).
+\item{\bf muDecayPosX, muDecayPosY, muDecayPosZ}  (Double\_t) -- the position where the muon stopped and decayed (in mm).
 \item{\bf muDecayPolX, muDecayPolY, muDecayPolZ}  (Double\_t) -- polarisation of the muon when it stopped and decayed.
 \item{\bf muTargetTime}  (Double\_t) -- time at which the muon entered the volume whose name starts by ``target'' -- usually the sample (in $\mu$s).
 \item{\bf muTargetPolX, muTargetPolY, muTargetPolZ} (Double\_t) -- polarisation of the muon when it entered the volume whose name starts with ``target'' -- usually the sample.
@@ -349,7 +648,7 @@ and therefore no time can be assigned to the sample hit.
 \item{\bf muM1PolX, muM1PolY, muM1PolZ}  (Double\_t) -- polarisation of the muon when it entered the detector called ``M1'' or ``m1''.
 \item{\bf muM2Time}  (Double\_t) -- time at which the muon entered the detector called ``M2'' or ``m2'' (in $\mu$s).
 \item{\bf muM2PolX, muM2PolY, muM2PolZ}  (Double\_t) -- polarisation of the muon when it entered the detector called ``M2'' or ``m2''.
-\item{\bf posIniMomX,   posIniMomY, posIniMomY}  (Double\_t) -- Initial momentum of the decay positron (in MeV/c).
+\item{\bf posIniMomX,   posIniMomY, posIniMomZ}  (Double\_t) -- Initial momentum of the decay positron (in MeV/c).
 \item{\bf nFieldNomVal} (Int\_t) -- number of the elementary fields that make together the global field.
 \item{\bf fieldNomVal[nFieldNomVal]} (array of Double\_t) -- nominal values of all elementary fields.  
 	(They are usually constant, but sometimes they may vary from event to event).
@@ -391,9 +690,11 @@ and therefore no time can be assigned to the sample hit.
 \item{\bf det\_time\_start[det\_n], det\_time\_end[det\_n]} (array of Double\_t) -- the initial and final time belonging of the hit.
 	It should be the ``global time'' of the track when the first and last hit occurred (in $\mu$s).
 \item{\bf det\_x[det\_n], det\_y[det\_n], det\_z[det\_n]} (array of Double\_t) -- the coordinates of the first step of the given hit.
-%\item{\bf det\_kine[det\_n]} (array of Double\_t) -- should be kinetic energy, but not sure whether it is filled correctly (in MeV).
+\item{\bf det\_kine[det\_n]} (array of Double\_t) -- should be kinetic energy of the first particle contributing 
+	to the hit, but it is not clear how to interpret this variable, so check the
+	code for the exact meaning (in MeV).
 \item{\bf det\_Vrtx*****[det\_n]} -- All the variables starting with ``det\_Vrtx'' refer to the particle with the first (in time) energy deposit
-         belonging to the given hit.  (Note that the hit might be induceed by more than one particle.)  The vertex, at which
+         belonging to the given hit.  (Note that the hit might be induced by more than one particle.)  The vertex, at which
          the particle was created, may or may not be positioned within the sensitive volume, in which the hit is observed.
 \item{\bf det\_VrtxKine[det\_n]} (array of Double\_t) -- the kinetic energy of the first (in time) particle belonging to the hit.
 \item{\bf det\_VrtxX[det\_n], det\_VrtxY[det\_n], det\_VrtxZ[det\_n]}  (array of Double\_t) -- the position of the vertex of
@@ -407,8 +708,8 @@ and therefore no time can be assigned to the sample hit.
 \item{\bf det\_Vvv*****[det\_n]} -- similar to the variables det\_Vrtx*****[det\_n] above, but if the first particle 
 	belonging to the hit was created inside of the logical volume where the hit occurs, then it's track is followed
         to its mother track (even several times) until the track (particle) is found that has been created outside the
-        given volume.  This way one can better investigate which (hopefully) single particle coused the hit.  Even though
+        given volume.  This way one can better investigate which (hopefully) single particle caused the hit.  Even though
-        even in this case it is not guarranteed that only a single particle gave origin to the hit, it is quite likely, though, 
+        even in this case it is not guaranteed that only a single particle gave origin to the hit, it is quite likely, though, 
 	that it was in fact just a single particle.  If the 
 \item{\bf save\_n} (Int\_t) -- number of special kind of ``save'' volume that were hit in this event. The ``save volume'' is
 	any volume whose name starts with letters ``save''.  Their purpose in the simulation is usually to check positions
@@ -419,8 +720,9 @@ and therefore no time can be assigned to the sample hit.
 \item{\bf save\_x[save\_n], save\_y[save\_n], save\_z[save\_n]} (array of Double\_t) -- position of the particle where it
         entered the save volume (``GetPreStepPoint()'') (in mm).
 \item{\bf save\_px[save\_n], save\_py[save\_n], save\_pz[save\_n]} (array of Double\_t) -- momentum of the particle when it
-        entered the save volume (in GeV). 
+        entered the save volume (in MeV/c). 
-
+\item{\bf save\_ke[save\_n]} (array of Double\_t) -- kinetic energy of the particle when it
+        entered the save volume (in MeV). 
 \end{description}
 \clearpage
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

doc/run

@@ -0,0 +1,3 @@
+latex musrSim.tex
+dvips -o musrSim.ps musrSim.dvi
+dvipdf musrSim.dvi

src/musrDetectorConstruction.cc

@@ -25,6 +25,7 @@
 #include "G4Tubs.hh"
 #include "G4Sphere.hh"
 #include "G4Trd.hh"
+#include "G4Para.hh"
 #include "G4PVDivision.hh"
 #include "G4UserLimits.hh"
 
@@ -185,6 +186,13 @@ G4VPhysicalVolume* musrDetectorConstruction::Construct()  {
 	  solidName+=name;
 	  solid = new G4Sphere(solidName,x1*mm,x2*mm,x3*deg,x4*deg,x5*deg,x6*deg);
 	}
+	else if (strcmp(tmpString2,"para")==0){  // NOT YET TESTED
+	  sscanf(&line[0],"%*s %*s %*s %s %g %g %g %g %g %g %s %g %g %g %s %s",
+		 name,&x1,&x2,&x3,&x4,&x5,&x6,material,&posx,&posy,&posz,mothersName,rotMatrix);
+	  sscanf(&line[0],"%*s %*s %*s %*s %*g %*g %*g %*g %*g %*g %*s %*g %*g %*g %*s %*s %s %d %s",sensitiveDet,&volumeID,actualFieldName);
+	  solidName+=name;
+	  solid = new G4Para(solidName,x1*mm,x2*mm,x3*mm,x4*deg,x5*deg,x6*deg);
+	}
 	else if (strcmp(tmpString2,"uprofile")==0){
 	  // Create a U-profile geometry.  x1, x2, x3 define the outer dimensions of the U-profile (as a box),
 	  //                               x4 is the wall thickness of the U-profile.  The centre of the U-profile
@@ -1151,7 +1159,7 @@ void musrDetectorConstruction::SetColourOfLogicalVolume(G4LogicalVolume* pLogVol
     else if (strcmp(colour,"invisible" )==0) {pLogVol->SetVisAttributes(G4VisAttributes::Invisible);}
 
     else if (strcmp(colour,"blue_style")==0) {pLogVol->SetVisAttributes(G4Colour(0.80,0.83,1));}
-    else if (strcmp(colour,"lightblue")==0) {pLogVol->SetVisAttributes(G4Colour(0,0.5,1));}
+    //    else if (strcmp(colour,"lightblue")==0) {pLogVol->SetVisAttributes(G4Colour(0,0.5,1));}
     else if (strcmp(colour,"darkblue")==0) {pLogVol->SetVisAttributes(G4Colour(0,0.25,0.5));}
     else if (strcmp(colour,"fblue_style")==0) {pLogVol->SetVisAttributes(G4Colour(0.85,.88,0.92));}
     else if (strcmp(colour,"oxsteel")==0) {pLogVol->SetVisAttributes(G4Colour(0.9,0.8,0.75));}

src/musrTabulatedElementField.cc

@@ -209,7 +209,7 @@ musrTabulatedElementField::musrTabulatedElementField( const char* filename, cons
 	  file >> xval >> yval >> zval >> bx >> bz >> permeability;
 	  //	  G4cout<< xval <<" "<< yval <<" "<< zval <<" "<< bx <<" "<< bz <<G4endl;
 	}
-	else if (strcmp(fieldTableType,"2D_OperaXY")==0) {
+	else if ((strcmp(fieldTableType,"2D_OperaXY")==0)||(strcmp(fieldTableType,"2DBOperaXY")==0)) {
 	  file >> xval >> zval >> yval >> bx >> bz >> permeability;
 	}
 	else {