From f4536e5005fdb986d8520b995f8eb45226205ccf Mon Sep 17 00:00:00 2001 From: Thomas Prokscha Date: Thu, 2 Mar 2006 15:58:39 +0000 Subject: [PATCH] Removed backup files *.*~. --- geant4/LEMuSR/doc/About.dox~ | 24 - geant4/LEMuSR/doc/MClasses.dox~ | 27 - geant4/LEMuSR/doc/Useractions.dox~ | 75 -- geant4/LEMuSR/doc/commands.dox~ | 132 ---- geant4/LEMuSR/doc/g4setup.dox~ | 44 -- geant4/LEMuSR/doc/g4setupb.dox~ | 153 ----- geant4/LEMuSR/doc/g4setupc.dox~ | 66 -- geant4/LEMuSR/doc/geometry.dox~ | 396 ----------- geant4/LEMuSR/doc/geometry2.dox~ | 143 ---- geant4/LEMuSR/doc/gui.dox~ | 14 - geant4/LEMuSR/doc/howg4.dox~ | 270 -------- geant4/LEMuSR/doc/introduction.dox~ | 20 - geant4/LEMuSR/doc/lemusetup.dox~ | 72 -- geant4/LEMuSR/doc/lemusr.dox~ | 33 - geant4/LEMuSR/doc/lemusr_dox.cfg~ | 944 -------------------------- geant4/LEMuSR/doc/lemutree.dox~ | 22 - geant4/LEMuSR/doc/mainfile.dox~ | 24 - geant4/LEMuSR/doc/mandatories.dox~ | 26 - geant4/LEMuSR/doc/messenger.dox~ | 22 - geant4/LEMuSR/doc/opt_useraction.dox~ | 46 -- geant4/LEMuSR/doc/pga.dox~ | 18 - geant4/LEMuSR/doc/physicslist.dox~ | 25 - geant4/LEMuSR/doc/runmanager.dox~ | 21 - geant4/LEMuSR/doc/sensidet.dox~ | 9 - geant4/LEMuSR/doc/setup.dox~ | 19 - geant4/LEMuSR/doc/todo.dox~ | 30 - geant4/LEMuSR/doc/trackingaction.dox~ | 0 geant4/LEMuSR/doc/visualisation.dox~ | 18 - geant4/LEMuSR/doc/vocabulary.dox~ | 61 -- geant4/LEMuSR/doc/vocabulary2.dox~ | 45 -- geant4/LEMuSR/doc/web_update.sh~ | 1 - 31 files changed, 2800 deletions(-) delete mode 100644 geant4/LEMuSR/doc/About.dox~ delete mode 100644 geant4/LEMuSR/doc/MClasses.dox~ delete mode 100644 geant4/LEMuSR/doc/Useractions.dox~ delete mode 100644 geant4/LEMuSR/doc/commands.dox~ delete mode 100644 geant4/LEMuSR/doc/g4setup.dox~ delete mode 100644 geant4/LEMuSR/doc/g4setupb.dox~ delete mode 100644 geant4/LEMuSR/doc/g4setupc.dox~ delete mode 100644 geant4/LEMuSR/doc/geometry.dox~ delete mode 100644 geant4/LEMuSR/doc/geometry2.dox~ delete mode 100644 geant4/LEMuSR/doc/gui.dox~ delete mode 100644 geant4/LEMuSR/doc/howg4.dox~ delete mode 100644 geant4/LEMuSR/doc/introduction.dox~ delete mode 100644 geant4/LEMuSR/doc/lemusetup.dox~ delete mode 100644 geant4/LEMuSR/doc/lemusr.dox~ delete mode 100644 geant4/LEMuSR/doc/lemusr_dox.cfg~ delete mode 100644 geant4/LEMuSR/doc/lemutree.dox~ delete mode 100644 geant4/LEMuSR/doc/mainfile.dox~ delete mode 100644 geant4/LEMuSR/doc/mandatories.dox~ delete mode 100644 geant4/LEMuSR/doc/messenger.dox~ delete mode 100644 geant4/LEMuSR/doc/opt_useraction.dox~ delete mode 100644 geant4/LEMuSR/doc/pga.dox~ delete mode 100644 geant4/LEMuSR/doc/physicslist.dox~ delete mode 100644 geant4/LEMuSR/doc/runmanager.dox~ delete mode 100644 geant4/LEMuSR/doc/sensidet.dox~ delete mode 100644 geant4/LEMuSR/doc/setup.dox~ delete mode 100644 geant4/LEMuSR/doc/todo.dox~ delete mode 100644 geant4/LEMuSR/doc/trackingaction.dox~ delete mode 100644 geant4/LEMuSR/doc/visualisation.dox~ delete mode 100644 geant4/LEMuSR/doc/vocabulary.dox~ delete mode 100644 geant4/LEMuSR/doc/vocabulary2.dox~ delete mode 100644 geant4/LEMuSR/doc/web_update.sh~ diff --git a/geant4/LEMuSR/doc/About.dox~ b/geant4/LEMuSR/doc/About.dox~ deleted file mode 100644 index 63fba62..0000000 --- a/geant4/LEMuSR/doc/About.dox~ +++ /dev/null @@ -1,24 +0,0 @@ -/*! @page About About Geant4 - -
- Previous: @ref Intro - Up: @ref Intro - Next: @ref Voc -
- -
- - @section sAbout What is Geant4? - -

-Geant4 is a C++ set of libraries designed for Monte-Carlo simultation. This GEometry ANd Tracking toolkit was developped at CERN initially for high energy physics. It contains a large amount of data about particles, interactions and materials inputed according to the standard model. Nowaday, the package is used in a wide range of applications, from DNA modeling to astrophysics. - -

-In order to build a simple simulation, one just has to define a geometry and choose the interactions to consider. For non trivial experiments like \lemu, one may have to personalize some aspects of the original Geant4 code like physics processes or electromagnetic fields. It is now widely used in all kind of fields from dna modelling to astrophysics. - -

-The simulation can be interactive thanks to a user interface already included in Geant4. The possibilities of geometry visualization, histogramming and code personalization are key elements of Geant4. - -

-
-*/ diff --git a/geant4/LEMuSR/doc/MClasses.dox~ b/geant4/LEMuSR/doc/MClasses.dox~ deleted file mode 100644 index 3b86c9d..0000000 --- a/geant4/LEMuSR/doc/MClasses.dox~ +++ /dev/null @@ -1,27 +0,0 @@ -/*! @page Mandatory LEMuSR Mandatory Classes - -
- Previous: @ref lemusetup - Up: @ref Main - Next: @ref runmgr -
- -

- - - - - - - - - - - - -*/ \ No newline at end of file diff --git a/geant4/LEMuSR/doc/Useractions.dox~ b/geant4/LEMuSR/doc/Useractions.dox~ deleted file mode 100644 index 750376a..0000000 --- a/geant4/LEMuSR/doc/Useractions.dox~ +++ /dev/null @@ -1,75 +0,0 @@ -/*! @page Useraction The User Action Classes - -
- Previous: @ref Mandatory - Up: @ref Main - Next: @ref howg4 -
- -
- -\anchor useraction_intro - - - -\section useractintro Introduction -The user action classes are very useful monitoring features of \gf. Thanks to these classes, it is possible to operate actions at different stages of the simulation. - -The user is completely free in the implementation of the actions to take, and therefore the possibilities offered by this feature are innumerable, from interactivity to histogramming, debugging, visualization or even direct optimization of the simulation parameters etc. - -In the following pages, we describe the use of those classes for the \lemu simulation. - - -\section runaction User Run Action -The user run action class operates actions at the beginning and at the end of each run. In LEMuSRRunAction.cc, one can see that it is only used to initialize and update the visualization manager. - -An interesting thing to notice is that some commands can be sent directly to the user interaction manager without going through the terminal. This can be of special utility when running the simulation in batch mode. - - -\section eventaction User Event Action -The user event action class operates actions at the beginnig and at the end of each event of a given run. Initially used for the hits collection, we left its implementation open. - -The two main classes are BeginOfEventAction and EndOfEventAction. For the implementation refer to the LEMuSREventAction.cc file. - - -\section trackingaction User Tracking Action - -The tracking action class is implemented in the LEMuSRTrackingAction.cc file. The two main methods are PreUserTrackingAction and PostUserTrackingAction. In \lemu simulation, we first used the tracking action to get the gyromagnetic parameters of the tracked particle. They can be accessed by any other class via a pointer to the tracking action instance. - -This is very useful in particular for spin precession calculations. Indeed, \gf do not handle yet different gyromagnetic ratios or precession of neutral particles. The muonium data can be highly biased by this. - -However, this procedure is not very "nice" because the tracking action should remain an optional class i.e. should not be necessary to run the simulation. Now the code uses the G4TrackingManager class from geant4, which is a top executive class together with the G4RunManager, G4EventManager and G4SteppingManager classes. - -Here is a short overview on the hierarchy organisation of thoses classes. - - -\section stackingaction User Stacking Action -The user action class can be implemented to select the tracks to consider or not in order to gain calculation time. One can also use it for statistics or to take actions on the tracks to be simulated. - -\section steppingaction User Stepping Action - -The most important user action class of the \lemu simulation is the stepping action. Five different stepping action classes were implemented: - - -The stepping action has to be set in the LEMuSR.cc file. Only one stepping action can be enabled at once. Therefore, we defined environement variables in order to select under which form the code should be compiled. - -After important modification of the code it is useful to go through all the tests in order to verify that everything still runs correctly. - -In the following, we describe the actions of those different stepping actions. - -*/ - - diff --git a/geant4/LEMuSR/doc/commands.dox~ b/geant4/LEMuSR/doc/commands.dox~ deleted file mode 100644 index 9672443..0000000 --- a/geant4/LEMuSR/doc/commands.dox~ +++ /dev/null @@ -1,132 +0,0 @@ -/*! @page commands Commands - -
- Previous: @ref - Up: @ref - Next: @ref -
- -
- -We present here the most useful commands to run the simulation. Some additional commands can be accessed entering help in the run terminal or on the web. We do not put them here because they are not necessary for the \lemu simulation. - -\section coms_config UI control commands -* - /control/execute macrofile : execute a macro file. The macro files are edited as a list of commands. -* -* - /control/verbose : set the verbose level -* -* - /control/shell : access the shell -* -* - /help : call interactive help with all the commands. - - - -\section coms_run Run control commands -* - /run/beamOn #n : simulate n particles -* -* - /run/verbose : set the verbose level - - -\section coms_det Geometry control commands -\subsection com_Mode Detector Mode -* - /Detector/Mode [cryo/mcp] : -* -* - /Detector/CfoilThickness [\f$ \mu g / cm^{2}\f$] : set the thickness of the carbon foil -* -* - /Detector/MaxStepInField [\f$ mm \f$] : set a cut on the maximal step size in the regions with field. -* -\subsection com_sample Sample Specifications -* - /Detector/Sample/Grid [on/off] : NB! the command is not working because no field map was generated for this case. -* -* - /Detector/Sample/Guards [on/off] : enable or disable the guard rings in sample cryostat -* -* - /Detector/Sample/HolderMaterial [material] : to change the material of the sample holder plate. -* -\subsection com_volt Electric Fields and Voltage Settings -* - /Detector/ElectricField [on/off] : enables fiels at trigger detector or disables all electric fields. -* -In order to set the electric field for the third lense and the conical anode one should enter a voltage value. The fields maps were generated for 1 kV. During the initialization they are scaled according to the entered voltage. -* - /Detector/Voltage/ThirdLens [Third Lens Voltage kV] : Third lens voltage in kilovolt -* -* - /Detector/Voltage/ConicalAnode [RA-Left Voltage [kV]] [RA-Right Voltage [kV]] [Build] : Ring anode voltage in kilovolt. The built variable is 1 or 0 and specifies if the detector is rebuilt after the values are changed or later. -* -* - /Detector/Voltage/Cryo [kV] : Sample voltage in kilovolt -* -\subsection com_mag Magnetic Field -* - /Detector/MagneticField [Gauss] : set the value of the magnetic field -* -\subsection com_vis Visualization Mode -* - /Detector/View [total/half/quarter] : build the detector with half cut or quarter cut. The detector must be built in total view to run the simulation. - - - - -\section coms_pga Particle gun control commands -* - /lemuGun/gunPosition [X [cm]] [Y [cm]] [Z [cm]] : the gun position in centimeters. Note that the origin of the geometry is the mcp detector and the carbon foil is at -113.7cm -* -* - /lemuGun/MomentumDirection [momX ] [momY ] [momZ ] : a unitary vector for the particles momentum direction. -* -* - /lemuGun/particle particle : Particle types: mu+/Mu or other. -* -* - /lemuGun/scan/square [X Y B] : flat distribution of B bins in a rectangle 2X x 2Y. Distances are in centimeters. -* -* - /lemuGun/scan/circular [R N M] : circular distribution with N steps along the radius R and M steps along the \f$ 2\pi\f$ angle. Radius in cemtimeters. -* -* - /lemuGun/gauss : gaussian distribution of x and y. -* -* - /lemuGun/reset : reset the counters for the scan mode. - - - -\section coms_vis Visualization control commands -To start a visualization driver and draw the geometry one may follow the following four step procedure: -* -* -# /vis/scene/create : to create a scene to draw. -* -* -# /vis/open [vis_engine] : to open the visualisation engine vis_engine (recommended OGLIX for x-window or DAWNFILE for *.eps file and DANW *.prim file output). -* -* -# /vis/sceneHandler/attach : to link the scene the the engine. -* -* -# /vis/viewer/flush : to draw the geometry. -*. -* The visualization angles and camera position can be set in many different ways. The command should be accessed entering in the terminal. Among those commands one would find: -* -* - /vis/viewer/set/viewpointThetaPhi \f$ \alpha \ \beta \f$ : set camera angle in deg. -* -* - /vis/viewer/refresh : to redraw the geometry. -* -* - /vis/drawTree : print out the hierarchical tree of the geometry. If a physical volume name is specified, the tree will be printed from the correspondant volume. -* -* - /vis/ASCITree/verbose [level] : set verbose level for the /vis/drawTree command. The verbose level goes from 0 to 15. - - -\section coms_sensidet Sensitive detection control commands -* -* - /hits/list : get the list of the different sensitive detectors available -* -* - /hits/activate [sd_name] : activate the sensitive detector sd_name -* -* - /hits/inactivate [sd_name] : inactivate the sensitive detector sd_name -* -* - /hits/verbose [level] : set the verbose level. - -\section coms_misc Miscanellous control commands - -* -* - /tracking/storeTrajectory 1 : to store the trajectories in order to be able to plot them in the visualisation for example. -* -* - /process/(in)activate [particle_name] : (in)activate the particle particle_name -* -* - /particle/(in)activate [process_name] : (in)activate the process process_name. -* -*. - - - - - -In the help directory, one would find some guidance providing the use of the command with the arguments description: what argument to enter, which unit, which format (string, double, int ...), is the argument ommitable etc.). - -A comprehensive list of all the commands can be found in the annexe @ref annexe_commands. - -*/ diff --git a/geant4/LEMuSR/doc/g4setup.dox~ b/geant4/LEMuSR/doc/g4setup.dox~ deleted file mode 100644 index bc92c05..0000000 --- a/geant4/LEMuSR/doc/g4setup.dox~ +++ /dev/null @@ -1,44 +0,0 @@ -/*! @page g4setup Geant4 Installation - -
- Previous: @ref setup - Up: @ref setup - Next: @ref ssg4setup -
- -
- -@section sg4setup Libraries and Compilation - -The \gf package can be downloaded from the -Geant4 website. Enhanced documentation are available there. A short description of the installation is given in the following sections: -* - First , some additional libraries are needed to compile and run \gf -* - In order to compile Geant4 the user must go through a configuration procedure which should be done very carefully. -*. -Note that the following indications are given for Linux operating system. For windows users, we recommend to refer to -Geant4 website. - - - - - - - - */ diff --git a/geant4/LEMuSR/doc/g4setupb.dox~ b/geant4/LEMuSR/doc/g4setupb.dox~ deleted file mode 100644 index 884977d..0000000 --- a/geant4/LEMuSR/doc/g4setupb.dox~ +++ /dev/null @@ -1,153 +0,0 @@ -/*! @page g4setupb Geant4 Installation - -
- Previous: @ref sg4setup - Up: @ref g4setup - Next: @ref ssg4setup2 -
- -
- -@section ssg4setup Additionnal Libraries - - - -As many environment variables will have to be set, it is better to create a script file which would collect all of them. Let us refer at it as the SetEnv.sh script file. One can also copy the environment variables directly in the bash_profile, but it is more clear to have them separately. Each time one would start a work on the simulation one should first execute the SetEnv.sh script. - - -\anchor lbclhep -

CLHEP: - -

The class libraries for high energy physics can be downloaded from the CLHEP website. The installation is well detailled on the web. For the version we used the installation procedure can be described as follow - - -*-# Download a -clhep-version.tar.gz file. Recommended: http://cern.ch/clhep/clhep-1.9.1.2.tgz because the 2.0.x.x release are not yet perfectly working. -*-# Create a directory CLHEP-VERSION/ and copy the clhep-version.tar.gz file in it. -*-# Untar and unzip the file with 
tar -xzfv clhep-version
-*-# Create a work directory CLHEP out of the source directory, for example /home/user/CLHEP -*-# Go to CLHEP-VERSION/CLHEP directory and execute the following commands: -
-./configure --prefix=/home/user/CLHEP
-
-(Note that files will be installed under /usr/local if you do not - specify a prefix.) -
-make
-
-(Build temporary copies of libraries and executables.) -
-make check
-
-(Run the tests.) -
-make install
-
-(Copy libraries, headers, executables, etc. to relevant - subdirectories under .) -*-# \anchor clheplibs Set environement variable to indicate where the libraries are located, and the reference name of the library. To access the correct values, execute the following -
-cd CLHEP/bin
-./clheplib
-
-add the CLHEP/lib directory to the list of library paths (e.g) -
-export LD_LIBRARY_PATH=:$LD_LIBRARY_PATH:/home/user/CLHEP/lib
-
-and export the name of the library (e.g) -
-export CLHEP_LIB=CLHEP-1.9.1.2
-
-Also set -
-export CLHEP_BASE_DIR=/home/user/CLHEP/
-
-It is recommended to set those variables in the SetEnv.sh file, which would be dedicated to store and set all the environment variables of the simulation. It is important execute it before the compilation of \gf, which needs to have those variables set to run. - -Geant4 can support many visualisation application and the user is free to chose the one which he prefers to use. - -NB: When one has no root privileges, it is better to create a directory "CLHEP" appart the directory "CLHEP-version" where the downloaded file is extracted. The bin and libraries will be then store in the "CLHEP" directory. The same procedure is used below. - -\anchor lbmesa -

MesaGL/OpenGL:

-For the visualisation in three dimensions engine is required. The usual engine is OpenGL and one should check that it is correctly installed on the system. If not, Mesa is a free engine that can be downloaded easily, together with a demos package, at Mesa3D website. The instalation is done as follow - -
    -
  1. Go to the top directory of Mesa and execute the command -
    -make linux-x86
-
    -(or the name of the system configuration) -
    2. -
  2. Update the library environnement variable with the Mesa/lib directory -
    -export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/user/Mesa/lib
-
    -
    3. -
  3. The demos are installed in the Mesa/progs/demos directory, and one can run one of them to test if Mesa is well installed. - -
    4. -
- -\anchor lbvrml -

VRML virtual reality module:

-Geant4 can export the geometry in the virtual reality modeling language (VRML) format. The freewrl VRML viewer can be installed as a web browser plugin or ran in stand alone mode by a script. - -First one should download freetype which is a nice font software used by freewrl. It not present on the computer, download it, untar, create a "/home/user/freetype directory and enter the following commands in the code directory freetype-version: -*- ./configure /home/user/freetype (or /usr/local, or the directory to output the libraries) -*- make -*- make install (for root privilege only, otherwise use the standalone script.) -*. -Then download freewrl and open the INSTALL.HTML file. The installation is done in three steps: -* - Edit vrml.conf and adjust it to the system, in particular the output libraries directory can be set to /home/user/freewrl (for example) and the freetype2 libraries directory might be corrected. Moreover the lines refering to Java application could be commented out. -* - perl Makefile.PL -* - make install -*. -Note that the library libjs.so shall be downloaded if necessary. It can be copied in the freewrl-version/blib/arch/auto/VRML/JS/ directory. -If one does not have the root privileges one can simply use the -runme-standalone script. It is however a bit less efficient. - -A better application is OPEN VRML. -*- ./configure /home/user/OpenVRML -*- make -*- make check -*- make install - - - -\anchor lbdawn -

DAWN:

- Danw is a usefull application, whih allow to generate *.eps files from three dimensional OpenGL pictures. The installation is done easily following the danw tutorial website intructions. The following environment variables should be defined: -
-export G4DAWN_NAMED_PIPE=1
-export G4DAWN_GUI_ALWAYS=1
-export G4DAWN_GUI_ALWAYS=1
-export G4VIS_USE_DAWN=1
-export G4DAWN_NAMED_PIPE=1
-export DAWN_PS_PREVIEWER=/usr/X11R6/bin/gv
-
- -\anchor lbroot -

ROOT:

-For histogramming and generating ntuples or trees, Root is probably the most convenient tool. It also provides a convenient interface and the manipulation and fitting of histograms are some of it's important feaures. An comprehensive documentation is available in the web page. The LEMuSR simulation requires Root to be installed. - - - - -\anchor lbcomment -

Comment:

-The new environement variables can be define in the bash file for example, in order to have them defined by default for any logging. - -

-Those libraries come with many tests and it's is recommended to run some of them before going any further. -< -*/ \ No newline at end of file diff --git a/geant4/LEMuSR/doc/g4setupc.dox~ b/geant4/LEMuSR/doc/g4setupc.dox~ deleted file mode 100644 index b7caef6..0000000 --- a/geant4/LEMuSR/doc/g4setupc.dox~ +++ /dev/null @@ -1,66 +0,0 @@ -/*! @page g4setupc Geant4 Installation - -
- Previous: @ref ssg4setup - Up: @ref g4setup - Next: @ref lemusetup -
- -

- -@section ssg4setup2 Geant4 Compilation - - - - -\anchor g4safe -

Safest way:

-The safest way is to execute the automatic installation by using the configure shell script. One should go to the geant4.version/ directory and first build the libraries. Type -
-./Configure -build
-
-and follow the instructions. Each question must be answered very carefully in order to get a good configurationtip. - -Before going any further, make sure that the @ref clheplibs "CLHEP environment variables" are properly set. Remember that the values of the library directory and name can be obtained by entering ./clheplib in CLHEP/bin. -The environment variables for the visualization drivers shall also be set at this point. -Finally, it is recommended to run the script geant4.version/.config/bin/Linux-g++/env.sh as a confirmation (it should have been ran automatically after the configuration script of the previous command). -Then execute -
-./Configure -install
-
-And compile the source code -
-cd geant4.version/source
-gmake
-
-The \gf code is now ready to use and one can compile an example to check that it runs correctly. - -It is usefull to launch the \gf environment variables script geant4.version/.config/bin/Linux-g++/env.sh via the SetEnv.sh script. - - -\anchor g4manual -

Manual way:

-First, some environement variables must be set (for example): -
-export G4INSTALL=/home/user/geant4.version   
-export G4SYSTEM=Linux-g++ (for example)
-export CLHEP\_BASE\_DIR=/home/user/CLHEP
-
-Then the other variables should be set executing the $G4INSTALL/Configure file. - -

-Changes of the configuration can be done directly, editing the config.sh file which is located in the $G4INSTALL/.config/bin/Linux-g++ directory. -After modification, this executed in order to prepare the compilation. - - -\anchor g4compile -

Compile Geant4:

-The compilation is launched by the command $G4INSTALL/source/gmake. - - - -*/ \ No newline at end of file diff --git a/geant4/LEMuSR/doc/geometry.dox~ b/geant4/LEMuSR/doc/geometry.dox~ deleted file mode 100644 index a2ff02f..0000000 --- a/geant4/LEMuSR/doc/geometry.dox~ +++ /dev/null @@ -1,396 +0,0 @@ -/*! @page geometry The Detector Construction - -
- Previous: @ref runmgr - Up: @ref Mandatory - Next: @ref geometry2 "Description of the geometry " -
- -\section geo_implement Implementation of the geometry -The detector construction class is the virtual class for the geometry definition. To implement a geometry, one has to provide the dimensions, a material, a position and different attributes for each element of the detector. Practicaly, the implementation consists in the definition of three types of volumes, which are organized according to the following hierarchy: -* -# a solid volume: it is the definition of the shape of the volume, for example a cone, a sphere or a cylinder (etc.) together with its dimensions. The solid volume can be the result of a boolean operation (addition, subtraction). -* -# a logical volume: it is a solid volume plus a material and other attributes like -* - a field manager e.g. for applying an electromagnetic field in the volume, -* - the visualization parameters as color, transparency etc. -* - a sensitive detector object for monitoring the analysis of flying through particles, -* - some "user limit" parameters for controling the step size or the minimal energy of particles inside the volume. -* The logical volume is indeed the volume which the simulation manager will be refering to for all logical operations during the run. -* -# a physical volume: it is a logical volume with its final position and orientation (spacial conformal transformation) in a so-called mother logical volume. That means, if we have for example a cylinder of the third lens, its position is defined in relation with the vacuum volume of the third chamber logical volume, which itself is converted into a physical volume by getting a position in the laboratory logical volume. It is then much more easier to handle relative positioning of the different detector elements. One would notice that only the laboratory volume (usually called World) is not given a position because it has no mother volume. Notice that a same logical volume can be used to define different physical volumes, as a same solid volume can be used to define different logical volumes. -*. -The following trsncript illustrates the construction of the scintillators. -\code -void LEMuSRDetectorConstruction::lemuSCINT() -{ - - // solids - SCIS_tube= new G4Tubs("sSCIS",9.0*cm,9.5*cm, 13.0*cm, -45*deg, +90*deg); - SCOS_tube= new G4Tubs("sSCOS",9.6*cm,10.1*cm, 13.0*cm, -45*deg, +90*deg); - - // materials - SC_material= G4Material::GetMaterial("scint"); - - // logical - lv_SCIS= new G4LogicalVolume(SCIS_tube,SC_material,"lv_SCIS",0,0,0); - lv_SCOS= new G4LogicalVolume(SCOS_tube,SC_material,"lv_SCOS",0,0,0); - - // physical - rotation1=G4RotateZ3D(90*deg) ; - rotation2=G4RotateZ3D(180*deg) ; - rotation3=G4RotateZ3D(270*deg) ; - - pv_SCISr = new G4PVPlacement( rotation2,lv_SCIS ,"pv_SCISr",lv_LABO, false, 0 ); - pv_SCOSr = new G4PVPlacement( rotation2,lv_SCOS ,"pv_SCOSr",lv_LABO, false, 0 ); - - -(...) - - pv_SCISt = new G4PVPlacement( rotation1,lv_SCIS ,"pv_SCISt",lv_LABO, false, 0 ); - pv_SCOSt = new G4PVPlacement( rotation1,lv_SCOS ,"pv_SCOSt",lv_LABO, false, 0 ); - - pv_SCISl = new G4PVPlacement( 0 , G4ThreeVector(0 *cm,0 *cm, 0*cm),lv_SCIS ,"pv_SCISl",lv_LABO, false, 0 ); - pv_SCOSl = new G4PVPlacement( 0 , G4ThreeVector(0 *cm,0 *cm, 0*cm),lv_SCOS ,"pv_SCOSl",lv_LABO, false, 0 ); - - pv_SCISb = new G4PVPlacement( rotation3,lv_SCIS ,"pv_SCISb",lv_LABO, false, 0 ); - pv_SCOSb = new G4PVPlacement( rotation3,lv_SCOS ,"pv_SCOSb",lv_LABO, false, 0 ); - -(...) - - // vis attributes - lv_SCIS->SetVisAttributes(SCINT_style); - lv_SCOS->SetVisAttributes(dSCINT_style); -} -\endcode - -Different types of interfaces has been implemented for the geometry definition, as for example an XML interface. Further development of \gf will include CAD/\gf geometry conversion. - -The code fo the detector construction was separate in three different files: -* - LEMuSRDetectorConstruction.cc, which concerns all the geometry definition -* - LEMuSRMaterials.cc, which contains the definition of the materials and the attributes -* - LEMuSRdummydets.cc, which was used to draw dummy vacuum planes in the detector in order to get informations on particles at precise points. This file should be deleted in the future because one can simply use a limit on the step size (e.g. 1. cm) and use the stepping action to collect data at the end of each step. -*. -The advantage of writting the code in separate files is simply a gain of compilation time when a modification is done in one of the files. - - - -\section geo_material The materials definition -The definition of the materials and elements is a powerful feature of \gf. It is possible to define all kind of elements and materials with specific parameter. The code for the material definition can be found in the LEMuSRMaterials.cc file, which is no more than an extension of the LEMuSRDetectorConstructor.cc file. - -The user can define elements giving a name, a symbol, an atomic number and an atomic mass. Then the defined elements can be used to define materials. In the following transcript we see how elements are defined: - -\code - -void LEMuSRDetectorConstruction :: MaterialsDefinition () -{ - - - - G4double a; // atomic mass - G4double z; // atomic number - G4double density; // - G4String name, symbol; // - G4int nbelements; // number of elements - G4double fractionmass; // fractionnal mass - for mixtures - - - - // ELEMENTS - - // definition hydrogene - a=1.01*g/mole; - G4Element* H = new G4Element(name="hydrogen", symbol="H", z=1., a); - - // definition boron - a=10.811*g/mole; - G4Element* B = new G4Element(name="boron", symbol="B", z=5., a); - - (...) - -\endcode - Then using those elements it is possible to define material and gases: -\code - // MATERIALS - - // definition : composition de Air - density=1.290*mg/cm3; - G4Material* Air= new G4Material(name="Air", density,nbelements=2); - Air->AddElement (N, fractionmass=0.7);//fractionmass=G4double - Air->AddElement (O, fractionmass=0.3);//fractionmass=G4double - - density= 2.376e-15*g/cm3; - G4double temperature= 300*kelvin; - G4double pressure= 3.0e-9*pascal; - G4Material* vacuum = new G4Material(name="vacuum", density, nbelements=1, - kStateGas,temperature,pressure); - vacuum-> AddMaterial(Air, fractionmass= 1.); - - //definition H2O= - density = 1.000*g/cm3; - G4Material* H2O = new G4Material(name="H2O", density, 2); - H2O->AddElement (H, nbelements=2);//nbelements=G4int - H2O->AddElement (O, nbelements=1);//nbelements=G4int - -(...) - - // definition material 'tungsten' - density =19.250*g/cm3; - G4Material* tungsten = new G4Material("tungsten",density,1); - tungsten->AddElement(W,1); - - - // definition : composition of Graphite - density=2.*g/cm3; - G4Material* graphite= new G4Material(name="graphite",density,1); - graphite->AddElement (C,1); - -(...) -} -\endcode - - Important remark: -* - The MaterialDefinition() method is called in the constructor of the LEMuSRDetectorConstruction class and not in the Contruct() method. The reason is that the materials table should be built only once; whereas the contructor is called only once, the Contruct() method is called at each modification of the detector. - -* - Some dedicated pointers are declared in the @ref mat_def "header file" and instanciated in the method in charge to construct the different parts of the detector. -\cd - //====== MATERIAL DECLARATION ========================= -private: - void MaterialsDefinition(); - //materials - G4Material* SC_material; - G4Material* SAH_material; - G4Material* SAPH_material; - G4Material* Scint_material; - G4Material* DMCP_material; - G4Material* Vacuum ; - G4Material* SSteel ; - G4Material* Copper ; - G4Material* Macor ; - G4Material* Carbon ; -\ec - The instanciation is done calling the GetMaterial() method. The most used elements (stainless steel and vacuum) are instanciated in the lemuDetector() method and the other in their respective methods. - \cd - G4VPhysicalVolume* LEMuSRDetectorConstruction::lemuDetector() // !attention au V dans G4VP... -{ - -(...) - // main materials - - Vacuum = G4Material::GetMaterial("vacuum"); - SSteel = G4Material::GetMaterial("stainless_steel"); - //------------------------------- -(...) -} - - -void LEMuSRDetectorConstruction:: lemuMCPdet() -{ - -(...) - - //materials - - Macor = G4Material::GetMaterial("macor"); - DMCP_material = G4Material::GetMaterial("mcpglass"); - - // logicals volumes - lv_DMCP = new G4LogicalVolume( DMCP_tube , DMCP_material ,"lv_DMCP",0,0,0); - lv_MCPM = new G4LogicalVolume( MCPM_tube , Macor ,"lv_MCVR",0,0,0); - lv_MCPA = new G4LogicalVolume( MCPA_box , SSteel ,"lv_MCPA",0,0,0); - lv_ANVA = new G4LogicalVolume( ANVA_tube , Vacuum ,"lv_ANVA",0,0,0); -(...) -} -\ec -In this transcript we see that the vacuum and the stainless steel are not redefined in the submethods. - - -\section geo_elmag Managing electromagnetic fields -As stated previously, it is possible to assign a field to a logical volume. This is done in four steps: -*-# Creating a field object using a virtual class or a field map -*-# Instanciating a field manager -*-# Providing the field manager with the field, the motion equation and the integrator stepper (Runge-Kutta, Heum...), the minimal step increment etc. -*-# Assigning the field manager to the desired logical volume -*. -Different types of fields are virtually implemented in \gf, as well as the corresponding equations of motion. Anyway, for the \lemu simulation new classes were built in order to handle field maps generated by COMSOL multiphysics finite element solver. -\cd - void LEMuSRDetectorConstruction::lemuLinse3() -{ -(...) - if(elfield==1) - { - - G4ElectricField* L3Field = new LEMuSRElectricField(L3FieldVal, - FieldMapsDir+"/ThirdLense/L3b.map" - ,"dm",-567,60,60,100); - - //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - - L3FieldMgr = new G4FieldManager();//1 - - G4MagIntegratorStepper *pStepper; - G4El_UsualEqRhs *fEquation = new G4El_UsualEqRhs(L3Field); - - pStepper = new G4ClassicalRK4( fEquation, 12 ); - - // equation considers spin or not - G4ChordFinder* pChordFinder = new G4ChordFinder( L3Field, - 1.e-10 * mm, // Minimum step size: must be very small for a precise calculation of transport energy - pStepper); - - L3FieldMgr->SetDetectorField(L3Field); - L3FieldMgr->SetChordFinder(pChordFinder); - - lv_L3VA = new G4LogicalVolume( L3VA_tube , Vacuum ,"lv_L3VA",L3FieldMgr,0,0); - - } -(...) -} -\ec -This transcript shows how to declare the field map of the third lens. The directory of the field maps must be set via the environment variable LEMuSR_FIELDMAPS_DIR. - - -\section geo_sensi Managing the sensitive detection -\gf is well designed for modeling the sensitive detection. It features a virtual class for creating sensitive detectors. These are objects which are linked to a volume and which are called during the particle propagation to take specific actions implemented by the user. For example, the LEMuSRCryoSD class is responsible for monitoring the sensitive detection of particles entering the plates of the sample cryostat. - -*/ -//------------------------------------------------------------ -/*! @page geometry2 The Detector Construction - -
- Previous: @ref geo_implement - Up: @ref Mandatory - Next: @ref physicsref -
-\section geo_list Description of the geometry -The \lemu detector consists of the last part of the spectrometer, from the trigger detector to the sample cryostat. - -The top volume is the laboratory volume (World), which is a cubic air volume (2mx2mx4m). -\image html det2.gif XZ projection view of the detector in the World volume. -* -\section geo_submethod The contruction methods -For clarity reasons, the different parts of the detector are built by different methods. This allows a better control of the geometry and a better modularity. We also had to build different vacuum volumes because it is not possible to assign more than one field per volume. Hence, in LEMuSRDetectorConstruction.cc, on can see that the detector construction method is call other methods to construct different parts of the detector according to the following repartition: - -* \subsection geo_labo Laboratory -*- pv_LABO -* -* - lemuDetector(): constructs the Laboratory and calls the following methods. - -* \subsection geo_trigger Trigger Detector and Chamber -*- pv_Trigger: steel cylinder -*- pv_TriggerV: vacuum -*- pv_TriggerF1: flange -*- pv_TriggerF2: flange -*- pv_CFOIL: carbon foil -*- pv_TriggerB: vacuum region with electric field -*- pv_TriggerB2: vacuum region with electric field -*- pv_TriggerB3: vacuum region with electric field -* -* - lemuTrigger_Detector(): builds the carbon foil, the vacuum volume, the steel cylinder and flanges around it and three vacuum volumes to introduce the electric fields. \image html trigger.gif Trigger detector carbon foil, electric field regions and vacuum chamber. - -* \subsection geo_cgate Compensation Gate Chamber -*- pv_CGateV: vacuum -*- pv_CGate: steel cylinder -*- pv_CGateF1: flange -*- pv_CGateF2: flange -* -* - lemuCGate(): builds the compensation gate steel tube and the vacuum volume. - -* \subsection geo_l3 Third Lense and Chamber -*- pv_L3VA: vacuum -*- pv_L3ST: steel cylinder -*- pv_L3F1: flange -*- pv_L3F2: flange -*- pv_L3GP1: ground potential tube -*- pv_L3GP2: " -*- pv_L3GP3: " -*- pv_L3GP4: " -*- pv_L3GP5: " -*- pv_L3GP6: " -*- pv_L3GP7: " -*- pv_L3GP8: " -*- pv_L3HP: high potential tube -*- pv_L3HP4: " -*- pv_L3HP5: " -*- pv_L3HP7: " -*- pv_L3HP8: " -* -* - lemuLinse3(): builds the third lens, the vacuum volume and the tube around it. The electric field of the third lens is assigned to the vacuum volume. \im det_L3.gif Third lens and chamber. - -* \subsection geo_mcp2 MCP2 and Gate Valve Chambers -*- pv_MCPV: vacuum volume of the MCP2 chamber -*- pv_MCPS: steel cylinder of MCP2 chamber -*- pv_F100: end of the cylinder -*- pv_F160: flange -*- pv_F200: flange -*- pv_GATV: additional vacuum volume in gate valve chamber (indeed, the radii of the gate valve and the mcp chambers are different) -*- pv_GATS: steel cylinder for the gate valve chamber -* -* - lemuMCP2(): builds the gate valve tube and flanges, the cryostat chamber and flange and a vacuum volume for the gate valve and the sample cryostat region. Indeed, we have and overlap of the electric fields (ring anode, sample cryostat) and magnetic field (coils) in this region. For this volume we built a class for superimposing electric fields and a class for combining electric and magnetic fields. - -* \subsection geo_ringanode RING ANODE -*- pv_RA_E: left front conical part -*- pv_RA_M: left rear conical part -*- pv_RA_E2: right front conical part -*- pv_RA_M2: right rear conical part -*- pv_RA_G: cylinder part -* -* - lemuANODE(): builds the ring anode.\im det_mcpv.gif MCP2 and Gate Valve chamber, Ring Anode and MCP detector. - -* \subsection geo_scint Inner and Outer Scintillators -*- pv_SCISt: inner top scintillator -*- pv_SCISb: inner bottom scintillator -*- pv_SCISr: inner right scintillator -*- pv_SCISl: inner left scintillator -*- pv_SCOSt: outer top scintillator -*- pv_SCOSb: outer bottom scintillator -*- pv_SCOSr: ouer right scintillator -*- pv_SCOSl: outer left scintillator -* -* - lemuSCINT(): builds the inner and outer scintillators. - -* \subsection geo_mcpdet MCP2 Detector -*- pv_DMPC: glass -*- pv_MCPA: steel -*- pv_MCPM: macor -*- pv_MCPM2: macor -*- pv_ANVA: vacuum -*- pv_MCSR: vacuum -*- pv_MCSR: steel -*- pv_MCVR: vacuum -*- pv_MCSS: steel -* -* - lemuMCPdet(): builds the MCP2 detector. \im det_mcp_scint.gif MCP2 detector and scintillators. - -* \subsection geo_cryo CRYOSTAT -*- pv_SAH1: sample holder 1 -*- pv_SAH2: sample holder 2 -*- pv_SAH3: sample holder 3 (not used) -*- pv_SAPH: sapphire plate -*- pv_COFI: cold finger tube -*- pv_CRY1: cryostat -*- pv_CRY2: cryostat -*- pv_CRY3: cryostat -*- pv_CRY4: cryostat -*- pv_CRSH: He shield -*- pv_CRSH2: front shield -*- pv_Guard1: guard -*- pv_Guard2: guard -* -* - lemuCryo(): builds the sample cryostat. \im det_cryo.gif Sample Cryostat. -*. - -* \subsection geo_emf Electromagnetic Fields -The electromagnetic fields of the trigger and the third lense are build in their respective contruction methods. For the MCP2 region, the field is build by the method BuildAnodeField(), which will construct the electromagnetic field according to the user settings. In this region, it is possible to enable or disable the magnetic field, the electric field at the sample and the electric field of the ring anode. Two special classes, LEMuSRElFieldMix and LEMuSRElMagField, were specialy implemented in order to handle the superposition of two electric fields for the first one, and the superposition of an electric field and a magnetic field for the second one. - - -\subsection geo_printlist Printing the Volumes List -The list of all the volumes and their densities and masses can be printed during the simulation by entering the commands -* -* vis/ASCIITree/verbose x to set the level of details (\f$ 0 < x < 15 \f$ ) -* -* vis/drawTree -* - - - - - -*/ \ No newline at end of file diff --git a/geant4/LEMuSR/doc/geometry2.dox~ b/geant4/LEMuSR/doc/geometry2.dox~ deleted file mode 100644 index 8d18c5f..0000000 --- a/geant4/LEMuSR/doc/geometry2.dox~ +++ /dev/null @@ -1,143 +0,0 @@ -//------------------------------------------------------------ -/*! @page geometry The Detector Construction - -
- Previous: @ref geo_implement - Up: @ref Mandatory - Next: @ref physicsref -
-\section geo_list Description of the geometry -The \lemu detector consists of the last part of the spectrometer, from the trigger detector to the sample cryostat. - -The top volume is the laboratory volume (World), which is a cubic air volume (2mx2mx4m). -\image html det2.gif XZ projection view of the detector in the World volume. -* -\subsection geo_submethod The contruction methods -For clarity reasons, the different parts of the detector are built by different methods. This allows a better control of the geometry and a better modularity. We also had to build different vacuum volumes because it is not possible to assign more than one field per volume. Hence, in LEMuSRDetectorConstruction.cc, on can see that the detector construction method is call other methods to construct different parts of the detector according to the following repartition: -* - lemuTrigger_Detector(): builds the carbon foil, the vacuum volume, the steel cylinder and flanges around it and three vacuum volumes to introduce the electric fields. \image html trigger.gif Trigger detector carbon foil, electric field regions and vacuum chamber. -* - lemuCGate(): builds the compensation gate steel tube and the vacuum volume. -* - lemuLinse3(): builds the third lens, the vacuum volume and the tube around it. The electric field of the third lens is assigned to the vacuum volume. \im det_L3.gif Third lens and chamber. -* - lemuMCP2(): builds the gate valve tube and flanges, the cryostat chamber and flange and a vacuum volume for the gate valve and the sample cryostat region. Indeed, we have and overlap of the electric fields (ring anode, sample cryostat) and magnetic field (coils) in this region. For this volume we built a class for superimposing electric fields and a class for combining electric and magnetic fields. -* - lemuANODE(): builds the ring anode.\im det_mcpv.gif Cryostat chamber and Gate Valve chamber. -* - lemuSCINT(): builds the inner and outer scintillators. -* - lemuMCPdet(): builds the MCP2 detector. \im det_mcp_scint.gif MCP2 detector and scintillators. -* - lemuCryo(): builds the sample cryostat. \im det_cryo.gif Sample Cryostat. -*. -The electromagnetic fields of the trigger and the third lense are build in their respective contruction methods. For the MCP2 region, the field is build by the method BuildAnodeField(), which will construct the electromagnetic field according to the user settings. In this region, it is possible to enable or disable the magnetic field, the electric field at the sample and the electric field of the ring anode. Two special classes, LEMuSRElFieldMix and LEMuSRElMagField, were specialy implemented in order to handle the superposition of two electric fields for the first one, and the superposition of an electric field and a magnetic field for the second one. - -\subsection geo_pvolumes List of the geometry elements -Here is a list of the different physical volume and their specifications: -*- pv_LABO -* -* MCP and Gate Valve Chambers -*- pv_MCPV: -*- pv_MCPS: -*- pv_F100: -*- pv_F160: -*- pv_F200: -*- pv_GATV: -*- pv_GATS: -* -* RING ANODE -*- pv_RA_E -*- pv_RA_M -*- pv_RA_G -*- pv_RAV -* -* MCP2 Detector -*- pv_DMPC -*- pv_MCPA -*- pv_MCPM -*- pv_MCPM2 -*- pv_ANVA -*- pv_MCSR -*- pv_MCSR -*- pv_MCVR -*- pv_MCSS -* -* CRYOSTAT -*- pv_SAH1 -*- pv_SAH2 -*- pv_SAH3 -*- pv_SAPH -*- pv_COFI -*- pv_CRY1 -*- pv_CRY2 -*- pv_CRY3 -*- pv_CRY4 -*- pv_CRSH -*- pv_CRSH2 -*- pv_Guard1 -*- pv_Guard2 -* -* Third Lense and Chamber -*- pv_L3VA -*- pv_L3ST -*- pv_L3F1 -*- pv_L3F2 -*- pv_L3GP1 -*- pv_L3GP2 -*- pv_L3GP3 -*- pv_L3GP4 -*- pv_L3GP5 -*- pv_L3GP6 -*- pv_L3GP7 -*- pv_L3GP8 -*- pv_L3HP -*- pv_L3HP4 -*- pv_L3HP5 -*- pv_L3HP7 -*- pv_L3HP8 -* -* Compensation Gate Chamber -*- pv_CGateV -*- pv_CGate -*- pv_CGateF1 -*- pv_CGateF2 -* -*Trigger Detector and Chamber -*- pv_Trigger -*- pv_TriggerV -*- pv_TriggerF1 -*- pv_TriggerF2 -*- pv_CFOIL -*- pv_TriggerB -*- pv_TriggerB2 -*- pv_TriggerB3 -* -* Inner and Outer Scintillators -*- pv_SCISt -*- pv_SCISb -*- pv_SCISr -*- pv_SCISl -*- pv_SCOSt -*- pv_SCOSb -*- pv_SCOSr -*- pv_SCOSl -*. - - - - - - - - -*. -The list of all the volumes and their densities and masses can be accessesd during the simulation by entering the commands -* -* vis/ASCIITree/verbose x to set the level of details (\f$ 0 < x < 15 \f$ ) -* -* vis/drawTree -* - - - - - - - - - - -*/ \ No newline at end of file diff --git a/geant4/LEMuSR/doc/gui.dox~ b/geant4/LEMuSR/doc/gui.dox~ deleted file mode 100644 index 908c3cf..0000000 --- a/geant4/LEMuSR/doc/gui.dox~ +++ /dev/null @@ -1,14 +0,0 @@ -/*! @page gui LEmuSR Tree - -
- Previous: @ref svisualisation - Up: @ref lemutree - Next: @ref setup -
- -
- -@section sgui Geant4 user interface manager -Geant4 interactivity is possible thanks to the user interface manager G4UIManager. It is a powerfull tool that allows the user to change any parameter of the simulation entering commands in a terminal. In addition to the commands included in \gf, one can implement ones own commands by the use of messenger classes. An example of building a messenger class for the detector geometry can be found in @ref messengers . - -*/ diff --git a/geant4/LEMuSR/doc/howg4.dox~ b/geant4/LEMuSR/doc/howg4.dox~ deleted file mode 100644 index 726a8f6..0000000 --- a/geant4/LEMuSR/doc/howg4.dox~ +++ /dev/null @@ -1,270 +0,0 @@ -/*! @page howg4 How Does Geant4 Runs? - -
- Previous: @ref Useraction - Up: @ref Main - Next: @ref howg4 -
- -In this section we describe how Geant4 proceeds to run a simulation, which are the successive classes involved in the process of a run and what is the interplay between them. - -\section how_runmgr The G4RunManager -As written precedently, the main component of the simulation is the \b G4RunManager object which is instanciated at the very beginning of the LEMuSR.cc file. It is the class in charge of the simulation control. - -\cd -//! 1 The run manager construction -G4RunManager* runManager = new G4RunManager; -\ec - -The simulation procedure will be launched when the user invokes the method BeamOn(#NumberOfEvents). - - -\section how_init Initialization of the mandatory and user action classes. -The class G4RunManager features the following important pointers: - -\code -210 protected: -211 G4RunManagerKernel * kernel; -212 G4EventManager * eventManager; -213 -214 G4VUserDetectorConstruction * userDetector; -215 G4VUserPhysicsList * physicsList; -216 G4UserRunAction * userRunAction; -217 G4VUserPrimaryGeneratorAction * userPrimaryGeneratorAction; -218 G4UserEventAction * userEventAction; -219 G4UserStackingAction * userStackingAction; -220 G4UserTrackingAction * userTrackingAction; -221 G4UserSteppingAction * userSteppingAction; -222 -23 private: -224 G4RunMessenger* runMessenger; -\endcode Transcript of G4RunManager.hh - -* - The G4RunManagerKernel is responsible for controlling the state of the simulation at the different stages of the run. It contains the following methods -* - DefineWorldVolume -* - InitializePhysics -* - RunInitialization -* - RunTermination -*. -*which will be called by the run manager successively in this order. -*. -* - @anchor eventManager The G4EventManager is responsible for the control of the current event of the simulation. More details are given later about it. - -* - The G4VUser classes are @ref virtual_classes "virtual classes": this means that they consist in virtual methods which have to be entirely implemented by the user. During the simulation, those methods are called by the simulation managers in order to execute precise operations personalized by the user. - -For example, the geometry initialization method of the kernel will call the userDetector->Construct() method in order to setup the desired geometry. It is now clear that when the user defines his own geometry class he \b must implement the detector description method Construct() with the same name (cf. \ref geometry). - -Now one understands the big advantage of the object oriented language and of the use of @ref virtual_classes "virtual classes" and methods: the \gf package can be regarded as a plug-and-play simulation where the communication with virtual user parameters like the geometry, the physics to take into account or the actions to operate at different stages (plotting, histogramming...) relies on pre-established commands. - - - -After instanciation of the mandatory classes in the LEMuSR.cc file, -\cd - //! 2.1 LEMuSR Initialization classes - LEMuSRDetectorConstruction* lemuDetector = new LEMuSRDetectorConstruction(); - - LEMuSRPhysicsList* lemuPhysicsList = new LEMuSRPhysicsList(); - - //! 2.2 LEMuSR Action class - LEMuSRPrimaryGeneratorAction* lemuPGA = new LEMuSRPrimaryGeneratorAction(); -\ec - -the following methods are called: -* - \cd -//! 2.3 Setting the mandatory Initialization classesrunManager->SetUserInitialization(MandatoryDetectorClass); -runManager->SetUserInitialization(MandatoryPhysicsListClass); -//! 2.4 Setting the mandatory Action class -runManager->SetUserAction(MandatoryPrimaryGeneratorActionClass); -\ec -* for the initilization of the mandatory action class and -* - \cd - //! 2.4 Setting the mandatory Action class - runManager ->SetUserAction( lemuPGA ); - - //! 3 The optionnal classes - runManager ->SetUserAction( new LEMuSRRunAction()); - runManager ->SetUserAction( new LEMuSREventAction()); - runManager ->SetUserAction( new LEMuSRTrackingAction()); - (...) - runManager ->SetUserAction( new LEMuSRSteppingAction()); -\ec -* for the initialization of the action classes. - - -When those methods are called, the run manager assigns its pointers to the classes defined by the user. - -\cd -255 inline void SetUserInitialization(G4VUserDetectorConstruction* userInit) -256 { userDetector = userInit; } -257 inline void SetUserInitialization(G4VUserPhysicsList* userInit) -258 { -259 physicsList = userInit; -260 kernel->SetPhysics(userInit); -261 } - (...) -276 inline void SetUserAction(G4UserTrackingAction* userAction) -277 { -278 eventManager->SetUserAction(userAction); -279 userTrackingAction = userAction; -280 } -\ec - -In this transcript one sees that the pointers to the users classes are also given to the other classes like the G4RunManagerKernel (initialization classes) or the G4EventManager (action classes). - - -\section how_rminit Initialization of the Run Manager - -The run manager is initialized in the main() by calling the Initialize() method - \cd - //! 5 Initialize G4 kernel - runManager -> Initialize(); - \ec - - The role of this method is to initialize the detector and the physics list -\cd -298 void G4RunManager::Initialize() -299 { - (...) -309 if(!geometryInitialized) InitializeGeometry(); -310 if(!physicsInitialized) InitializePhysics(); -311 initializedAtLeastOnce = true; -312 } -313 -314 void G4RunManager::InitializeGeometry() -315 { -316 if(!userDetector) -317 { -318 G4Exception -319 ("G4RunManager::InitializeGeometry - G4VUserDetectorConstruction is not defined."); -320 } -321 -322 if(verboseLevel>1) G4cout << "userDetector->Construct() start." << G4endl; -323 kernel->DefineWorldVolume(userDetector->Construct(),false); -324 geometryInitialized = true; -325 } -326 -327 void G4RunManager::InitializePhysics() -328 { -329 if(physicsList) -330 { -331 if(verboseLevel>1) G4cout << "physicsList->Construct() start." << G4endl; -332 kernel->InitializePhysics(); -333 } -334 else -335 { -336 G4Exception("G4VUserPhysicsList is not defined"); -337 } -338 physicsInitialized = true; -339 } -340 -\ec -what is done by calling the Construct() methods via the kernel initialization methods. - -Once this initialization is complete, the simulation is ready to be launched by calling the beamOn() method. - - -\anchor beamOn -\section how_beamon beamOn() - -The beamOn() method is called by tue user in the terminal. Once called, this method will start the simulation procedure, generating as many events as given in argument. If the user gives no argument, only one event will be generated. - -\cd -122 void G4RunManager::BeamOn(G4int n_event,const char* macroFile,G4int n_select) -123 { -124 G4bool cond = ConfirmBeamOnCondition(); -125 if(cond) -126 { -127 numberOfEventToBeProcessed = n_event; -128 RunInitialization(); -129 if(n_event>0) DoEventLoop(n_event,macroFile,n_select); -130 RunTermination(); -131 } -\ec - -The beamOn() method invokes tree important methods of the run manager: -* -# First, the RunInitialization() method for the run preparation: -* -# The kernel run initialization method is called: it will confirm the correct definition of the geometry, physics etc. and create a G4StateManager object, which is responsible for handling and updating the running state of the Geant4 application during its different phases. -* -# A new G4Run object is instanciated. -* -# If a \b user \b run \b action class is defined, the G4run object is created by calling the G4UserRunAction::GenerateRun() method and the G4UserRunAction::BeginOfRunAction() method is called to take user actions at the beginning of the run (cf. \ref runaction ). -\cd -166 void G4RunManager::RunInitialization() -167 { -168 if(!(kernel->RunInitialization())) return; - // Check if user classes are initialized - (...) -171 if(userRunAction) currentRun = userRunAction->GenerateRun(); -172 if(!currentRun) currentRun = new G4Run(); - // Create new G4Run object -182 if(userRunAction) userRunAction->BeginOfRunAction(currentRun); - // Perform the user's actions for the beginning of the run - (...) -197 if(verboseLevel>0) G4cout << "Start Run processing." << G4endl; -198 } -\ec -In the case of the \lemu simulation the LEMuSRRunAction::BeginOfRunAction() method is used to initialize the user interface terminal. -* -# Second, the DoEventLoop() method is called to simulate as many event as wanted. The event loop is described in the next section. -* -# Finally, the RunTermination() method is called and simply consists in the execution of the RunTermination() from the kernel, and makes the simulation ready for a new run. -\cd -303 void G4RunManagerKernel::RunTermination() -304 { G4StateManager::GetStateManager()->SetNewState(G4State_Idle); } -\ec - - - - -\section how_evtloop The Event Loop - -The following transcript shows how an event loop is organised. The loop iteration number (the number of events to simulate) is provided by the user. -\cd -200 void G4RunManager::DoEventLoop(G4int n_event,const char* macroFile,G4int n_select) -201 { - (...) -215 // Event loop -216 G4int i_event; -217 for( i_event=0; i_eventProcessOneEvent(currentEvent); -221 AnalyzeEvent(currentEvent); -222 if(i_eventApplyCommand(msg); -223 StackPreviousEvent(currentEvent); -224 currentEvent = 0; -225 if(runAborted) break; -226 } - (...) -239 } -\ec - -Once the event is generated by calling the GeneratePrimaries() method of the user primary generator action (cf. LEMuSRPrimaryGeneratorAction), the \ref eventManager will simulate one event, propagating a particle through the described detector and making it interact according to the defined interaction and processes. - - -\subsection how_processevent ProcessOneEvent() - -The G4EventManager::ProcessOneEvent() method prepare the G4EventManager::DoProcessing() method, which is actually responsible for the event simulation. The procedure is the following: -* -# Initialization of the state of the run via the G4StateManager -* -# Instanciation of the navigator object. * It is the class responsible for the calculation of time and distances during the navigation of the particle in the different volumes of the geometry. The navigator object is created by the G4TransportationManager, itself created at the very beginning of the simulation, before the main() method is called. -* -# Initialization of the sensitive detector manager. -* -# Initialization of the track container, which is an object of the G4StackManager class. It stores the initial track and its secondaries until they are all simulated. The UserStackingAction can be used to segregate the secondary particles tracks to stack or not. -* -# Stack tracks from the pimary event. This is done by calling the GimmePrimaries() method from the G4PrimaryTransformer class. This class performs the conversion of the primary particle object generated by the primary generator action into a dynamic particle, which is the particle object for the tracking. -* -# Do the following loop while the track container is not empty: -* -# Creation of a track pointer. -* -# Execution of the User Event Actions. -* -# Loop the folowing for each track in the container: -* -# Assing the current track to the created track pointer -* -# Call of the G4TrackingManager::ProcessOneTrack() method to simulate the track -* -# Collect the track trajectory and stack (under conditions) the secondary tracks in the container -* -# Call the termination of the sensitive detector manager. -* -# Initialization of the state manager for a new run. -*. - -\subsection how_processtrack ProcessOneTrack() -Let us now decribe the next step in the simulation hierarchy, which is the simulation of a track. This is done by calling the ProcessOneTrack() method which is a member of the G4TrackingManager. - -After initialization of the new track taken from the stack manager, the Stepping Manager is called to set the initial step of the track. The Pre User Tracking Actions are taken and the step by step tracking is performed until the particle stops or dies. This is done by calling the G4SteppingManager::Stepping() method. - -At each step, the user actions are taken before and after the step, and the process is selected according to cross section and priority given by the user. The Sensitive Detectors are also called at the step stage of the simulation. - - - - -*/ \ No newline at end of file diff --git a/geant4/LEMuSR/doc/introduction.dox~ b/geant4/LEMuSR/doc/introduction.dox~ deleted file mode 100644 index 403578b..0000000 --- a/geant4/LEMuSR/doc/introduction.dox~ +++ /dev/null @@ -1,20 +0,0 @@ -/*! @page Intro Introduction - -
- Previous: @ref Main - Up: @ref Main - Next: @ref sAbout -
- -
- - - - -
    -
  • @ref sAbout -
  • @ref Voc -
  • @ref slemutree - - -*/ \ No newline at end of file diff --git a/geant4/LEMuSR/doc/lemusetup.dox~ b/geant4/LEMuSR/doc/lemusetup.dox~ deleted file mode 100644 index 1f0e6ff..0000000 --- a/geant4/LEMuSR/doc/lemusetup.dox~ +++ /dev/null @@ -1,72 +0,0 @@ -/*! @page lemusetup LEMuSR Installation - -
    - Previous: @ref ssg4setup2 - Up: @ref setup - Next: @ref Mandatory -
    - -
    - - - -\anchor getlemcode -@section slemusetup Getting the code -To install the \lemu simulation one should download the code from the SVN server and compile it. -The main directories of the simulation are the following: -
      -
    • The Base directory LEMuSR. -
    • The include sub-directory for the header files. -
    • The src sub-directory for the source files. -
    • The FieldMaps sub-directory for the field maps. -
    • The MACROS directory which contains useful macro files. -
    - -\anchor modify -@section slemusetupb Modifications of Geant4 code - -The source code of Geant4 had to be optimized for the LEMuSR simulation. The following list reports all modifictations of Geant4 which are required by the simulation. It's important to copy those files frome the directory G4MODIFIED to their respective Geant4 directories. -
    -
    -
    G4ParticleDefinition: this library collects all the parameters needed to define a particle, like the mass, the charge, the spin etc. We modified the original version because it did not include the definition of the gyromagnetic ratio of the particles. Those one are needed when we want to compare the asymmetry spectra of muon and muonium for example. - -

    -Directory: particle/management -

    -
    -
    G4Muonium: is the class for muonium particle, which do not come directly with the original code. - -

    -Directory: particle/leptons -

    -
    -
    G4FieldManager: when a new field is created, we have to assign it to a given volume. This is done via the field manager, which stores the pointer to the field. For example, the electric field of the third lense will be assigned to the vacuum surounding the third lense. Each volume containing a field has a field manager. - -

    -During the transport of a particle, the field manager will be in charge of returning the pointer to the field and other parameter which the user can specify, like the minimal step size in the volume. We modified this class to be able to handle pointers for different types of field and added a boolean variable to set whereas the considered field has a magnetic component or not (mainly for spin precession). - -

    -Directory: geometry/magneticfield -

    -
    -
    G4El_UsualEqRhs and G4El_MagEqRhs: thoses classes define the motion equations in electric field and electromagnetic field. - -

    -Directory: geometry/magneticfield -

    -
    -
    G4MultipleScattering52: contains the parameters for the multiple scattering process. It was modified to be linked to the low energy muons scattering class implemented according to Meyer's algorithm. - -

    -Directory: processes/electromagnetic/standard/ -

    -
    -After copying those classes in the indicated directories, it is recommanded to recompile the whole geant4 code. - - - - -*/ \ No newline at end of file diff --git a/geant4/LEMuSR/doc/lemusr.dox~ b/geant4/LEMuSR/doc/lemusr.dox~ deleted file mode 100644 index b7cc24e..0000000 --- a/geant4/LEMuSR/doc/lemusr.dox~ +++ /dev/null @@ -1,33 +0,0 @@ -/*-------------------------------------------------------------- - - name: lemusr.dox - created by: Taofiq Paraiso, 12.21.2005 - - contents: This is the main page documentation file used to - generate the documentation for LEmuSR simulation - ----------------------------------------------------------------*/ - - - -/*! @mainpage Documentation of the \lemu Simulation - -\anchor Main - The aim of this documentation is to provide comprehensive information on the installation and the utilisation of the \lemu simulation. - - This simulation was built using the Geant4 toolkit for Monte-Carlo simulations. - - We first explain how to install Geant4 and the \lemu simulation. Then we describe the main components of the code and finally explain how to run a simulation using different user interaction commands. - - - Chapters are: - \arg @ref Intro - \arg @ref setup - \arg @ref Mandatory - \arg @ref Useraction - \arg @ref howg4 - -@ref todo "To Do List." - - -*/ diff --git a/geant4/LEMuSR/doc/lemusr_dox.cfg~ b/geant4/LEMuSR/doc/lemusr_dox.cfg~ deleted file mode 100644 index a65ab86..0000000 --- a/geant4/LEMuSR/doc/lemusr_dox.cfg~ +++ /dev/null @@ -1,944 +0,0 @@ -# Doxyfile 1.2.14 - -# This file describes the settings to be used by the documentation system -# doxygen (www.doxygen.org) for a project -# -# All text after a hash (#) is considered a comment and will be ignored -# The format is: -# TAG = value [value, ...] -# For lists items can also be appended using: -# TAG += value [value, ...] -# Values that contain spaces should be placed between quotes (" ") - -#--------------------------------------------------------------------------- -# General configuration options -#--------------------------------------------------------------------------- - -# The PROJECT_NAME tag is a single word (or a sequence of words surrounded -# by quotes) that should identify the project. - -PROJECT_NAME = "Geant4 Simulation for LEmuSR Experiment" - -# The PROJECT_NUMBER tag can be used to enter a project or revision number. -# This could be handy for archiving the generated documentation or -# if some version control system is used. - -PROJECT_NUMBER = 1.0 - -# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) -# base path where the generated documentation will be put. -# If a relative path is entered, it will be relative to the location -# where doxygen was started. If left blank the current directory will be used. - -OUTPUT_DIRECTORY = $(HOME)/Documentation/lemusr - -# The OUTPUT_LANGUAGE tag is used to specify the language in which all -# documentation generated by doxygen is written. Doxygen will use this -# information to generate all constant output in the proper language. -# The default language is English, other supported languages are: -# Brazilian, Chinese, Croatian, Czech, Danish, Dutch, Finnish, French, -# German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, -# Portuguese, Romanian, Russian, Slovak, Slovene, Spanish and Swedish. - -OUTPUT_LANGUAGE = English - -# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in -# documentation are documented, even if no documentation was available. -# Private class members and static file members will be hidden unless -# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES - -EXTRACT_ALL = YES - -# If the EXTRACT_PRIVATE tag is set to YES all private members of a class -# will be included in the documentation. - -EXTRACT_PRIVATE = YES - -# If the EXTRACT_STATIC tag is set to YES all static members of a file -# will be included in the documentation. - -EXTRACT_STATIC = YES - -# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) -# defined locally in source files will be included in the documentation. -# If set to NO only classes defined in header files are included. - -EXTRACT_LOCAL_CLASSES = YES - -# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all -# undocumented members of documented classes, files or namespaces. -# If set to NO (the default) these members will be included in the -# various overviews, but no documentation section is generated. -# This option has no effect if EXTRACT_ALL is enabled. - -HIDE_UNDOC_MEMBERS = NO - -# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all -# undocumented classes that are normally visible in the class hierarchy. -# If set to NO (the default) these class will be included in the various -# overviews. This option has no effect if EXTRACT_ALL is enabled. - -HIDE_UNDOC_CLASSES = NO - -# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will -# include brief member descriptions after the members that are listed in -# the file and class documentation (similar to JavaDoc). -# Set to NO to disable this. - -BRIEF_MEMBER_DESC = YES - -# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend -# the brief description of a member or function before the detailed description. -# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the -# brief descriptions will be completely suppressed. - -REPEAT_BRIEF = YES - -# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then -# Doxygen will generate a detailed section even if there is only a brief -# description. - -ALWAYS_DETAILED_SEC = YES - -# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all inherited -# members of a class in the documentation of that class as if those members were -# ordinary class members. Constructors, destructors and assignment operators of -# the base classes will not be shown. - -INLINE_INHERITED_MEMB = NO - -# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full -# path before files name in the file list and in the header files. If set -# to NO the shortest path that makes the file name unique will be used. - -FULL_PATH_NAMES = NO - -# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag -# can be used to strip a user defined part of the path. Stripping is -# only done if one of the specified strings matches the left-hand part of -# the path. It is allowed to use relative paths in the argument list. - -STRIP_FROM_PATH = - -# The INTERNAL_DOCS tag determines if documentation -# that is typed after a \internal command is included. If the tag is set -# to NO (the default) then the documentation will be excluded. -# Set it to YES to include the internal documentation. - -INTERNAL_DOCS = NO - -# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct -# doxygen to hide any special comment blocks from generated source code -# fragments. Normal C and C++ comments will always remain visible. - -STRIP_CODE_COMMENTS = YES - -# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate -# file names in lower case letters. If set to YES upper case letters are also -# allowed. This is useful if you have classes or files whose names only differ -# in case and if your file system supports case sensitive file names. Windows -# users are adviced to set this option to NO. - -CASE_SENSE_NAMES = YES - -# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter -# (but less readable) file names. This can be useful is your file systems -# doesn't support long names like on DOS, Mac, or CD-ROM. - -SHORT_NAMES = NO - -# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen -# will show members with their full class and namespace scopes in the -# documentation. If set to YES the scope will be hidden. - -HIDE_SCOPE_NAMES = NO - -# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen -# will generate a verbatim copy of the header file for each class for -# which an include is specified. Set to NO to disable this. - -VERBATIM_HEADERS = YES - -# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen -# will put list of the files that are included by a file in the documentation -# of that file. - -SHOW_INCLUDE_FILES = YES - -# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen -# will interpret the first line (until the first dot) of a JavaDoc-style -# comment as the brief description. If set to NO, the JavaDoc -# comments will behave just like the Qt-style comments (thus requiring an -# explict @brief command for a brief description. - -JAVADOC_AUTOBRIEF = NO - -# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented -# member inherits the documentation from any documented member that it -# reimplements. - -INHERIT_DOCS = YES - -# If the INLINE_INFO tag is set to YES (the default) then a tag [inline] -# is inserted in the documentation for inline members. - -INLINE_INFO = YES - -# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen -# will sort the (detailed) documentation of file and class members -# alphabetically by member name. If set to NO the members will appear in -# declaration order. - -SORT_MEMBER_DOCS = YES - -# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC -# tag is set to YES, then doxygen will reuse the documentation of the first -# member in the group (if any) for the other members of the group. By default -# all members of a group must be documented explicitly. - -DISTRIBUTE_GROUP_DOC = NO - -# The TAB_SIZE tag can be used to set the number of spaces in a tab. -# Doxygen uses this value to replace tabs by spaces in code fragments. - -TAB_SIZE = 8 - -# The GENERATE_TODOLIST tag can be used to enable (YES) or -# disable (NO) the todo list. This list is created by putting \todo -# commands in the documentation. - -GENERATE_TODOLIST = YES - -# The GENERATE_TESTLIST tag can be used to enable (YES) or -# disable (NO) the test list. This list is created by putting \test -# commands in the documentation. - -GENERATE_TESTLIST = YES - -# The GENERATE_BUGLIST tag can be used to enable (YES) or -# disable (NO) the bug list. This list is created by putting \bug -# commands in the documentation. - -GENERATE_BUGLIST = YES - -# This tag can be used to specify a number of aliases that acts -# as commands in the documentation. An alias has the form "name=value". -# For example adding "sideeffect=\par Side Effects:\n" will allow you to -# put the command \sideeffect (or @sideeffect) in the documentation, which -# will result in a user defined paragraph with heading "Side Effects:". -# You can put \n's in the value part of an alias to insert newlines. - -ALIASES = "gf=Geant4"\ - "lemu= @htmlonly LEmSR @endhtmlonly @latexonly LE$\mu$SR @endlatexonly"\ - "ct=Constructor."\ - "dt=Destructor."\ - "mm=Main method."\ - "cd=\code"\ - "ec=\endcode"\ - "im=\image html"\ - "cbv=Condition boolean variable. If true, the process will be executed." - - -# The ENABLED_SECTIONS tag can be used to enable conditional -# documentation sections, marked by \if sectionname ... \endif. - -ENABLED_SECTIONS = - -# The MAX_INITIALIZER_LINES tag determines the maximum number of lines -# the initial value of a variable or define consist of for it to appear in -# the documentation. If the initializer consists of more lines than specified -# here it will be hidden. Use a value of 0 to hide initializers completely. -# The appearance of the initializer of individual variables and defines in the -# documentation can be controlled using \showinitializer or \hideinitializer -# command in the documentation regardless of this setting. - -MAX_INITIALIZER_LINES = 30 - -# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources -# only. Doxygen will then generate output that is more tailored for C. -# For instance some of the names that are used will be different. The list -# of all members will be omitted, etc. - -OPTIMIZE_OUTPUT_FOR_C = YES - -# Set the SHOW_USED_FILES tag to NO to disable the list of files generated -# at the bottom of the documentation of classes and structs. If set to YES the -# list will mention the files that were used to generate the documentation. - -SHOW_USED_FILES = YES - -#--------------------------------------------------------------------------- -# configuration options related to warning and progress messages -#--------------------------------------------------------------------------- - -# The QUIET tag can be used to turn on/off the messages that are generated -# by doxygen. Possible values are YES and NO. If left blank NO is used. - -QUIET = NO - -# The WARNINGS tag can be used to turn on/off the warning messages that are -# generated by doxygen. Possible values are YES and NO. If left blank -# NO is used. - -WARNINGS = YES - -# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings -# for undocumented members. If EXTRACT_ALL is set to YES then this flag will -# automatically be disabled. - -WARN_IF_UNDOCUMENTED = YES - -# The WARN_FORMAT tag determines the format of the warning messages that -# doxygen can produce. The string should contain the $file, $line, and $text -# tags, which will be replaced by the file and line number from which the -# warning originated and the warning text. - -WARN_FORMAT = "$file:$line: $text" - -# The WARN_LOGFILE tag can be used to specify a file to which warning -# and error messages should be written. If left blank the output is written -# to stderr. - -WARN_LOGFILE = - -#--------------------------------------------------------------------------- -# configuration options related to the input files -#--------------------------------------------------------------------------- - -# The INPUT tag can be used to specify the files and/or directories that contain -# documented source files. You may enter file names like "myfile.cpp" or -# directories like "/usr/src/myproject". Separate the files or directories -# with spaces. - -INPUT = . \ - ./commands \ - ../ \ - ../src \ - ../include \ - ../YIELDS - -# If the value of the INPUT tag contains directories, you can use the -# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp -# and *.h) to filter out the source-files in the directories. If left -# blank the following patterns are tested: -# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx *.hpp -# *.h++ *.idl *.odl - -FILE_PATTERNS = *.cc \ - *.c \ - *.icc \ - *.h \ - *.hh \ - *.dox - -# The RECURSIVE tag can be used to turn specify whether or not subdirectories -# should be searched for input files as well. Possible values are YES and NO. -# If left blank NO is used. - -RECURSIVE = NO - -# The EXCLUDE tag can be used to specify files and/or directories that should -# excluded from the INPUT source files. This way you can easily exclude a -# subdirectory from a directory tree whose root is specified with the INPUT tag. - -EXCLUDE = - -# The EXCLUDE_SYMLINKS tag can be used select whether or not files or directories -# that are symbolic links (a Unix filesystem feature) are excluded from the input. - -EXCLUDE_SYMLINKS = NO - -# If the value of the INPUT tag contains directories, you can use the -# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude -# certain files from those directories. - -EXCLUDE_PATTERNS = - -# The EXAMPLE_PATH tag can be used to specify one or more files or -# directories that contain example code fragments that are included (see -# the \include command). - -EXAMPLE_PATH = - -# If the value of the EXAMPLE_PATH tag contains directories, you can use the -# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp -# and *.h) to filter out the source-files in the directories. If left -# blank all files are included. - -EXAMPLE_PATTERNS = - -# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be -# searched for input files to be used with the \include or \dontinclude -# commands irrespective of the value of the RECURSIVE tag. -# Possible values are YES and NO. If left blank NO is used. - -EXAMPLE_RECURSIVE = NO - -# The IMAGE_PATH tag can be used to specify one or more files or -# directories that contain image that are included in the documentation (see -# the \image command). - -IMAGE_PATH = ./ \ - ./images \ - ../../images/next.gif \ - ../../images/previous.gif - - -# The INPUT_FILTER tag can be used to specify a program that doxygen should -# invoke to filter for each input file. Doxygen will invoke the filter program -# by executing (via popen()) the command , where -# is the value of the INPUT_FILTER tag, and is the name of an -# input file. Doxygen will then use the output that the filter program writes -# to standard output. - -INPUT_FILTER = - -# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using -# INPUT_FILTER) will be used to filter the input files when producing source -# files to browse. - -FILTER_SOURCE_FILES = NO - -#--------------------------------------------------------------------------- -# configuration options related to source browsing -#--------------------------------------------------------------------------- - -# If the SOURCE_BROWSER tag is set to YES then a list of source files will -# be generated. Documented entities will be cross-referenced with these sources. - -SOURCE_BROWSER = YES - -# Setting the INLINE_SOURCES tag to YES will include the body -# of functions and classes directly in the documentation. - -INLINE_SOURCES = NO - -# If the REFERENCED_BY_RELATION tag is set to YES (the default) -# then for each documented function all documented -# functions referencing it will be listed. - -REFERENCED_BY_RELATION = YES - -# If the REFERENCES_RELATION tag is set to YES (the default) -# then for each documented function all documented entities -# called/used by that function will be listed. - -REFERENCES_RELATION = YES - -#--------------------------------------------------------------------------- -# configuration options related to the alphabetical class index -#--------------------------------------------------------------------------- - -# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index -# of all compounds will be generated. Enable this if the project -# contains a lot of classes, structs, unions or interfaces. - -ALPHABETICAL_INDEX = NO - -# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then -# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns -# in which this list will be split (can be a number in the range [1..20]) - -COLS_IN_ALPHA_INDEX = 5 - -# In case all classes in a project start with a common prefix, all -# classes will be put under the same header in the alphabetical index. -# The IGNORE_PREFIX tag can be used to specify one or more prefixes that -# should be ignored while generating the index headers. - -IGNORE_PREFIX = - -#--------------------------------------------------------------------------- -# configuration options related to the HTML output -#--------------------------------------------------------------------------- - -# If the GENERATE_HTML tag is set to YES (the default) Doxygen will -# generate HTML output. - -GENERATE_HTML = YES - -# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `html' will be used as the default path. - -HTML_OUTPUT = html - -# The HTML_FILE_EXTENSION tag can be used to specify the file extension for -# each generated HTML page (for example: .htm,.php,.asp). If it is left blank -# doxygen will generate files with .html extension. - -HTML_FILE_EXTENSION = .html - -# The HTML_HEADER tag can be used to specify a personal HTML header for -# each generated HTML page. If it is left blank doxygen will generate a -# standard header. - -HTML_HEADER = - -# The HTML_FOOTER tag can be used to specify a personal HTML footer for -# each generated HTML page. If it is left blank doxygen will generate a -# standard footer. - -HTML_FOOTER = - -# The HTML_STYLESHEET tag can be used to specify a user defined cascading -# style sheet that is used by each HTML page. It can be used to -# fine-tune the look of the HTML output. If the tag is left blank doxygen -# will generate a default style sheet - -HTML_STYLESHEET = - -# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, -# files or namespaces will be aligned in HTML using tables. If set to -# NO a bullet list will be used. - -HTML_ALIGN_MEMBERS = YES - -# If the GENERATE_HTMLHELP tag is set to YES, additional index files -# will be generated that can be used as input for tools like the -# Microsoft HTML help workshop to generate a compressed HTML help file (.chm) -# of the generated HTML documentation. - -GENERATE_HTMLHELP = NO - -# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag -# controls if a separate .chi index file is generated (YES) or that -# it should be included in the master .chm file (NO). - -GENERATE_CHI = NO - -# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag -# controls whether a binary table of contents is generated (YES) or a -# normal table of contents (NO) in the .chm file. - -BINARY_TOC = NO - -# The TOC_EXPAND flag can be set to YES to add extra items for group members -# to the contents of the Html help documentation and to the tree view. - -TOC_EXPAND = NO - -# The DISABLE_INDEX tag can be used to turn on/off the condensed index at -# top of each HTML page. The value NO (the default) enables the index and -# the value YES disables it. - -DISABLE_INDEX = NO - -# This tag can be used to set the number of enum values (range [1..20]) -# that doxygen will group on one line in the generated HTML documentation. - -ENUM_VALUES_PER_LINE = 4 - -# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be -# generated containing a tree-like index structure (just like the one that -# is generated for HTML Help). For this to work a browser that supports -# JavaScript and frames is required (for instance Mozilla, Netscape 4.0+, -# or Internet explorer 4.0+). Note that for large projects the tree generation -# can take a very long time. In such cases it is better to disable this feature. -# Windows users are probably better off using the HTML help feature. - -GENERATE_TREEVIEW = NO - -# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be -# used to set the initial width (in pixels) of the frame in which the tree -# is shown. - -TREEVIEW_WIDTH = 250 - -#--------------------------------------------------------------------------- -# configuration options related to the LaTeX output -#--------------------------------------------------------------------------- - -# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will -# generate Latex output. - -GENERATE_LATEX = YES - -# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `latex' will be used as the default path. - -LATEX_OUTPUT = latex - -# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact -# LaTeX documents. This may be useful for small projects and may help to -# save some trees in general. - -COMPACT_LATEX = NO - -# The PAPER_TYPE tag can be used to set the paper type that is used -# by the printer. Possible values are: a4, a4wide, letter, legal and -# executive. If left blank a4wide will be used. - -PAPER_TYPE = a4wide - -# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX -# packages that should be included in the LaTeX output. - -EXTRA_PACKAGES = - -# The LATEX_HEADER tag can be used to specify a personal LaTeX header for -# the generated latex document. The header should contain everything until -# the first chapter. If it is left blank doxygen will generate a -# standard header. Notice: only use this tag if you know what you are doing! - -LATEX_HEADER = - -# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated -# is prepared for conversion to pdf (using ps2pdf). The pdf file will -# contain links (just like the HTML output) instead of page references -# This makes the output suitable for online browsing using a pdf viewer. - -PDF_HYPERLINKS = NO - -# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of -# plain latex in the generated Makefile. Set this option to YES to get a -# higher quality PDF documentation. - -USE_PDFLATEX = NO - -# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode. -# command to the generated LaTeX files. This will instruct LaTeX to keep -# running if errors occur, instead of asking the user for help. -# This option is also used when generating formulas in HTML. - -LATEX_BATCHMODE = NO - -#--------------------------------------------------------------------------- -# configuration options related to the RTF output -#--------------------------------------------------------------------------- - -# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output -# The RTF output is optimised for Word 97 and may not look very pretty with -# other RTF readers or editors. - -GENERATE_RTF = NO - -# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `rtf' will be used as the default path. - -RTF_OUTPUT = rtf - -# If the COMPACT_RTF tag is set to YES Doxygen generates more compact -# RTF documents. This may be useful for small projects and may help to -# save some trees in general. - -COMPACT_RTF = NO - -# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated -# will contain hyperlink fields. The RTF file will -# contain links (just like the HTML output) instead of page references. -# This makes the output suitable for online browsing using WORD or other -# programs which support those fields. -# Note: wordpad (write) and others do not support links. - -RTF_HYPERLINKS = NO - -# Load stylesheet definitions from file. Syntax is similar to doxygen's -# config file, i.e. a series of assigments. You only have to provide -# replacements, missing definitions are set to their default value. - -RTF_STYLESHEET_FILE = - -# Set optional variables used in the generation of an rtf document. -# Syntax is similar to doxygen's config file. - -RTF_EXTENSIONS_FILE = - -#--------------------------------------------------------------------------- -# configuration options related to the man page output -#--------------------------------------------------------------------------- - -# If the GENERATE_MAN tag is set to YES (the default) Doxygen will -# generate man pages - -GENERATE_MAN = NO - -# The MAN_OUTPUT tag is used to specify where the man pages will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `man' will be used as the default path. - -MAN_OUTPUT = man - -# The MAN_EXTENSION tag determines the extension that is added to -# the generated man pages (default is the subroutine's section .3) - -MAN_EXTENSION = .3 - -# If the MAN_LINKS tag is set to YES and Doxygen generates man output, -# then it will generate one additional man file for each entity -# documented in the real man page(s). These additional files -# only source the real man page, but without them the man command -# would be unable to find the correct page. The default is NO. - -MAN_LINKS = NO - -#--------------------------------------------------------------------------- -# configuration options related to the XML output -#--------------------------------------------------------------------------- - -# If the GENERATE_XML tag is set to YES Doxygen will -# generate an XML file that captures the structure of -# the code including all documentation. Note that this -# feature is still experimental and incomplete at the -# moment. - -GENERATE_XML = NO - -#--------------------------------------------------------------------------- -# configuration options for the AutoGen Definitions output -#--------------------------------------------------------------------------- - -# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will -# generate an AutoGen Definitions (see autogen.sf.net) file -# that captures the structure of the code including all -# documentation. Note that this feature is still experimental -# and incomplete at the moment. - -GENERATE_AUTOGEN_DEF = NO - -#--------------------------------------------------------------------------- -# Configuration options related to the preprocessor -#--------------------------------------------------------------------------- - -# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will -# evaluate all C-preprocessor directives found in the sources and include -# files. - -ENABLE_PREPROCESSING = YES - -# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro -# names in the source code. If set to NO (the default) only conditional -# compilation will be performed. Macro expansion can be done in a controlled -# way by setting EXPAND_ONLY_PREDEF to YES. - -MACRO_EXPANSION = NO - -# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES -# then the macro expansion is limited to the macros specified with the -# PREDEFINED and EXPAND_AS_PREDEFINED tags. - -EXPAND_ONLY_PREDEF = NO - -# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files -# in the INCLUDE_PATH (see below) will be search if a #include is found. - -SEARCH_INCLUDES = YES - -# The INCLUDE_PATH tag can be used to specify one or more directories that -# contain include files that are not input files but should be processed by -# the preprocessor. - -INCLUDE_PATH = - -# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard -# patterns (like *.h and *.hpp) to filter out the header-files in the -# directories. If left blank, the patterns specified with FILE_PATTERNS will -# be used. - -INCLUDE_FILE_PATTERNS = - -# The PREDEFINED tag can be used to specify one or more macro names that -# are defined before the preprocessor is started (similar to the -D option of -# gcc). The argument of the tag is a list of macros of the form: name -# or name=definition (no spaces). If the definition and the = are -# omitted =1 is assumed. - -PREDEFINED = DOXYGEN_SHOULD_SKIP_THIS - -# If the MACRO_EXPANSION and EXPAND_PREDEF_ONLY tags are set to YES then -# this tag can be used to specify a list of macro names that should be expanded. -# The macro definition that is found in the sources will be used. -# Use the PREDEFINED tag if you want to use a different macro definition. - -EXPAND_AS_DEFINED = - -# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then -# doxygen's preprocessor will remove all function-like macros that are alone -# on a line and do not end with a semicolon. Such function macros are typically -# used for boiler-plate code, and will confuse the parser if not removed. - -SKIP_FUNCTION_MACROS = YES - -#--------------------------------------------------------------------------- -# Configuration::addtions related to external references -#--------------------------------------------------------------------------- - -# The TAGFILES tag can be used to specify one or more tagfiles. - -TAGFILES = - -# When a file name is specified after GENERATE_TAGFILE, doxygen will create -# a tag file that is based on the input files it reads. - -GENERATE_TAGFILE = - -# If the ALLEXTERNALS tag is set to YES all external classes will be listed -# in the class index. If set to NO only the inherited external classes -# will be listed. - -ALLEXTERNALS = NO - -# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed -# in the modules index. If set to NO, only the current project's groups will -# be listed. - -EXTERNAL_GROUPS = YES - -# The PERL_PATH should be the absolute path and name of the perl script -# interpreter (i.e. the result of `which perl'). - -PERL_PATH = /usr/bin/perl - -#--------------------------------------------------------------------------- -# Configuration options related to the dot tool -#--------------------------------------------------------------------------- - -# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will -# generate a inheritance diagram (in Html, RTF and LaTeX) for classes with base or -# super classes. Setting the tag to NO turns the diagrams off. Note that this -# option is superceded by the HAVE_DOT option below. This is only a fallback. It is -# recommended to install and use dot, since it yield more powerful graphs. - -CLASS_DIAGRAMS = YES - -# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is -# available from the path. This tool is part of Graphviz, a graph visualization -# toolkit from AT&T and Lucent Bell Labs. The other options in this section -# have no effect if this option is set to NO (the default) - -HAVE_DOT = NO - -# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen -# will generate a graph for each documented class showing the direct and -# indirect inheritance relations. Setting this tag to YES will force the -# the CLASS_DIAGRAMS tag to NO. - -CLASS_GRAPH = YES - -# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen -# will generate a graph for each documented class showing the direct and -# indirect implementation dependencies (inheritance, containment, and -# class references variables) of the class with other documented classes. - -COLLABORATION_GRAPH = YES - -# If set to YES, the inheritance and collaboration graphs will show the -# relations between templates and their instances. - -TEMPLATE_RELATIONS = YES - -# If set to YES, the inheritance and collaboration graphs will hide -# inheritance and usage relations if the target is undocumented -# or is not a class. - -HIDE_UNDOC_RELATIONS = YES - -# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT -# tags are set to YES then doxygen will generate a graph for each documented -# file showing the direct and indirect include dependencies of the file with -# other documented files. - -INCLUDE_GRAPH = YES - -# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and -# HAVE_DOT tags are set to YES then doxygen will generate a graph for each -# documented header file showing the documented files that directly or -# indirectly include this file. - -INCLUDED_BY_GRAPH = YES - -# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen -# will graphical hierarchy of all classes instead of a textual one. - -GRAPHICAL_HIERARCHY = YES - -# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images -# generated by dot. Possible values are gif, jpg, and png -# If left blank gif will be used. - -DOT_IMAGE_FORMAT = gif - -# The tag DOT_PATH can be used to specify the path where the dot tool can be -# found. If left blank, it is assumed the dot tool can be found on the path. - -DOT_PATH = - -# The DOTFILE_DIRS tag can be used to specify one or more directories that -# contain dot files that are included in the documentation (see the -# \dotfile command). - -DOTFILE_DIRS = - -# The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width -# (in pixels) of the graphs generated by dot. If a graph becomes larger than -# this value, doxygen will try to truncate the graph, so that it fits within -# the specified constraint. Beware that most browsers cannot cope with very -# large images. - -MAX_DOT_GRAPH_WIDTH = 1024 - -# The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height -# (in pixels) of the graphs generated by dot. If a graph becomes larger than -# this value, doxygen will try to truncate the graph, so that it fits within -# the specified constraint. Beware that most browsers cannot cope with very -# large images. - -MAX_DOT_GRAPH_HEIGHT = 1024 - -# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will -# generate a legend page explaining the meaning of the various boxes and -# arrows in the dot generated graphs. - -GENERATE_LEGEND = YES - -# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will -# remove the intermedate dot files that are used to generate -# the various graphs. - -DOT_CLEANUP = YES - -#--------------------------------------------------------------------------- -# Configuration::addtions related to the search engine -#--------------------------------------------------------------------------- - -# The SEARCHENGINE tag specifies whether or not a search engine should be -# used. If set to NO the values of all tags below this one will be ignored. - -SEARCHENGINE = NO - -# The CGI_NAME tag should be the name of the CGI script that -# starts the search engine (doxysearch) with the correct parameters. -# A script with this name will be generated by doxygen. - -CGI_NAME = search.cgi - -# The CGI_URL tag should be the absolute URL to the directory where the -# cgi binaries are located. See the documentation of your http daemon for -# details. - -CGI_URL = - -# The DOC_URL tag should be the absolute URL to the directory where the -# documentation is located. If left blank the absolute path to the -# documentation, with file:// prepended to it, will be used. - -DOC_URL = - -# The DOC_ABSPATH tag should be the absolute path to the directory where the -# documentation is located. If left blank the directory on the local machine -# will be used. - -DOC_ABSPATH = - -# The BIN_ABSPATH tag must point to the directory where the doxysearch binary -# is installed. - -BIN_ABSPATH = /usr/local/bin/ - -# The EXT_DOC_PATHS tag can be used to specify one or more paths to -# documentation generated for other projects. This allows doxysearch to search -# the documentation for these projects as well. - -EXT_DOC_PATHS = diff --git a/geant4/LEMuSR/doc/lemutree.dox~ b/geant4/LEMuSR/doc/lemutree.dox~ deleted file mode 100644 index 9e23e8f..0000000 --- a/geant4/LEMuSR/doc/lemutree.dox~ +++ /dev/null @@ -1,22 +0,0 @@ -/*! @page lemutree LEmuSR Tree - -
    - Previous: @ref Voc - Up: @ref Intro - Next: @ref smainfile -
    - -
    - -@section slemutree LEmuSR Tree - -
      -
    • @ref smainfile -
    • @ref smandatories -
    • @ref soptact -
    • @ref svisualisation -
    • @ref sgui -
    - - - */ diff --git a/geant4/LEMuSR/doc/mainfile.dox~ b/geant4/LEMuSR/doc/mainfile.dox~ deleted file mode 100644 index 3318a96..0000000 --- a/geant4/LEMuSR/doc/mainfile.dox~ +++ /dev/null @@ -1,24 +0,0 @@ -/*! @page mainfile LEmuSR Tree - -
    - Previous: @ref lemutree - Up: @ref lemutree - Next: @ref smandatories -
    - -
    - -@section smainfile The main file: LEMuSR.cc - - -The main file of the simulation is LEMuSR.cc. It initializes the main classes. -Those are the initialization classes and the action classes. They are hierarchized in two categories: -
      -
    • the mandatory classes, which must be implemented for any simulation. They define the geometry, the physics interactions and the initial state of the particles to simulate. -
    • the optionnal classes, which are not necessary to get a simulation running. They define optionnal parameters for the visualization or the user interaction, but also specific actions the user wants to perform during the simulation, like histogramming or events sorting. -
    - - -The very first component of the simulation is the run manager. It is an object of the class G4RunManager and has to be instanciated at the beginning of the main file. As stated by the name, its role is to manage the simulation. In LEMuSR.cc, the user feeds the run manager with all the different @ref mandatory and @ref optionnal classes. - -*/ diff --git a/geant4/LEMuSR/doc/mandatories.dox~ b/geant4/LEMuSR/doc/mandatories.dox~ deleted file mode 100644 index 0c552cd..0000000 --- a/geant4/LEMuSR/doc/mandatories.dox~ +++ /dev/null @@ -1,26 +0,0 @@ -/*! @page mandatories LEmuSR Tree - -
    - Previous: @ref smainfile - Up: @ref lemutree - Next: @ref soptact -
    - -
    - -\anchor mandatory -@section smandatories The mandatory classes - -The simplest Geant4 simulation requires four so-called mandatory classes. These classes provide the main information about the simulation fundamental parameters, like the detector description or the physical interaction taken in account. They are initialized at the beginning of LEMuSR.cc: - -
      -
    • @ref runmgr : it is the Geant4 mandatory class used to initialize the kernel. -
      • -
    • @ref geometry : mandatory user initialization class for the detector geometry. The geometry is mainly defined in the LEMuSRDetectorConstruction files. -
      • -
    • @ref physicsref : mandatory user initialization class for the physical interactions. The file LEMuSRPhysicsList registers the different particle interaction classes, defined separately, as for example LEMuSRMuonPhysics. -
      • -
    • @ref pga : mandatory user action class for the simulation monitoring. All the initial parameters of the muon beam are described in the file LEMuSRPrimaryGeneratorAction -
      • -
    - */ diff --git a/geant4/LEMuSR/doc/messenger.dox~ b/geant4/LEMuSR/doc/messenger.dox~ deleted file mode 100644 index 78c9ed7..0000000 --- a/geant4/LEMuSR/doc/messenger.dox~ +++ /dev/null @@ -1,22 +0,0 @@ -/*! @page messenger Messengers - -
    - Previous: @ref sVoc - Up: @ref Intro - Next: @ref lemutree -
    - -
    - - @section smessenger Messengers - - -
  • The main file: LEmuSR.cc -
      -
    • @ref mandatories -
    • @ref visualisation -
    • @ref gui -
    • @ref optact -
    • @ref messenger -
    - */ diff --git a/geant4/LEMuSR/doc/opt_useraction.dox~ b/geant4/LEMuSR/doc/opt_useraction.dox~ deleted file mode 100644 index ad07ce8..0000000 --- a/geant4/LEMuSR/doc/opt_useraction.dox~ +++ /dev/null @@ -1,46 +0,0 @@ -/*! @page optact LEmuSR Tree - -
    - Previous: @ref smainfile - Up: @ref lemutree - Next: @ref svisualisation -
    - -
    - -\anchor optionnal - @section soptact Optional user action classes - -The optionnal classes are used for histogramming, visualizing and interacting whith the simulation. - -First of all, the user can implement action classes involved at different levels of the simulation: - -
      -
    • LEMuSRRunAction is in charge of all the processes to perform after each run -
      • -
    • LEMuSREventAction is in charge of all the processes to perform after each event -
      • -
    • LEMuSRTrackingAction is in charge of all the processes to perform after or before each track -
      • -
    • LEMuSRSteppingAction is in charge of all the processes to perform after or before each step -
      • -
    • LEMuSRStackingAction is in charge of segregating the tracks to simulate or not. -
      • -
    - - -In order to perform tests of the simulation, the following alternative stepping action classes were implemented. Note that only one can be enabled at once: - -
      -
    • AsymCheck was implemented to test the asymmetry. -
      • -
    • FieldCheck was implemented to test the electromagnetic fields accuracy. -
      • -
    • TDCheck was implemented to test the trigger detector efficiency. -
      • -
    • FocalLengthTest was implemented to test the focal length of the einzel lens. -
      • -
    - -Finally, the visualisation class LEMuSRVisManager and the user interaction class G4UImanager are usefull and helpfull features to introduce in a simulation. -*/ diff --git a/geant4/LEMuSR/doc/pga.dox~ b/geant4/LEMuSR/doc/pga.dox~ deleted file mode 100644 index 8680348..0000000 --- a/geant4/LEMuSR/doc/pga.dox~ +++ /dev/null @@ -1,18 +0,0 @@ -/*! @page pga The Primary Generator Action - -
    - Previous: @ref physicsref - Up: @ref Mandatory - Next: @ref Useraction -
    - - - * The initial parameters of the particle(s) to simulate are given in the - * LEMuSRPrimaryGeneratorAction class. This mandatory class work in interplay - * with the LEMuSRParticleGun to create each new event of the simulation. - * - * An event is the track of one particle and all the particles created during its - * evolution in the detector, by decay, scattering or any other kind of process. - - -*/ \ No newline at end of file diff --git a/geant4/LEMuSR/doc/physicslist.dox~ b/geant4/LEMuSR/doc/physicslist.dox~ deleted file mode 100644 index 5d5e024..0000000 --- a/geant4/LEMuSR/doc/physicslist.dox~ +++ /dev/null @@ -1,25 +0,0 @@ -/*! @page physicsref The Physics List - -
    - Previous: @ref geometry - Up: @ref Mandatory - Next: @ref pga -
    - -The physics list is the class responsible for the different particles and the interactions to consider during the simulation. If it is possible to declare all the particles and all the physics processes in the physics list, another method consists in building registers for the different types of particles. Those register are then collected in the physics list file LEMuSRPhysicsList.cc, building a so-called modular physics list class. The gain of clarity and precision is the main advantadge of this procedure. - -\gf provides comprehensive libraries about particles and their interactions. They can be accessed in the subdirectories Geant4.version/source/particles and Geant4.version/source/processes. - -Most of the registers used in the \lemu experiment were taken from \gf examples, and only the muon physics was specified: - * - LEMuSREMPhysics: electromagnetic processes. Definition of the electron, positron and their neutrinos, and of the photon #gamma. The processes implemented are the photoelectric effect, the compton effect and the pair production for the gamma, the multiple scattering and bremstrahlung and the ionisation for the electron and positron. The neutrinos are not considered to interact. - * - LEMuSRIonPhysics: considers the common hydrogen-based ions and their scattering processes. This register is not needed for the simulation. - * - LEMuSRHadronPhysics: constructs the mesons and the baryons and their common interactions. - * - LEMuSRGeneralPhysics: is used to apply general processes to the particles, like enabling decay processes or applying user limitations and cuts on energy, step length or track size. - * - LEMuSRMuonPhysics: muon physics. Are constructed the muon plus, the muon minus, the muonium and the neutrinos. -* . -The transportation process is by default attached to the registered particles. - - -\section phys_muprocesses Processes for muonic particles - -*/ \ No newline at end of file diff --git a/geant4/LEMuSR/doc/runmanager.dox~ b/geant4/LEMuSR/doc/runmanager.dox~ deleted file mode 100644 index 3b40c97..0000000 --- a/geant4/LEMuSR/doc/runmanager.dox~ +++ /dev/null @@ -1,21 +0,0 @@ -/*! @page runmgr The Run Manager - -
    - Previous: @ref Mandatory - Up: @ref Mandatory - Next: @ref geometry -
    - -The run manager class in the most important class of the simulation since it is the class responsible for the course of the simulation. -The code of the run manager is described in detail in the section " @ref howg4 ". - -In the main file, the user provides @ref useraction_intro "user action classes" to the run manager. While running the simulation, it is to the run manager that the @ref beamOn "beamOn command" is sent to start the simulation. The run manager will initialize all the user classes and monitor the succession of the different phases of the simulation: -* - beginning of a run -* - simulation of the different events -* - termination of the run -*. -The G4RunManager class works closely to the G4RunManagerKernel class which controls the kernel of \gf. It supervizes the initialization of the user classes, checks if the simulation can be ran and manages the status of the simulation. - - - -*/ \ No newline at end of file diff --git a/geant4/LEMuSR/doc/sensidet.dox~ b/geant4/LEMuSR/doc/sensidet.dox~ deleted file mode 100644 index e7d2495..0000000 --- a/geant4/LEMuSR/doc/sensidet.dox~ +++ /dev/null @@ -1,9 +0,0 @@ -/*! @page Sensidet Sensitive Detection - -
    - Previous: @ref Sensidet - Up: @ref Sensidet - Next: @ref howg4 -
    - -*/ \ No newline at end of file diff --git a/geant4/LEMuSR/doc/setup.dox~ b/geant4/LEMuSR/doc/setup.dox~ deleted file mode 100644 index 01824f1..0000000 --- a/geant4/LEMuSR/doc/setup.dox~ +++ /dev/null @@ -1,19 +0,0 @@ -/*! @page setup Installation - -
    - Previous: @ref Intro - Up: @ref Main - Next: @ref g4setup -
    - -
    - - - - -
      -
    • @ref g4setup -
    • @ref lemusetup - - -*/ \ No newline at end of file diff --git a/geant4/LEMuSR/doc/todo.dox~ b/geant4/LEMuSR/doc/todo.dox~ deleted file mode 100644 index 5288521..0000000 --- a/geant4/LEMuSR/doc/todo.dox~ +++ /dev/null @@ -1,30 +0,0 @@ -/** \anchor todo @page TODO TO-DO LIST - -Questions asked and remarks during the presentation of the \lemu experiment and things to do: - -*- What is the origin (0,0,0) of the geometry? -*- We should add the angular distribution before the foil -*- How to invoke the gauss scan commands? -* - is there really an offset? -* - isn't it possible to use the gunPosition as the center for the gaussian distribution? -*- A comprehensive documentation should be written on the commands -*- Guidelines should be given to understand the output files -* - can we introduce the parameters in the tree? -* - can we build a single output file using the event manager? -* - where to find the things to change? particle.charge etc. -* - how to change the output filename and to make it in clear relation with the run macro file? (run IDs etc. Make it interactive) -* - what is what in the Sensitive detectors files? -*- How to execute the macros? -*- Can we access the run parameters? (implement a command in detector messenger to print the status) -*- What are the modifications that can be done and how to do them -*- What are the output units? -*- How to use the Root macro files? -*- All the parameters must be stored with the run macro file. -*- Implement the magnetic field map. -*- Describe the commands for the voltages -*- Describe the role of the energy offset -* -*- What is the pic at the muon deposition in the sample holder??? -*- Build the detector in the run action not in the messenger - -*/ \ No newline at end of file diff --git a/geant4/LEMuSR/doc/trackingaction.dox~ b/geant4/LEMuSR/doc/trackingaction.dox~ deleted file mode 100644 index e69de29..0000000 diff --git a/geant4/LEMuSR/doc/visualisation.dox~ b/geant4/LEMuSR/doc/visualisation.dox~ deleted file mode 100644 index 9877f86..0000000 --- a/geant4/LEMuSR/doc/visualisation.dox~ +++ /dev/null @@ -1,18 +0,0 @@ -/*! @page visualisation LEmuSR Tree - -
      - Previous: @ref soptact - Up: @ref lemutree - Next: @ref sgui -
      - -
      - -@section svisualisation The visualisation manager -It is possible to have visualization of the simulation. Many devices are available and they have to be set up using the LEMuSRVisManager class, that inherits form the G4VisManager class. - -For example, using the OpenGL system, one can benefit of a real time visualitation of the simulation. Using to DAWNFILE system, one can get snapshots of the simulation into postscript files. Various visualization systems can be loaded simultaneousely. - - - - */ diff --git a/geant4/LEMuSR/doc/vocabulary.dox~ b/geant4/LEMuSR/doc/vocabulary.dox~ deleted file mode 100644 index 08b1181..0000000 --- a/geant4/LEMuSR/doc/vocabulary.dox~ +++ /dev/null @@ -1,61 +0,0 @@ -/*! @page Voc Vocabulary and Notions - -
      - Previous: @ref sAbout - Up: @ref Intro - Next: @ref lemutree -
      - -
      - -@section sVoc Preliminary Vocabulary - -Before going any further, we should familiarize ourselves with some basic vocabulary. In this report we will encounter some words taken from C++ language, and others related to Geant4 architecture. Let us have a brief description of them. - -\subsection cppwords C++ words - -* - Class: a class is the definition of a collection of variables or functions called the members of the class. For example the class Particle has for members: mass, lifetime, charge ...In other words, the class defines a type of variable with parameters that can be specified. - -* - Instance, object: in order to use a class in a program one may create an instance, or object, of it. For example Particle particle1 will create a variable of the type Particle. It is then possible to set all the parameters of the object particle1 and to use it independently in the program. - -* - Inheritance: it is possible to build subclasses. For example, Lepton would be a subclass of Particle class. Instead of building a completely new class, one just has to give Lepton class all the caracteristics of a Particle and add the properties which make a particle a lepton. We say that Lepton class inherits from Particle class. - -* - Virtual method: in the same register as inheritance concept has been created so-called vitual methods. Those are functions declared in the mother class but which is not or only partially implemented. They can be overriden in a subclass. The advantage of those virtual method is that each subclass will have it own implementation of the same base function. Then the name of the function can be used in a general way without having to worry about which subclass we are dealing with. - -A good example is the construction of the detector geometry. The class LEMuSRDetectorConstruction is a subclass G4VUserDetectorConstruction. In order to build the detector, the user has to give geant4 an object of type G4VUserDetectorConstruction. This is done in the main file LEMusR.cc. When initializing the simulation geant4 calls the method G4UserDetectorConstruction::Construct(). This method is virtual but implemented in the LEMuSRDetectorConstruction class and therefore the user's detector geometry will be built. - - - -\subsection g4words Geant4 words -* - Run: this is the word for a the simulation process. - -* - Event: during a run, one can shoot as many particles as needed. An event is the simulation of all the primary particles. Before the run the user specifies the number of primary particles shoot per Event as well as the number of events. - -* - Track: this is the information collection of one particle tracking - -* - Step: step by step, a track is build. At each step the simulation engine is called to decide the process that the particle will suffer, this in accordance to cross-sections or priority orders defined by the user. - - - -@section sVocb Usefull notions of C++ language - -\subsection Header files and source codes files - -Geant4 is a C++ toolkit and one need to write both a header and a source files for each object class. - -The header file contains the declaration of all methods and variables that are specific to the class that is being defined. One also have to specify all the other classes from which his class inherits. Finally, one should indicate if the methods and variables are public (can be seen and get their values modified by other methods) or private (excusive appartenance to the class). Header files are located in the $LEMU/include directory. - -The source file contains the code of each method. These files are located in the $LEMU/source directory. - -\anchor virtual_classes -\subsection The inheritance philosophy - -A base class (a class from which other classes derive) can present so-called virtual methods. That means that these methods can be re-written when defining a daughter class: in C++ language, we say that virtual methods can be overloaded. Virtual methods are the key of Geant4 framework modularity: many of Geant4 classes can be personalized by the user. They are called \b virtual \b classes. - -One only has to build a daughter class of those classes and overload the virtual methods, making sure to keep their name exact because they are called at other places of the framework. It is also possible to add new methods and variables at will. - -For example, the method in charge of building the geometry must be called Construct(), and the messengers methods in charge of modifying parameters must have the name SetNewValue(). - -*/ - - diff --git a/geant4/LEMuSR/doc/vocabulary2.dox~ b/geant4/LEMuSR/doc/vocabulary2.dox~ deleted file mode 100644 index 13e646c..0000000 --- a/geant4/LEMuSR/doc/vocabulary2.dox~ +++ /dev/null @@ -1,45 +0,0 @@ -/*! @page Vocb Vocabulary and Notions - -
      - Previous: @ref sVoc - Up: @ref Intro - Next: @ref lemutree -
      - -
      - -@section sVocb Usefull notions of C++ language - -
        -
      1. Header files and source codes files -
        -
        - -
        - -Geant4 is a C++ toolkit and one need to write both a header and a source files for each object class. - -The header file contains the declaration of all methods and variables that are specific to the class that is being defined. One also have to specify all the other classes from which his class inherits. Finally, one should indicate if the methods and variables are public (can be seen and get their values modified by other methods) or private (excusive appartenance to the class). Header files are located in the $LEMU/include directory. - -The source file contains the code of each method. These files are located in the $LEMU/source directory. -
        -
        -
        - -\anchor virtual_classes -
      2. The inheritance philosophy -
        -
        -
        - -A base class (a class from which other classes derive) can present so-called virtual methods. That means that these methods can be re-written when defining a daughter class: in C++ language, we say that virtual methods can be overloaded. Virtual methods are the key of Geant4 framework modularity: many of Geant4 classes can be personalized by the user. They are called \b virtual \b classes. - -One only has to build a daughter class of those classes and overload the virtual methods, making sure to keep their name exact because they are called at other places of the framework. It is also possible to add new methods and variables at will. - -For example, the method in charge of building the geometry must be called Construct(), and the messengers methods in charge of modifying parameters must have the name SetNewValue(). - -
        -
        3. -
      - -*/ diff --git a/geant4/LEMuSR/doc/web_update.sh~ b/geant4/LEMuSR/doc/web_update.sh~ deleted file mode 100644 index 0a3eed6..0000000 --- a/geant4/LEMuSR/doc/web_update.sh~ +++ /dev/null @@ -1 +0,0 @@ - cp -r ~/Documentation/lemusr/ /afs/psi.ch/project/nemu/www/doc/LEMuSR_Simulation