Import Geant4 11.0.0 source tree
This commit is contained in:
Gabriele Cosmo
Vendored
+139
@@ -0,0 +1,139 @@
|
||||
|
||||
Expat, Release 2.1.0
|
||||
|
||||
This is Expat, a C library for parsing XML, written by James Clark.
|
||||
Expat is a stream-oriented XML parser. This means that you register
|
||||
handlers with the parser before starting the parse. These handlers
|
||||
are called when the parser discovers the associated structures in the
|
||||
document being parsed. A start tag is an example of the kind of
|
||||
structures for which you may register handlers.
|
||||
|
||||
Windows users should use the expat_win32bin package, which includes
|
||||
both precompiled libraries and executables, and source code for
|
||||
developers.
|
||||
|
||||
Expat is free software. You may copy, distribute, and modify it under
|
||||
the terms of the License contained in the file COPYING distributed
|
||||
with this package. This license is the same as the MIT/X Consortium
|
||||
license.
|
||||
|
||||
Versions of Expat that have an odd minor version (the middle number in
|
||||
the release above), are development releases and should be considered
|
||||
as beta software. Releases with even minor version numbers are
|
||||
intended to be production grade software.
|
||||
|
||||
If you are building Expat from a check-out from the CVS repository,
|
||||
you need to run a script that generates the configure script using the
|
||||
GNU autoconf and libtool tools. To do this, you need to have
|
||||
autoconf 2.58 or newer. Run the script like this:
|
||||
|
||||
./buildconf.sh
|
||||
|
||||
Once this has been done, follow the same instructions as for building
|
||||
from a source distribution.
|
||||
|
||||
To build Expat from a source distribution, you first run the
|
||||
configuration shell script in the top level distribution directory:
|
||||
|
||||
./configure
|
||||
|
||||
There are many options which you may provide to configure (which you
|
||||
can discover by running configure with the --help option). But the
|
||||
one of most interest is the one that sets the installation directory.
|
||||
By default, the configure script will set things up to install
|
||||
libexpat into /usr/local/lib, expat.h into /usr/local/include, and
|
||||
xmlwf into /usr/local/bin. If, for example, you'd prefer to install
|
||||
into /home/me/mystuff/lib, /home/me/mystuff/include, and
|
||||
/home/me/mystuff/bin, you can tell configure about that with:
|
||||
|
||||
./configure --prefix=/home/me/mystuff
|
||||
|
||||
Another interesting option is to enable 64-bit integer support for
|
||||
line and column numbers and the over-all byte index:
|
||||
|
||||
./configure CPPFLAGS=-DXML_LARGE_SIZE
|
||||
|
||||
However, such a modification would be a breaking change to the ABI
|
||||
and is therefore not recommended for general use - e.g. as part of
|
||||
a Linux distribution - but rather for builds with special requirements.
|
||||
|
||||
After running the configure script, the "make" command will build
|
||||
things and "make install" will install things into their proper
|
||||
location. Have a look at the "Makefile" to learn about additional
|
||||
"make" options. Note that you need to have write permission into
|
||||
the directories into which things will be installed.
|
||||
|
||||
If you are interested in building Expat to provide document
|
||||
information in UTF-16 encoding rather than the default UTF-8, follow
|
||||
these instructions (after having run "make distclean"):
|
||||
|
||||
1. For UTF-16 output as unsigned short (and version/error
|
||||
strings as char), run:
|
||||
|
||||
./configure CPPFLAGS=-DXML_UNICODE
|
||||
|
||||
For UTF-16 output as wchar_t (incl. version/error strings),
|
||||
run:
|
||||
|
||||
./configure CFLAGS="-g -O2 -fshort-wchar" \
|
||||
CPPFLAGS=-DXML_UNICODE_WCHAR_T
|
||||
|
||||
2. Edit the MakeFile, changing:
|
||||
|
||||
LIBRARY = libexpat.la
|
||||
|
||||
to:
|
||||
|
||||
LIBRARY = libexpatw.la
|
||||
|
||||
(Note the additional "w" in the library name.)
|
||||
|
||||
3. Run "make buildlib" (which builds the library only).
|
||||
Or, to save step 2, run "make buildlib LIBRARY=libexpatw.la".
|
||||
|
||||
4. Run "make installlib" (which installs the library only).
|
||||
Or, if step 2 was omitted, run "make installlib LIBRARY=libexpatw.la".
|
||||
|
||||
Using DESTDIR or INSTALL_ROOT is enabled, with INSTALL_ROOT being the default
|
||||
value for DESTDIR, and the rest of the make file using only DESTDIR.
|
||||
It works as follows:
|
||||
$ make install DESTDIR=/path/to/image
|
||||
overrides the in-makefile set DESTDIR, while both
|
||||
$ INSTALL_ROOT=/path/to/image make install
|
||||
$ make install INSTALL_ROOT=/path/to/image
|
||||
use DESTDIR=$(INSTALL_ROOT), even if DESTDIR eventually is defined in the
|
||||
environment, because variable-setting priority is
|
||||
1) commandline
|
||||
2) in-makefile
|
||||
3) environment
|
||||
|
||||
Note: This only applies to the Expat library itself, building UTF-16 versions
|
||||
of xmlwf and the tests is currently not supported.
|
||||
|
||||
Note for Solaris users: The "ar" command is usually located in
|
||||
"/usr/ccs/bin", which is not in the default PATH. You will need to
|
||||
add this to your path for the "make" command, and probably also switch
|
||||
to GNU make (the "make" found in /usr/ccs/bin does not seem to work
|
||||
properly -- appearantly it does not understand .PHONY directives). If
|
||||
you're using ksh or bash, use this command to build:
|
||||
|
||||
PATH=/usr/ccs/bin:$PATH make
|
||||
|
||||
When using Expat with a project using autoconf for configuration, you
|
||||
can use the probing macro in conftools/expat.m4 to determine how to
|
||||
include Expat. See the comments at the top of that file for more
|
||||
information.
|
||||
|
||||
A reference manual is available in the file doc/reference.html in this
|
||||
distribution.
|
||||
|
||||
The homepage for this project is http://www.libexpat.org/. There
|
||||
are links there to connect you to the bug reports page. If you need
|
||||
to report a bug when you don't have access to a browser, you may also
|
||||
send a bug report by email to expat-bugs@mail.libexpat.org.
|
||||
|
||||
Discussion related to the direction of future expat development takes
|
||||
place on expat-discuss@mail.libexpat.org. Archives of this list and
|
||||
other Expat-related lists may be found at:
|
||||
|
||||
http://mail.libexpat.org/mailman/listinfo/
|
||||
Vendored
+40
@@ -0,0 +1,40 @@
|
||||
---
|
||||
Checks: "-*,\
|
||||
google-readability-casting,\
|
||||
misc-*,\
|
||||
-misc-incorrect-roundings,\
|
||||
-misc-macro-parentheses,\
|
||||
-misc-misplaced-widening-cast,\
|
||||
-misc-static-assert,\
|
||||
modernize-*,\
|
||||
-modernize-deprecated-headers,\
|
||||
-modernize-pass-by-value,\
|
||||
-modernize-raw-string-literal,\
|
||||
-modernize-return-braced-init-list,\
|
||||
-modernize-use-auto,\
|
||||
-modernize-use-default-member-init,\
|
||||
-modernize-use-emplace,\
|
||||
-modernize-use-equals-default,\
|
||||
-modernize-use-equals-delete,\
|
||||
-modernize-use-noexcept,\
|
||||
-modernize-use-transparent-functors,\
|
||||
-modernize-use-using,\
|
||||
performance-*,\
|
||||
-performance-inefficient-string-concatenation,\
|
||||
readability-*,\
|
||||
-readability-function-size,\
|
||||
-readability-identifier-naming,\
|
||||
-readability-implicit-bool-cast,\
|
||||
-readability-inconsistent-declaration-parameter-name,\
|
||||
-readability-named-parameter,\
|
||||
-readability-redundant-declaration,\
|
||||
-readability-redundant-member-init,\
|
||||
-readability-simplify-boolean-expr,\
|
||||
"
|
||||
HeaderFilterRegex: 'source/[^/]*\.(hh|cc)$'
|
||||
CheckOptions:
|
||||
- key: readability-braces-around-statements.ShortStatementLines
|
||||
value: '2'
|
||||
- key: readability-implicit-bool-conversion.AllowPointerConditions
|
||||
value: '1'
|
||||
...
|
||||
Vendored
+2
@@ -0,0 +1,2 @@
|
||||
# Parallel Tasking Library (PTL)
|
||||
Lightweight C++11 multithreading tasking system featuring thread-pool, task-groups, and lock-free task queue
|
||||
Vendored
+157
@@ -0,0 +1,157 @@
|
||||
Gunter Folger - 12 June 2018
|
||||
============================
|
||||
- Switch to original zlib sources, using zlib 1.2.11. Use C as compiler.
|
||||
Keep sources.cmake, this has most of zlib CMakeLists.txt code.
|
||||
|
||||
Gunter Folger - 17 June 2015
|
||||
============================
|
||||
- Update to zlib-1.2.8, keeping Geant4 specific structure of files.
|
||||
Compare files to new zlib, and transfer changes, keeping local
|
||||
modifications, like function declarationss, and removed register keyword.
|
||||
|
||||
|
||||
Gunter Folger - 27-March 2013
|
||||
=============================
|
||||
Update to zlib 1.2.7
|
||||
Again, rename source files to .cc.
|
||||
Add files for reading zlib format, i.e. zlib is now complete.
|
||||
Re-modify functions to compile with C++ compiler, "type-name" rather than
|
||||
"name { type" in all .cc code.
|
||||
In {gzlib,gzread,gzwrite}.cc, introduced several casts to avoid compile error for invalid
|
||||
converion
|
||||
- May 2013:
|
||||
Adapt to Geant4 cmake; copied portions of zlib CMakeLists.tzt to sources.cmake,
|
||||
using standard G4 CMakeLists.txt. Private header are in src, include only has
|
||||
zlib.h; zconf.h is configured and put into build tree; these two header files
|
||||
are installed.
|
||||
|
||||
Mark Donszelmann - 4 May 2005
|
||||
=============================
|
||||
Files renamed to .cc
|
||||
Removed all files for reading zlib format.
|
||||
Functions were modified to compile with C++ compiler, "type-name" rather than
|
||||
"name { type", in:
|
||||
|
||||
adler32.cc, compress.cc, crc32.cc, deflate.cc, trees.cc
|
||||
|
||||
In: deflate.cc and trees.cc all strings are casted to (char*) to avoid warnings.
|
||||
=============================================================
|
||||
|
||||
|
||||
Original zlib README:
|
||||
=====================
|
||||
ZLIB DATA COMPRESSION LIBRARY
|
||||
|
||||
zlib 1.2.7 is a general purpose data compression library. All the code is
|
||||
thread safe. The data format used by the zlib library is described by RFCs
|
||||
(Request for Comments) 1950 to 1952 in the files
|
||||
http://tools.ietf.org/html/rfc1950 (zlib format), rfc1951 (deflate format) and
|
||||
rfc1952 (gzip format).
|
||||
|
||||
All functions of the compression library are documented in the file zlib.h
|
||||
(volunteer to write man pages welcome, contact zlib@gzip.org). A usage example
|
||||
of the library is given in the file test/example.c which also tests that
|
||||
the library is working correctly. Another example is given in the file
|
||||
test/minigzip.c. The compression library itself is composed of all source
|
||||
files in the root directory.
|
||||
|
||||
To compile all files and run the test program, follow the instructions given at
|
||||
the top of Makefile.in. In short "./configure; make test", and if that goes
|
||||
well, "make install" should work for most flavors of Unix. For Windows, use
|
||||
one of the special makefiles in win32/ or contrib/vstudio/ . For VMS, use
|
||||
make_vms.com.
|
||||
|
||||
Questions about zlib should be sent to <zlib@gzip.org>, or to Gilles Vollant
|
||||
<info@winimage.com> for the Windows DLL version. The zlib home page is
|
||||
http://zlib.net/ . Before reporting a problem, please check this site to
|
||||
verify that you have the latest version of zlib; otherwise get the latest
|
||||
version and check whether the problem still exists or not.
|
||||
|
||||
PLEASE read the zlib FAQ http://zlib.net/zlib_faq.html before asking for help.
|
||||
|
||||
Mark Nelson <markn@ieee.org> wrote an article about zlib for the Jan. 1997
|
||||
issue of Dr. Dobb's Journal; a copy of the article is available at
|
||||
http://marknelson.us/1997/01/01/zlib-engine/ .
|
||||
|
||||
The changes made in version 1.2.7 are documented in the file ChangeLog.
|
||||
|
||||
Unsupported third party contributions are provided in directory contrib/ .
|
||||
|
||||
zlib is available in Java using the java.util.zip package, documented at
|
||||
http://java.sun.com/developer/technicalArticles/Programming/compression/ .
|
||||
|
||||
A Perl interface to zlib written by Paul Marquess <pmqs@cpan.org> is available
|
||||
at CPAN (Comprehensive Perl Archive Network) sites, including
|
||||
http://search.cpan.org/~pmqs/IO-Compress-Zlib/ .
|
||||
|
||||
A Python interface to zlib written by A.M. Kuchling <amk@amk.ca> is
|
||||
available in Python 1.5 and later versions, see
|
||||
http://docs.python.org/library/zlib.html .
|
||||
|
||||
zlib is built into tcl: http://wiki.tcl.tk/4610 .
|
||||
|
||||
An experimental package to read and write files in .zip format, written on top
|
||||
of zlib by Gilles Vollant <info@winimage.com>, is available in the
|
||||
contrib/minizip directory of zlib.
|
||||
|
||||
|
||||
Notes for some targets:
|
||||
|
||||
- For Windows DLL versions, please see win32/DLL_FAQ.txt
|
||||
|
||||
- For 64-bit Irix, deflate.c must be compiled without any optimization. With
|
||||
-O, one libpng test fails. The test works in 32 bit mode (with the -n32
|
||||
compiler flag). The compiler bug has been reported to SGI.
|
||||
|
||||
- zlib doesn't work with gcc 2.6.3 on a DEC 3000/300LX under OSF/1 2.1 it works
|
||||
when compiled with cc.
|
||||
|
||||
- On Digital Unix 4.0D (formely OSF/1) on AlphaServer, the cc option -std1 is
|
||||
necessary to get gzprintf working correctly. This is done by configure.
|
||||
|
||||
- zlib doesn't work on HP-UX 9.05 with some versions of /bin/cc. It works with
|
||||
other compilers. Use "make test" to check your compiler.
|
||||
|
||||
- gzdopen is not supported on RISCOS or BEOS.
|
||||
|
||||
- For PalmOs, see http://palmzlib.sourceforge.net/
|
||||
|
||||
|
||||
Acknowledgments:
|
||||
|
||||
The deflate format used by zlib was defined by Phil Katz. The deflate and
|
||||
zlib specifications were written by L. Peter Deutsch. Thanks to all the
|
||||
people who reported problems and suggested various improvements in zlib; they
|
||||
are too numerous to cite here.
|
||||
|
||||
Copyright notice:
|
||||
|
||||
(C) 1995-2012 Jean-loup Gailly and Mark Adler
|
||||
|
||||
This software is provided 'as-is', without any express or implied
|
||||
warranty. In no event will the authors be held liable for any damages
|
||||
arising from the use of this software.
|
||||
|
||||
Permission is granted to anyone to use this software for any purpose,
|
||||
including commercial applications, and to alter it and redistribute it
|
||||
freely, subject to the following restrictions:
|
||||
|
||||
1. The origin of this software must not be misrepresented; you must not
|
||||
claim that you wrote the original software. If you use this software
|
||||
in a product, an acknowledgment in the product documentation would be
|
||||
appreciated but is not required.
|
||||
2. Altered source versions must be plainly marked as such, and must not be
|
||||
misrepresented as being the original software.
|
||||
3. This notice may not be removed or altered from any source distribution.
|
||||
|
||||
Jean-loup Gailly Mark Adler
|
||||
jloup@gzip.org madler@alumni.caltech.edu
|
||||
|
||||
If you use the zlib library in a product, we would appreciate *not* receiving
|
||||
lengthy legal documents to sign. The sources are provided for free but without
|
||||
warranty of any kind. The library has been entirely written by Jean-loup
|
||||
Gailly and Mark Adler; it does not include third-party code.
|
||||
|
||||
If you redistribute modified sources, we would appreciate that you include in
|
||||
the file ChangeLog history information documenting your changes. Please read
|
||||
the FAQ for more information on the distribution of modified source versions.
|
||||
@@ -0,0 +1,105 @@
|
||||
G3toG4
|
||||
------
|
||||
|
||||
G3toG4 is the Geant4 facility to convert Geant3 geometries into Geant4.
|
||||
This is done in two stages.
|
||||
|
||||
First, the user supplies a Geant3 .rz file containing the initialization
|
||||
data structures. An executable, rztog4, reads this file and produces an
|
||||
ascii ("call list") file containing instructions on how to build the
|
||||
geometry. The source code for this is fortran.
|
||||
|
||||
Second, a call list interpreter (G4BuildGeom.cc) reads these instructions
|
||||
and builds the geometry in the user's G4 client code.
|
||||
|
||||
Two examples of how to use the call list interpreter are supplied in
|
||||
examples/extended/g3tog4:
|
||||
- the first example, cltog4, is a simple example which simply invokes the
|
||||
call list interpreter method G4BuildGeom from G3toG4DetectorConstruction
|
||||
class, builds the geometry and exits.
|
||||
- the second example, clGeometry, is more complete and is patterned after
|
||||
the novice G4 examples. It also invokes the call list interpreter, but
|
||||
in addition, allows the geometry to be visualized and particles to be
|
||||
tracked. Currently, G3toG4 does not provide a method for scoring hits
|
||||
in G4.
|
||||
|
||||
To build these examples, especially the one involving visualization, the
|
||||
user must have one or more of the following environment variables set:
|
||||
|
||||
setenv G4VIS_BUILD_<driver>_DRIVER
|
||||
setenv G4VIS_USE_<driver>
|
||||
|
||||
where the G4-supported drivers are listed in source/visualization/README.
|
||||
|
||||
To use the freeware Mesa API, you must have the environment variable
|
||||
OGLHOME defined to point to the directory containing the Mesa lib/ directory
|
||||
specific to your platform.
|
||||
|
||||
To compile and build the G3toG4 libraries, simply type
|
||||
|
||||
gmake
|
||||
|
||||
from the top-level G3toG4 directory.
|
||||
|
||||
To build the converter executable "rztog4", simply type
|
||||
|
||||
gmake bin
|
||||
|
||||
To make everything, simply type:
|
||||
|
||||
gmake global
|
||||
|
||||
To remove all G3toG4 libraries, executables and .d files, simply type
|
||||
|
||||
gmake clean
|
||||
|
||||
the implementation (April 1999)
|
||||
----------------------------------------
|
||||
- PGON, PCON are built using the CSG classes G4Polycone and G4Polyhedra.
|
||||
- G3 MANY feature has not been tested.
|
||||
- GsROTM is fully implemented and supports rotations and mirror reflections
|
||||
- GSPOSP implemented via individual logical volumes for each instantiation
|
||||
(G4PVIndexed doesn't exist yet)
|
||||
- GSDV* routines for dividing volumes implemented, using
|
||||
G4PVReplicas, G4PVParametrised
|
||||
- GSROTM is implemented
|
||||
- hits are not implemented. Hit code is do-nothing. (It is
|
||||
coded up, but hit class references are commented out.)
|
||||
The digits+hits code has to be updated before G3toG4's
|
||||
hit code can be activated.
|
||||
- GSPART has to be updated.
|
||||
- Usage of magnetic field class has to be turned on.
|
||||
|
||||
the implementation (February 2001)
|
||||
----------------------------------------
|
||||
- Supported shapes: all G3 shapes except for
|
||||
"HYPE", "GTRA", "CTUB"
|
||||
- G3 MANY feature is not supported.
|
||||
- GSDV* routines for dividing volumes implemented, using
|
||||
G4PVReplicas, for shapes:
|
||||
"BOX", "TUBE", "TUBS", "PARA" - all axes;
|
||||
"CONE", "CONS" - axes 2, 3;
|
||||
"TRD1", "TRD2", "TRAP" - axis 3;
|
||||
"PGON", "PCON" - axis 2;
|
||||
"PARA" -axis 1; axis 2,3 for a special case
|
||||
Unsupported shapes:
|
||||
"SPHE", "ELTU", "HYPE", "GTRA", "CTUB"
|
||||
|
||||
the implementation (November 2001)
|
||||
----------------------------------------
|
||||
- Support for G3 MANY feature:
|
||||
|
||||
MANY positions are resolved in G3toG4MANY function,
|
||||
which has to be processed before G3toG4BuildTree
|
||||
(it is not called by default).
|
||||
In order to resolve MANY user code has to provide
|
||||
additional info using G4gsbool(G4String volName, G4String manyVolName)
|
||||
function) for all overlapping volumes. Daughters of
|
||||
overlapping volumes are then resolved automatically
|
||||
and should not be specified via Gsbool.
|
||||
|
||||
Limitation: a volume with a MANY position can have only this
|
||||
one position; if more than one position is needed a new volume
|
||||
has to be defined (gsvolu) for each position.
|
||||
|
||||
See History file for modification history.
|
||||
@@ -0,0 +1,14 @@
|
||||
-------------------------------------------------------------------
|
||||
|
||||
|
||||
G4DecayPhysics
|
||||
--------------
|
||||
|
||||
G4RadioactiveDecayPhysics
|
||||
-------------------------
|
||||
|
||||
G4SpinDecayPhysics
|
||||
------------------
|
||||
|
||||
G4UnknownDecayPhysics
|
||||
---------------------
|
||||
@@ -0,0 +1,91 @@
|
||||
-------------------------------------------------------------------
|
||||
|
||||
|
||||
G4EmDNAChemistry
|
||||
----------------
|
||||
|
||||
G4EmDNAPhysics
|
||||
--------------
|
||||
|
||||
G4EmDNAPhysicsActivator
|
||||
-----------------------
|
||||
|
||||
G4EmDNAPhysics_option1
|
||||
----------------------
|
||||
|
||||
G4EmDNAPhysics_option2
|
||||
----------------------
|
||||
|
||||
G4EmDNAPhysics_option3
|
||||
----------------------
|
||||
|
||||
G4EmDNAPhysics_option4
|
||||
----------------------
|
||||
|
||||
G4EmDNAPhysics_option5
|
||||
----------------------
|
||||
|
||||
G4EmDNAPhysics_option7
|
||||
----------------------
|
||||
|
||||
G4EmLEPTSPhysics
|
||||
----------------
|
||||
|
||||
G4EmLivermorePhysics
|
||||
--------------------
|
||||
see https://geant4.web.cern.ch/geant4/collaboration/working_groups/electromagnetic/physlist.shtml
|
||||
|
||||
G4EmLivermorePolarizedPhysics
|
||||
-----------------------------
|
||||
see https://geant4.web.cern.ch/geant4/collaboration/working_groups/electromagnetic/physlist.shtml
|
||||
|
||||
G4EmLowEPPhysics
|
||||
----------------
|
||||
|
||||
G4EmModelActivator
|
||||
------------------
|
||||
|
||||
G4EmPenelopePhysics
|
||||
-------------------
|
||||
see https://geant4.web.cern.ch/geant4/collaboration/working_groups/electromagnetic/physlist.shtml
|
||||
|
||||
G4EmStandardPhysics
|
||||
-------------------
|
||||
see https://geant4.web.cern.ch/geant4/collaboration/working_groups/electromagnetic/physlist.shtml
|
||||
|
||||
G4EmStandardPhysicsGS
|
||||
---------------------
|
||||
see https://geant4.web.cern.ch/geant4/collaboration/working_groups/electromagnetic/physlist.shtml
|
||||
|
||||
G4EmStandardPhysicsSS
|
||||
---------------------
|
||||
see https://geant4.web.cern.ch/geant4/collaboration/working_groups/electromagnetic/physlist.shtml
|
||||
|
||||
G4EmStandardPhysicsWVI
|
||||
----------------------
|
||||
see https://geant4.web.cern.ch/geant4/collaboration/working_groups/electromagnetic/physlist.shtml
|
||||
|
||||
G4EmStandardPhysics_option1
|
||||
---------------------------
|
||||
see https://geant4.web.cern.ch/geant4/collaboration/working_groups/electromagnetic/physlist.shtml
|
||||
|
||||
G4EmStandardPhysics_option2
|
||||
---------------------------
|
||||
see https://geant4.web.cern.ch/geant4/collaboration/working_groups/electromagnetic/physlist.shtml
|
||||
|
||||
G4EmStandardPhysics_option3
|
||||
---------------------------
|
||||
see https://geant4.web.cern.ch/geant4/collaboration/working_groups/electromagnetic/physlist.shtml
|
||||
|
||||
G4EmStandardPhysics_option4
|
||||
---------------------------
|
||||
see https://geant4.web.cern.ch/geant4/collaboration/working_groups/electromagnetic/physlist.shtml
|
||||
|
||||
G4OpticalPhysics
|
||||
----------------
|
||||
|
||||
G4OpticalPhysicsMessenger
|
||||
-------------------------
|
||||
|
||||
G4OpticalProcessIndex
|
||||
---------------------
|
||||
@@ -0,0 +1,9 @@
|
||||
-------------------------------------------------------------------
|
||||
|
||||
|
||||
G4PhysicsConstructorFactory
|
||||
---------------------------
|
||||
|
||||
G4PhysicsConstructorRegistry
|
||||
----------------------------
|
||||
|
||||
@@ -0,0 +1,48 @@
|
||||
-------------------------------------------------------------------
|
||||
|
||||
|
||||
G4BertiniElectroNuclearBuilder
|
||||
------------------------------
|
||||
It includes gamma-nuclear, electron-nuclear and positron-nuclear
|
||||
processes.
|
||||
For gamma-nuclear, it uses Bertini (BERT) model for gamma below 6 GeV,
|
||||
and Quark-Gluon-String (QGS) model above 3 GeV.
|
||||
For electron-nuclear and positron-nuclear, it uses the equivalent photon
|
||||
approximation in which the incoming lepton generates a virtual photon,
|
||||
and then the virtual photon is converted to a real photon. This real
|
||||
photon is handled by BERT if its energy is below 10 GeV; if it is above
|
||||
10 GeV, then the real photon is transformed into a (on-shell) pi0 and
|
||||
then handled by Fritiof (FTF) string model.
|
||||
|
||||
|
||||
G4EmExtraPhysics
|
||||
----------------
|
||||
It uses G4BertiniElectroNuclearBuilder for gamma-nuclear, electron-nuclear
|
||||
and positron-nuclear.
|
||||
Moreover, it includes muon-nuclear process (for mu- and mu+), and
|
||||
synchrotron process (either for electron & positron, or for all
|
||||
charged particles).
|
||||
The muon-nuclear process is treated similarly as for electrons and
|
||||
positrons (i.e. the equivalent photon approximation in which the incoming
|
||||
lepton generates a virtual photon, and then the virtual photon is converted
|
||||
to a real photon, which is handled by BERT below 10 GeV or by FTF as a pi0
|
||||
above 10 GeV).
|
||||
By default, gamma-nuclear, electron-nuclear, positron-nuclear, and
|
||||
muon-nuclear are switched on, whereas synchrotron process is switched off
|
||||
for all particles. It is however possible, at run time via macro commands,
|
||||
to change this default (see G4EmMessenger below).
|
||||
|
||||
|
||||
G4EmMessenger
|
||||
-------------
|
||||
Used by G4EmExtraPhysics to be able to switch on/off:
|
||||
- synchrotron radiation for electron and positron
|
||||
(note: electron and positron together, not individually)
|
||||
- synchrotron radiation for all charged particles
|
||||
(note: all charged particles together, not individually)
|
||||
- gamma-nuclear, electron-nuclear and positron-nuclear
|
||||
(note: all these three particles together, not individually)
|
||||
- muon-nuclear
|
||||
(note: mu- and mu+ together, not individually)
|
||||
at run time, via macro commands.
|
||||
|
||||
@@ -0,0 +1,104 @@
|
||||
-------------------------------------------------------------------
|
||||
|
||||
|
||||
G4HadronElasticPhysics
|
||||
----------------------
|
||||
Hadron nuclear elastic process for all hadrons:
|
||||
- proton
|
||||
- cross section: Barashenkov-Glauber-Gribov
|
||||
- final-state: Chips
|
||||
- neutron:
|
||||
- cross section: G4NeutronElasticXS
|
||||
- final-state: Chips
|
||||
- charged pions:
|
||||
- cross section: Barashenkov-Glauber-Gribov
|
||||
- final-state: Starkov's model (G4ElasticHadrNucleusHE) for all energies
|
||||
- kaons, hyperons, anti-hyperons, charm and bottom hadrons
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: Gheisha
|
||||
- deuteron, triton, He3, alpha
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: Gheisha
|
||||
- anti_proton, anti_neutron, anti_deuteron, anti_triton, anti_He3,
|
||||
anti_alpha
|
||||
- cross-section: Galoyan-Uzhinsky-Glauber-Gribov
|
||||
- final-state: Galoyan-Uzhinsky model above 100 MeV/nucleon,
|
||||
Gheisha below.
|
||||
|
||||
G4HadronElasticPhysicsHP
|
||||
------------------------
|
||||
As G4HadronElasticPhysics, with the only difference that for neutrons
|
||||
below 20 MeV, NeutronHP elastic is used (for both cross section and
|
||||
final-state model).
|
||||
|
||||
G4HadronElasticPhysicsLEND
|
||||
--------------------------
|
||||
As G4HadronElasticPhysics, with the only difference that for neutrons
|
||||
below 20 MeV, LEND elastic is used (for both cross section and
|
||||
final-state model).
|
||||
|
||||
G4HadronElasticPhysicsXS
|
||||
------------------------
|
||||
Now exactly as G4HadronElasticPhysics.
|
||||
|
||||
G4HadronHElasticPhysics
|
||||
-----------------------
|
||||
- proton
|
||||
- cross section: Barashenkov-Glauber-Gribov
|
||||
- final-state: Diffuse model, except for Hydrogen where Chips is used,
|
||||
above 10 MeV, and Gheisha below
|
||||
- neutron:
|
||||
- cross section: G4NeutronElasticXS
|
||||
- final-state: Diffuse model, except for Hydrogen where Chips is used,
|
||||
above 10 MeV, and Gheisha below
|
||||
- charged pions:
|
||||
- cross section: Barashenkov-Glauber-Gribov
|
||||
- final-state: Diffuse model, except for Hydrogen where Chips is used,
|
||||
above 10 MeV, and Gheisha below
|
||||
- kaons, hyperons, anti-hyperons, charm and bottom hadrons
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: Gheisha
|
||||
- deuteron, triton, He3, alpha
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: Gheisha
|
||||
- anti_proton, anti_neutron
|
||||
- cross section: Galoyan-Uzhinsky-Glauber-Gribov
|
||||
- final-state: Galoyan-Uzhinsky model above 100 MeV/nucleon,
|
||||
Chips below.
|
||||
- anti_deuteron, anti_triton, anti_He3, anti_alpha
|
||||
- cross-section: Galoyan-Uzhinsky-Glauber-Gribov
|
||||
- final-state: Galoyan-Uzhinsky model above 100 MeV/nucleon,
|
||||
Gheisha below.
|
||||
|
||||
G4IonElasticPhysics
|
||||
-------------------
|
||||
As G4HadronElasticPhysics, with the addition of elastic process for
|
||||
generic ion:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: Diffuse model
|
||||
|
||||
|
||||
G4HadronDElasticPhysics
|
||||
-----------------------
|
||||
Hadron nuclear elastic process for all hadrons:
|
||||
- proton and charged pions:
|
||||
- cross section: Barashenkov-Glauber-Gribov
|
||||
- final-state: Diffuse model where applicable, else Gheisha
|
||||
- neutron:
|
||||
- cross section: G4NeutronElasticXS
|
||||
- final-state: Diffuse model where applicable, else Gheisha
|
||||
- kaons, hyperons, anti-hyperons, charm and bottom hadrons,
|
||||
deuteron, triton, He3, alpha
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: Gheisha
|
||||
- anti_proton, anti_neutron, anti_deuteron, anti_triton, anti_He3,
|
||||
anti_alpha
|
||||
- cross-section: Galoyan-Uzhinsky-Glauber-Gribov
|
||||
- final-state: Galoyan-Uzhinsky model above 100 MeV/nucleon,
|
||||
Gheisha below.
|
||||
|
||||
G4ChargeExchangePhysics
|
||||
-----------------------
|
||||
Hadron nuclear coherent charge exchange, used in this constructor
|
||||
only for nucleons and charged pions.
|
||||
|
||||
@@ -0,0 +1,282 @@
|
||||
-------------------------------------------------------------------
|
||||
|
||||
|
||||
G4HadronInelasticQBBC
|
||||
---------------------
|
||||
Hadron nuclear inelastic processes for all hadrons:
|
||||
- proton inelastic:
|
||||
- cross section: G4ParticleInelasticXS
|
||||
- final-state: Fritiof coupled with Precompound/de-excitation (FTFP) above 3 GeV;
|
||||
Bertini (BERT) between 1 and 6 GeV;
|
||||
Binary coupled with Precompound/de-excitation (BIC) below 1.5 GeV
|
||||
- neutron inelastic:
|
||||
- cross section: G4NeutronInelasticXS
|
||||
- final-state: FTFP > 3 GeV; 1 GeV < BERT < 6 GeV; BIC < 1.5 GeV
|
||||
neutron capture:
|
||||
- cross section: G4NeutronCaptureXS
|
||||
- final-state: G4NeutronRadCapture
|
||||
- charged pions inelastic:
|
||||
- cross section: Barashenkov-Glauber-Gribov
|
||||
- final-state: FTFP > 3 GeV; 1 GeV < BERT < 12 GeV; BIC < 1.5 GeV
|
||||
- kaons inelastic:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: FTFP > 3 GeV; BERT < 6 GeV
|
||||
- hyperons inelastic:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: FTFP > 3 GeV; BERT < 6 GeV
|
||||
- anti_proton, anti_neutron, anti_deuteron, anti_triton, anti_He3, anti_alpha inelastic:
|
||||
- cross-section: Galoyan-Uzhinsky-Glauber-Gribov
|
||||
- final-state: FTFP for all energies
|
||||
- anti_hyperons inelastic:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: FTFP for all energies
|
||||
- charm and bottom hadrons inelastic:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: FTFP for all energies
|
||||
|
||||
|
||||
G4HadronPhysicsFTFP_BERT
|
||||
------------------------
|
||||
Hadron nuclear inelastic processes for all hadrons:
|
||||
- proton inelastic:
|
||||
- cross section: Barashenkov-Glauber-Gribov (G4BGGNucleonInelasticXS)
|
||||
- final-state: FTFP > 3 GeV; BERT < 6 GeV
|
||||
- neutron inelastic:
|
||||
- cross section: G4NeutronInelasticXS
|
||||
- final-state: FTFP > 3 GeV; BERT < 6 GeV
|
||||
neutron capture:
|
||||
- cross section: G4NeutronCaptureXS
|
||||
- final-state: G4NeutronRadCapture
|
||||
- charged pions inelastic:
|
||||
- cross section: Barashenkov-Glauber-Gribov
|
||||
- final-state: FTFP > 3 GeV; BERT < 6 GeV
|
||||
- kaons inelastic:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: FTFP > 3 GeV; BERT < 6 GeV
|
||||
- hyperons inelastic:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: FTFP > 3 GeV; BERT < 6 GeV
|
||||
- anti_proton, anti_neutron, anti_deuteron, anti_triton, anti_He3, anti_alpha inelastic:
|
||||
- cross-section: Galoyan-Uzhinsky-Glauber-Gribov
|
||||
- final-state: FTFP for all energies
|
||||
- anti_hyperons inelastic:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: FTFP for all energies
|
||||
- charm and bottom hadrons inelastic:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: FTFP for all energies
|
||||
|
||||
|
||||
G4HadronPhysicsFTFP_BERT_ATL
|
||||
----------------------------
|
||||
Similar to G4HadronPhysicsFTFP_BERT, with the difference that for proton,
|
||||
neutron, pions and kaons, the FTFP is used above 9 GeV and BERT below 12 GeV
|
||||
(i.e. transition between these two models is in the interval [9, 12] GeV
|
||||
for the most frequent hadrons).
|
||||
|
||||
|
||||
G4HadronPhysicsFTFP_BERT_HP
|
||||
--------------------------
|
||||
Similar to G4HadronPhysicsFTFP_BERT, but with a different treatment of
|
||||
low-energy neutrons:
|
||||
- neutron inelastic: use NeutronHP (for both cross section and final state)
|
||||
below 20 MeV; above G4NeutronCaptureXS cross section;
|
||||
final-state: BERT between 19.9 MeV and 6 GeV,
|
||||
FTFP above 3 GeV.
|
||||
- neutron capture: use NeutronHP (for both cross section and final state)
|
||||
below 20 MeV; above G4NeutronCaptureXS cross section
|
||||
and G4NeutronRadCapture final-state.
|
||||
- neutron fission: use NeutronHP (for both cross section and final state)
|
||||
below 20 MeV; above Gheisha (cross section and final state).
|
||||
Moreover, RadioactiveDecay is activated (as in all the physics lists that use HP).
|
||||
|
||||
|
||||
G4HadronPhysicsFTFP_BERT_TRV
|
||||
----------------------------
|
||||
The same as G4HadronPhysicsFTFP_BERT.
|
||||
|
||||
|
||||
G4HadronPhysicsFTF_BIC
|
||||
----------------------
|
||||
Similar to G4HadronPhysicsFTFP_BERT, with the following differences:
|
||||
- For proton and neutron, BIC is used (instead of BERT) below 6 GeV
|
||||
- For pions, BIC is used below 1.5 GeV, whereas BERT is used in the
|
||||
interval 1 GeV < BERT < 6 GeV
|
||||
- FTF is coupled with BIC (instead of directly to Precompound/de-excitation).
|
||||
|
||||
|
||||
G4HadronPhysicsQGS_BIC
|
||||
----------------------
|
||||
Similar to G4HadronPhysicsFTP_BIC, except that QGSP is used above 12 GeV
|
||||
and FTFP below 25 GeV.
|
||||
|
||||
|
||||
G4HadronPhysicsFTFQGSP_BERT
|
||||
---------------------------
|
||||
Similar to G4HadronPhysicsFTFP_BERT, but with QGS fragmentation of strings
|
||||
(instead of the Lund string fragmentation).
|
||||
|
||||
|
||||
G4HadronPhysicsINCLXX
|
||||
---------------------
|
||||
Similar to QGSP_BERT except for:
|
||||
- proton inelastic:
|
||||
- cross section: Barashenkov-Glauber-Gribov (G4BGGNucleonInelasticXS)
|
||||
- final-state: QGSP > 15 GeV; 1 MeV < INCLXX < 20 GeV; Preco < 2 MeV
|
||||
- neutron inelastic:
|
||||
- cross section: G4NeutronInelasticXS
|
||||
- final-state: QGSP > 15 GeV; 1 MeV < INCLXX < 20 GeV; Preco < 2 MeV
|
||||
- charged pions inelastic:
|
||||
- cross section: Barashenkov-Glauber-Gribov
|
||||
- final-state: QGSP > 15 GeV; 1 MeV < INCLXX < 20 GeV; Preco < 2 MeV
|
||||
- kaons inelastic:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: QGSP > 14 GeV; BERT < 15 GeV
|
||||
Note: it is possible to specify in the constructor the use of FTFP
|
||||
instead of QGSP;
|
||||
moreover, NeutronHP can also be activated in the constructor,
|
||||
in which case inelastic, capture and fission below 20 MeV are
|
||||
taken from NeutronHP (both cross section and final-state).
|
||||
|
||||
|
||||
G4HadronPhysicsNuBeam
|
||||
---------------------
|
||||
Similar to FTFP_BERT, except for the final-state models of proton:
|
||||
- proton : QGSP with Lund string fragmentation > 100 GeV;
|
||||
3 GeV < FTFP < 101 GeV; BERT < 6 GeV
|
||||
|
||||
|
||||
G4HadronPhysicsQGSP_BERT
|
||||
------------------------
|
||||
Hadron nuclear inelastic processes for all hadrons:
|
||||
- proton inelastic:
|
||||
- cross section: Barashenkov-Glauber-Gribov (G4BGGNucleonInelasticXS)
|
||||
- final-state: QGSP > 12 GeV; 3 GeV < FTFP < 25 GeV; BERT < 6 GeV
|
||||
- neutron inelastic:
|
||||
- cross section: G4NeutronInelasticXS
|
||||
- final-state: QGSP > 12 GeV; 3 GeV < FTFP < 25 GeV; BERT < 6 GeV
|
||||
neutron capture:
|
||||
- cross section: G4NeutronCaptureXS
|
||||
- final-state: G4NeutronRadCapture
|
||||
- charged pions inelastic:
|
||||
- cross section: Barashenkov-Glauber-Gribov
|
||||
- final-state: QGSP > 12 GeV; 3 GeV < FTFP < 25 GeV; BERT < 6 GeV
|
||||
- kaons inelastic:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: QGSP > 12 GeV; 3 GeV < FTFP < 25 GeV; BERT < 6 GeV
|
||||
- hyperons inelastic:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: QGSP > 12 GeV; 3 GeV < FTFP < 25 GeV; BERT < 6 GeV
|
||||
- anti_proton and anti_neutron inelastic:
|
||||
- cross-section: Galoyan-Uzhinsky-Glauber-Gribov
|
||||
- final-state: QGSP > 12 GeV; FTFP < 25 GeV
|
||||
- anti_deuteron, anti_triton, anti_He3, and anti_alpha inelastic:
|
||||
- cross-section: Galoyan-Uzhinsky-Glauber-Gribov
|
||||
- final-state: FTFP for all energies
|
||||
- anti_hyperons inelastic:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: QGSP > 12 GeV; FTFP < 25 GeV
|
||||
- charm and bottom hadrons inelastic:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: QGSP > 12 GeV; FTFP < 25 GeV
|
||||
|
||||
|
||||
G4HadronPhysicsQGSP_FTFP_BERT
|
||||
-----------------------------
|
||||
Currently it is the same as QGSP_BERT (this was not the case before G4 10.6).
|
||||
It might be removed in future versions of Geant4.
|
||||
|
||||
|
||||
G4HadronPhysicsQGSP_BERT_HP
|
||||
---------------------------
|
||||
Similar to G4HadronPhysicsQGSP_BERT, but with a different treatment of
|
||||
low-energy neutrons:
|
||||
- neutron inelastic: use NeutronHP (for both cross section and final state)
|
||||
below 20 MeV; above G4NeutronCaptureXS cross section;
|
||||
final-state: BERT between 19.9 MeV and 6 GeV,
|
||||
FTFP between 3 and 25 GeV, QGSP above 12 GeV.
|
||||
- neutron capture: use NeutronHP (for both cross section and final state)
|
||||
below 20 MeV; above G4NeutronCaptureXS cross section
|
||||
and G4NeutronRadCapture final-state.
|
||||
- neutron fission: use NeutronHP (for both cross section and final state)
|
||||
below 20 MeV; above Gheisha (cross section and final state).
|
||||
Moreover, RadioactiveDecay is activated (as in all the physics lists that use HP).
|
||||
|
||||
|
||||
G4HadronPhysicsQGSP_BIC
|
||||
-----------------------
|
||||
Hadron nuclear inelastic processes for all hadrons:
|
||||
- proton inelastic:
|
||||
- cross section: Barashenkov-Glauber-Gribov (G4BGGNucleonInelasticXS)
|
||||
- final-state: QGSP > 12 GeV; 3 GeV < FTFP < 25 GeV; BIC < 6 GeV
|
||||
- neutron inelastic:
|
||||
- cross section: G4NeutronInelasticXS
|
||||
- final-state: QGSP > 12 GeV; 3 GeV < FTFP < 25 GeV; BIC < 6 GeV
|
||||
neutron capture:
|
||||
- cross section: G4NeutronCaptureXS
|
||||
- final-state: G4NeutronRadCapture
|
||||
- charged pions inelastic:
|
||||
- cross section: Barashenkov-Glauber-Gribov
|
||||
- final-state: QGSP > 12 GeV; 3 GeV < FTFP < 25 GeV; BERT < 6 GeV
|
||||
- kaons inelastic:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: QGSP > 12 GeV; 3 GeV < FTFP < 25 GeV; BERT < 6 GeV
|
||||
- hyperons inelastic:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: QGSP > 12 GeV; 3 GeV < FTFP < 25 GeV; BERT < 6 GeV
|
||||
- anti_proton and anti_neutron inelastic:
|
||||
- cross-section: Galoyan-Uzhinsky-Glauber-Gribov
|
||||
- final-state: QGSP > 12 GeV; FTFP < 25 GeV
|
||||
- anti_deuteron, anti_triton, anti_He3, and anti_alpha inelastic:
|
||||
- cross-section: Galoyan-Uzhinsky-Glauber-Gribov
|
||||
- final-state: FTFP for all energies
|
||||
- anti_hyperons inelastic:
|
||||
- cross section: Glauber-Gribov
|
||||
- final-state: QGSP > 12 GeV; FTFP < 25 GeV
|
||||
|
||||
|
||||
G4HadronPhysicsQGSP_BIC_HP
|
||||
--------------------------
|
||||
Similar to G4HadronPhysicsQGSP_BIC, but with a different treatment of
|
||||
low-energy neutrons:
|
||||
- neutron inelastic: use NeutronHP (for both cross section and final state)
|
||||
below 20 MeV; above G4NeutronCaptureXS cross section;
|
||||
final-state: BIC between 19.9 MeV and 6 GeV,
|
||||
FTFP between 3 and 25 GeV, QGSP above 12 GeV.
|
||||
- neutron capture: use NeutronHP (for both cross section and final state)
|
||||
below 20 MeV; above G4NeutronCaptureXS cross section
|
||||
and G4NeutronRadCapture final-state.
|
||||
- neutron fission: use NeutronHP (for both cross section and final state)
|
||||
below 20 MeV; above Gheisha (cross section and final state).
|
||||
Moreover, RadioactiveDecay is activated (as in all the physics lists that use HP).
|
||||
|
||||
|
||||
G4HadronPhysicsQGSP_BIC_AllHP
|
||||
-----------------------------
|
||||
Similar to G4HadronPhysicsQGSP_BIC_HP, but with a different treatment of
|
||||
low-energy protons:
|
||||
ParticleHP is used (for both cross section and final state) below 200 MeV;
|
||||
above it: Barashenkov-Glauber-Gribov inelastic cross section;
|
||||
final-state: QGSP > 12 GeV; 3 GeV < FTFP < 25 GeV; 190 MeV < BIC < 6 GeV.
|
||||
|
||||
|
||||
G4HadronPhysicsShielding
|
||||
------------------------
|
||||
Similar to G4HadronPhysicsFTFP_BERT_HP except for using
|
||||
JENDLHEInelasticCrossSection for the neutron inelastic cross section
|
||||
above 20 MeV.
|
||||
Note: the variant "M" of the Shielding physics list has a transition region
|
||||
between FTFP and BERT for pions between 9.5 and 9.9 GeV
|
||||
(instead of 3-6 GeV).
|
||||
|
||||
|
||||
G4HadronPhysicsShieldingLEND
|
||||
----------------------------
|
||||
Similar to G4HadronPhysicsShielding, except that LEND is used for neutrons
|
||||
below 20 MeV instead of NeutronHP.
|
||||
|
||||
|
||||
G4VHadronPhysics
|
||||
----------------
|
||||
Utility class which provides useful methods.
|
||||
|
||||
@@ -0,0 +1,44 @@
|
||||
-------------------------------------------------------------------
|
||||
|
||||
|
||||
G4IonBinaryCascadePhysics
|
||||
-------------------------
|
||||
Inelastic ion-ion processes (for deuteron, triton, He3, alpha and
|
||||
generic ion projectiles), with Glauber-Gribov cross section and
|
||||
Binary Light Ion (BIC, with Precompound/de-excitation) and Fritiof (FTF)
|
||||
string model (with Precompound/de-excitation) for the final state.
|
||||
BIC is used for projectiles of kinetic energies below 6 GeV/nucleon, and
|
||||
FTF above 3 GeV/nucleon.
|
||||
|
||||
G4IonINCLXXPhysics
|
||||
------------------
|
||||
Inelastic ion-ion processes (for deuteron, triton, He3, alpha and
|
||||
generic ion projectiles), with Glauber-Gribov cross section and
|
||||
INCLXX and FTFP for the final state. INCLXX is used below 3 GeV/nucleon,
|
||||
and FTF above 2.9 GeV/nucleon.
|
||||
|
||||
G4IonPhysics
|
||||
------------
|
||||
Currently equivalent to G4IonBinaryCascadePhysics.
|
||||
|
||||
G4IonPhysicsXS
|
||||
--------------
|
||||
As G4IonPhysics, except that for deuteron, triton, He3 and alpha
|
||||
the corresponding G4ParticleInelasticXS cross section is used
|
||||
(instead of G4ComponentGGNuclNuclXsc).
|
||||
|
||||
G4IonPhysicsPHP
|
||||
---------------
|
||||
Similar to G4IonBinaryCascadePhysics, except that ParticleHP (for both
|
||||
cross sections and final states) is used below 200 MeV/n for deuteron,
|
||||
triton, He3 and alpha (and BIC used above 190 MeV/n for these light ions).
|
||||
|
||||
G4IonQMDPhysic
|
||||
--------------
|
||||
Inelastic ion-ion processes (for deuteron, triton, He3, alpha and
|
||||
generic ion projectiles), with Glauber-Gribov cross section and
|
||||
BIC, QMD and FTFP for the final state. These three final-state models
|
||||
are used in the following intervals of projectile kinetic energy:
|
||||
- BIC below 110 MeV/nucleon;
|
||||
- QMD between 100 and 6'000 MeV/nucleon;
|
||||
- FTF above 5990 MeV/nucleon.
|
||||
@@ -0,0 +1,72 @@
|
||||
contructors/limiters
|
||||
--------------------
|
||||
|
||||
This directory contains "technical" constructors in the sense they do not
|
||||
add processes with physics content but add processes or modify physics lists to
|
||||
allow for step limitation in parallel geometries, biasing, etc.
|
||||
|
||||
|
||||
G4FastSimulationPhysics:
|
||||
------------------------
|
||||
|
||||
Constructor that modifies a given physics list to allow for fast simulation.
|
||||
|
||||
One, or several, G4FastSimulationManagerProcess objects are added to the
|
||||
process manager of particles for which a fast simulation is requested.
|
||||
|
||||
The fast simulation may be associated to regions in the mass geometry, in
|
||||
what case a call like fastSimPhys->ActivateFastSimulation("e-") must be
|
||||
done to allow for fast simulation of electrons.
|
||||
Parallel geometries can be used also in what case the geometry is specified
|
||||
by its name like fastSimPhys->ActivateFastSimulation("e-","parallelGeom") to
|
||||
allow for fast simulation of electrons, with fast simulation models attached
|
||||
to regions in "parallelGeom".
|
||||
|
||||
|
||||
G4GenericBiasingPhysics:
|
||||
------------------------
|
||||
|
||||
Constructor that modifies a given physics list to allow for generic biasing.
|
||||
|
||||
It provides three type of functionnalities:
|
||||
- wrap physics processes with G4BiasingProcessInterface processes to
|
||||
make the generic biasing to control them (allowing change of
|
||||
interaction law, change of final state generation).
|
||||
- add G4BiasingProcessInterface processes, but without wrapping a
|
||||
physics process, in what case these processes will be used for
|
||||
"non-physics based biasing" : ie, spliting and killing
|
||||
- add G4ParallelGeometriesLimiterProcess process (at most one per
|
||||
process manager) that provides step limitation on the parallel
|
||||
geometries used in generic biasing. A process can handle several
|
||||
parallel geometries associated to one particle type.
|
||||
|
||||
Various methods are provided to activate these functionnalities per
|
||||
particle, set of particles, to activate physics-based only or
|
||||
non-physics-based only or both functionnalities, and to activate the
|
||||
parallel geometry functionnality.
|
||||
This is documented in include/G4GenericBiasingPhysics.hh .
|
||||
|
||||
|
||||
G4ImportanceBiasing:
|
||||
-------------------
|
||||
|
||||
G4MaxTimeCuts:
|
||||
--------------
|
||||
|
||||
G4MinEkineCuts:
|
||||
---------------
|
||||
|
||||
G4NeutronTrackingCut:
|
||||
---------------------
|
||||
|
||||
G4ParallelWorldPhysics:
|
||||
-----------------------
|
||||
|
||||
G4SpecialCuts:
|
||||
--------------
|
||||
|
||||
G4StepLimiterPhysics:
|
||||
---------------------
|
||||
|
||||
G4WeightWindowBiasing:
|
||||
----------------------
|
||||
@@ -0,0 +1,19 @@
|
||||
-------------------------------------------------------------------
|
||||
|
||||
|
||||
G4StoppingPhysics
|
||||
-----------------
|
||||
It uses Bertini/Precompound (i.e. Bertini followed by the official
|
||||
Precompound/deexcitation of Geant4, not the internal one of Bertini)
|
||||
for nuclear capture of: pi-, K-, Sigma-, Xi- and Omega-.
|
||||
It uses Fritiof/Precompound model for nuclear capture of: anti_proton,
|
||||
anti_neutron, anti_Lambda, anti_Sigma0, anti_Sigma+, anti_Xi0,
|
||||
anti_deuteron, anti_triton, anti_He3, and anti_alpha.
|
||||
For mu-, Bertini model is used for nuclear capture, together with
|
||||
default element selector, EM cascade sampling and bound decay sampling.
|
||||
|
||||
G4StoppingPhysicsFritiofWithBinaryCascade
|
||||
-----------------------------------------
|
||||
The same as G4StoppingPhysics, except that for anti-proton and anti-neutron
|
||||
annihilation at rest it uses Fritiof coupled with Binary Cascade.
|
||||
|
||||
+81
@@ -0,0 +1,81 @@
|
||||
|
||||
The photo-evaporation database contains nuclear deexcitation data starting
|
||||
from a given nuclear level. Each file contains data for a given isotope,
|
||||
identified by Z and A.
|
||||
|
||||
The database must first be downloaded from
|
||||
|
||||
http://geant4.web.cern.ch/geant4/support/download.shtml
|
||||
|
||||
and stored in a local directory. The environment variable
|
||||
G4LEVELGAMMADATA must then be set to point to this directory.
|
||||
|
||||
**************************************************
|
||||
|
||||
Each line describes a de-excitation *step* from a given energy level to a lower
|
||||
one (which might be the ground state). It contains data for gamma de-excitation
|
||||
and internal conversion. Notice that if multiple de-excitation
|
||||
channels are allowed for the starting energy level, these channels will be
|
||||
described in more lines (all having the same starting level).
|
||||
|
||||
|
||||
Each line contains 17 columns:
|
||||
|
||||
1) Energy of the starting nuclear level (keV)
|
||||
As mentioned before, it is possible to have more lines describing the same
|
||||
starting level, in the case where multiple de-excitation schemes are
|
||||
allowed.
|
||||
|
||||
2) Energy of the transition (keV)
|
||||
This is the energy difference between the initial and the final level.
|
||||
|
||||
3) Gamma transition probability (Ig in %)
|
||||
Note1: if the probability is less than minProbability = 1e-8%, it is forced
|
||||
to be 1e-8%.
|
||||
Note2: see column 7 how total branching ratio is computed.
|
||||
|
||||
4) Polarity
|
||||
Spin-parity variation in the transition
|
||||
[never used in real simulation]
|
||||
|
||||
5) Level half-life (s)
|
||||
|
||||
6) Angular Momentum
|
||||
Spin of the initial level
|
||||
[never used in real simulation]
|
||||
|
||||
7) Total internal conversion coefficient : alpha = Ic/Ig
|
||||
Note1: total transition is the sum of gamma de-excitation and internal
|
||||
conversion. Therefore total branching ratio is proportional to
|
||||
(1+alpha)*Ig
|
||||
Note2: total branching ratios from a given level do not always sum up to
|
||||
100%. They are re-normalized internally.
|
||||
Note3: relative probabilities for gamma de-excitation and internal conversion
|
||||
are 1/(1+alpha) and alpha/(1+alpha) respectively
|
||||
|
||||
8-17) Partial conversion probabilities for
|
||||
K-shell
|
||||
L1-3 shells
|
||||
M1-5 shells
|
||||
Outer shells (shellID = 9 is used, when applicable)
|
||||
|
||||
Note: if the nuclear excitation energy does not match any of the known levels,
|
||||
the *nearest* level is always considered. In G4RadioactiveDecay,
|
||||
metastable states are treated correctly if the excitation energy is
|
||||
within 2.0 keV of the values in $G4RADIOACTIVEDATA.
|
||||
|
||||
For instance: take file $G4LEVELGAMMADATA/z28.a60 (Ni-60)
|
||||
Co-60 radioactive decay populates the 1332.5080-keV level of
|
||||
Ni-60 (0.12%) or the 2505.7480-keV level of Ni-60 (99.88%).
|
||||
|
||||
Deexcitation from the 2505.7480-keV level is described in lines
|
||||
6-8 of $G4LEVELGAMMADATA/z28.a60 (Ni-60)
|
||||
Here, internal conversion coefficients are negligeable (column 7)
|
||||
Therefore the nucleus will release
|
||||
1) 347 keV with 7.6e-3% probability, ending up in the 2158-keV level
|
||||
(following de-excitation hence takes place, lines 2-4 of the file)
|
||||
2) 1173 keV with 100% probability, ending up in the 1332-keV
|
||||
excited state (following de-excitation hence takes place, line 1)
|
||||
3) 2505 keV with 2e-6% probability ending up in the ground state.
|
||||
|
||||
|
||||
@@ -0,0 +1,2 @@
|
||||
The tuning of resonances can still improve in a iteration on short-lived particles.
|
||||
|
||||
@@ -0,0 +1,38 @@
|
||||
|
||||
This README file provides instructions for reading the radioactive decay
|
||||
schemes in the files zXX.aYYY found in the directory RadioactiveDecay3.2
|
||||
(most recent version). This directory, as well as previous versions, is
|
||||
available from the Geant4 download page
|
||||
|
||||
http://geant4.web.cern.ch/geant4/support/download.shtml
|
||||
|
||||
under the Data files heading. In order to use the radioactive decay module
|
||||
correctly, you must download and unpack the above directory in your local
|
||||
area, and set the environment variable
|
||||
|
||||
G4RADIOACTIVEDATA
|
||||
|
||||
to point to it.
|
||||
|
||||
**************************************************************************
|
||||
In each of the files, lines beginning with either a 'W' or a '#' are
|
||||
comments.
|
||||
|
||||
Lines beginning with a 'P' are headers, each of which describes a level of
|
||||
the nucleus. The first number is the excitation energy in keV, the second
|
||||
is the half life in seconds. Indented lines under the 'P' lines are decay
|
||||
modes for that excitation. There are two type of records here,
|
||||
distinguished by the number of columns.
|
||||
|
||||
If there are 3 columns only, this is a header which describes all decays of
|
||||
that type from this level. The first column is the decay mode, the second
|
||||
column is zero, and the third column in the branching ratio to this mode,
|
||||
as a fraction of unity. Therefore, the third columns of all the 3-column
|
||||
records under a given 'P' line should sum to 1.0.
|
||||
|
||||
If there are four columns, this is a record which describes a subset of the
|
||||
decay type, specific to a given lower level in the daughter species. The
|
||||
first column is the decay type, the second column is the excitation level
|
||||
of the daughter (in keV), and the third column is the branching ratio as a
|
||||
percentage (! note... not a fraction of unity) of the total branching ratio
|
||||
which came from the 3-column record for this decay.
|
||||
@@ -0,0 +1,38 @@
|
||||
|
||||
Contains processes for phonon propagation and interaction in materials.
|
||||
|
||||
G4LatticeManager: Singleton (TLS) for logical and physical lattices
|
||||
associated with materials and volumes.
|
||||
|
||||
G4LatticeReader: Driver to create logical lattices by reading in
|
||||
configuration files and velocity map tables. NOTE: This class will
|
||||
be moved to source/materials/ once Release 10.0 is deployed.
|
||||
|
||||
The lattice data files should be stored under $G4LATTICEDATA (set to
|
||||
"./CrystalMaps" by default, to support the extended example). The
|
||||
configuration and velocity map files for a given material should be stored
|
||||
in a subdirectory with that material's name (e.g., "Ge").
|
||||
|
||||
Documentation for the lattice configuration files will be expanded in the
|
||||
future.
|
||||
|
||||
G4VPhononProcess: Virtual base class for all processes below, providing
|
||||
some utility functions.
|
||||
|
||||
G4PhononDownconversion: Process to convert single longitudinal phonons
|
||||
either into pairs of two transverse phonons, or to emit a transverse
|
||||
phonon.
|
||||
|
||||
G4PhononReflection: Placeholder process to reflect phonons off of crystal
|
||||
surfaces. Currently phonons are absorbed, or converted to hits.
|
||||
|
||||
G4PhononScattering: Process to scatter phonons off the surrounding
|
||||
lattice. Currently handles "transportation" as well, but each
|
||||
scatter destroys the phonon and creates a new one.
|
||||
|
||||
G4PhononPolarization: Enum with conversion functions to map the three
|
||||
phonon particle definitions onto internal codes (L=0, TS=1, TF=2).
|
||||
|
||||
G4PhononTrackMap: Singleton (TLS) map file to connect tracks with
|
||||
wavevectors. for temporary use until wavevector is added to G4Track
|
||||
as a data member, after Release 10.0.
|
||||
@@ -0,0 +1,131 @@
|
||||
|
||||
GEANT4
|
||||
|
||||
This directory contains several examples of GEANT4 main programs,
|
||||
from very simple cases (a purely batch program),
|
||||
to interactive programs based on the G4 command line interface,
|
||||
to more complex cases programs touching most of the G4 functionality.
|
||||
|
||||
Those main programs provide just examples of initialization and usage
|
||||
of the GEANT4 toolkit classes, but the user is also free to define his
|
||||
own way and functions to initialize G4 and write the main program.
|
||||
|
||||
A typical GEANT4 main program looks like the following:
|
||||
|
||||
int main() {
|
||||
|
||||
// Create Run Manager
|
||||
G4RunManager * runManager = new G4RunManager;
|
||||
|
||||
// Register User Classes to the RunManager
|
||||
// Mandatory classes -----------------------
|
||||
// Detector geometry
|
||||
runManager-> set_userInitialization(new MyDetectorConstruction);
|
||||
// Physics List
|
||||
runManager-> set_userInitialization(new MyPhysicsList);
|
||||
// Primary Generator
|
||||
runManager->set_userAction(new MyPrimaryGeneratorAction);
|
||||
|
||||
// Optiolnal classes -----------------------
|
||||
// User Actions
|
||||
runManager->set_userAction(new MyRunAction);
|
||||
runManager->set_userAction(new MyEventAction);
|
||||
runManager->set_userAction(new MyStackingAction);
|
||||
runManager->set_userAction(new MyTrackingAction);
|
||||
runManager->set_userAction(new MySteppingAction);
|
||||
|
||||
|
||||
// Define (G)UI terminal for interactive mode
|
||||
G4UIsession * session = new G4UIterminal;
|
||||
|
||||
// User interactions
|
||||
session->sessionStart();
|
||||
|
||||
// Termination
|
||||
delete session;
|
||||
delete runManager;
|
||||
return 0;
|
||||
}
|
||||
|
||||
First of all, user must create the RunManager. The RunManager controles
|
||||
run sequence by receiving messages from the user via UIsession.
|
||||
The following are a part of commands for run controle;
|
||||
/run/initialize * Initialize G4 kernel.
|
||||
/run/beamOn * Start a Run.
|
||||
/run/verbose * Set the verbose level of G4RunManager.
|
||||
/run/abort * Abort current run processing.
|
||||
For example, event loop will start by using "/run/beamOn" commands.
|
||||
|
||||
In order to execute simulation, user must provide geometrical
|
||||
configuration of his own detector. In addition information of
|
||||
primary events must be given with a list of particle types and
|
||||
processes for them.
|
||||
|
||||
So, user must provide his own classes derived from the following
|
||||
three abstract classes by implementing their pure virtual functions
|
||||
and register those user classes to the RunManager.
|
||||
|
||||
G4VUserDetectorConstruction - Detector Geometry, Materials
|
||||
pure virtual functions
|
||||
G4VPhysicalVolume* construct()
|
||||
- construct detectors;
|
||||
normally implemented to serve as the entry point
|
||||
for the tree of methods describing solids, volumes,
|
||||
materials and sensitive detectors.
|
||||
|
||||
G4VUserPhysicsList - Particle types and Processes
|
||||
pure virtual functions
|
||||
void constructParticle()
|
||||
- construct particles;
|
||||
normally implemented to select desired particle types.
|
||||
void constructPhysics()
|
||||
- construct procesess;
|
||||
normally implemented to select desired physics processes
|
||||
for each particle types and register them to the ProcessManager.
|
||||
void setCuts(G4double aValue)
|
||||
- sets a cut value;
|
||||
normally implemented to set cut value in range for all
|
||||
particle types.
|
||||
|
||||
G4VUserPrimaryGeneratorAction - Event Generator selection
|
||||
pure virtual functions
|
||||
void generatePrimaries(G4Event* anEvent)
|
||||
- generate a event with primary particles
|
||||
normally implemented to select the desired event generation
|
||||
mechanism, such as the ParticleGun or the PYTHIA interface.
|
||||
|
||||
In addition to the above mandatory classes, there are 5 user classes
|
||||
to customize the default functionality of GEANT4 simulation.
|
||||
|
||||
G4UserRunAction - Actions for each Run
|
||||
G4UserEventAction - Actions for each Event
|
||||
G4UserStackingAction - Tracks Stacking selection
|
||||
G4UserTrackingAction - Actions for each Track
|
||||
G4UserSteppingAction - Actions for each Step
|
||||
|
||||
The virtual functions belonging to the classes above are:
|
||||
|
||||
G4UserRunAction - void beginOfRunAction(G4Run*)
|
||||
- void endOfRunAction(G4Run*)
|
||||
|
||||
G4UserEventAction - void beginOfEventAction(G4Event*)
|
||||
- void endOfEventAction(G4Event*)
|
||||
|
||||
G4UserStackingAction - G4ClassificationOfNewTrack
|
||||
classifyNewTrack(G4Track *const)
|
||||
- void newStage()
|
||||
- void prepareNewEvent()
|
||||
|
||||
G4UserTrackingAction - void preUserTrackingAction()
|
||||
- void postUserTrackingAction()
|
||||
|
||||
G4UserSteppingAction - void userSteppingAction()
|
||||
|
||||
Finally, more details can be found in the header files and in the source
|
||||
code relative to the classes outlined above.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,226 @@
|
||||
# Geant4 Tasking
|
||||
|
||||
This directory contains a Geant4 run manager which uses a tasking system for the G4Event loop.
|
||||
This tasking system is fully compatible with TBB if `GEANT4_USE_TBB=ON` is specified when
|
||||
configuring CMake. The default behavior, however, is to submit the tasks to an internal
|
||||
thread-pool and task-queue.
|
||||
|
||||
## G4TaskRunManager
|
||||
|
||||
`G4TaskRunManager` multiply inherits from `G4MTRunManager` and `PTL::TaskRunManager`.
|
||||
`PTL::TaskRunManager` holds the thread-pool instance, the size of the thread-pool,
|
||||
and the default task-queue. The constructor of `G4TaskRunManager` takes a `G4VUserTaskQueue`
|
||||
pointer (can be nullptr), a boolean for whether to use TBB if available, and a grainsize.
|
||||
|
||||
### Concepts
|
||||
|
||||
#### Grainsize
|
||||
|
||||
> Environment Variable: `G4FORCE_GRAINSIZE=N`
|
||||
|
||||
The grainsize is essentially the number of tasks. If set to 0, the default grainsize
|
||||
will be `poolSize` and each thread will get `numEvents / poolSize` events.
|
||||
If the grainsize is set to 1, then _all the events_ will be submitted as one task (i.e. be
|
||||
processed serially by one thread in the pool). If the grainsize is set to 50 and there are 500 events,
|
||||
then 50 tasks of 10 events will be submitted.
|
||||
|
||||
#### Events Per Tasks
|
||||
|
||||
> Environment Variable: `G4FORCE_EVENTS_PER_TASK=N`
|
||||
|
||||
Sometimes is easier to specify the number of events in a task instead of the grainsize.
|
||||
If the events-per-task is set to 10 and there are 500 events,
|
||||
then 50 tasks of 10 events will be submitted.
|
||||
|
||||
### Default Constructor
|
||||
|
||||
```cpp
|
||||
G4TaskRunManager(G4VUserTaskQueue* = nullptr, bool useTBB = false, G4int grainsize = 0);
|
||||
```
|
||||
|
||||
## G4RunManagerFactory
|
||||
|
||||
An enumeration `G4RunManagerType` and a function `G4RunManagerFactory::CreateRunManager(...)`
|
||||
was added to `"G4RunManagerFactory.hh"` to simplify the selection of the various run managers.
|
||||
The first parameter is either one of the enumerated `G4RunManagerType` or a string identifier
|
||||
|
||||
| Enumeration | String ID | Class |
|
||||
| ------------------------------- | ----------- | ------------------- |
|
||||
| `G4RunManagerType::Serial` | `"Serial"` | `G4RunManager` |
|
||||
| `G4RunManagerType::MT` | `"MT"` | `G4MTRunManager` |
|
||||
| `G4RunManagerType::Tasking` | `"Tasking"` | `G4TaskRunManager` |
|
||||
| `G4RunManagerType::TBB` | `"TBB"` | `G4TaskRunManager` |
|
||||
| `G4RunManagerType::Default` | `"Default"` | Environment setting |
|
||||
| `G4RunManagerType::SerialOnly` | `"Serial"` | `G4RunManager` |
|
||||
| `G4RunManagerType::MTOnly` | `"MT"` | `G4MTRunManager` |
|
||||
| `G4RunManagerType::TaskingOnly` | `"Tasking"` | `G4TaskRunManager` |
|
||||
| `G4RunManagerType::TBBOnly` | `"TBB"` | `G4TaskRunManager` |
|
||||
|
||||
|
||||
The `Default` enumeration value will defer to the following environment variable `G4RUN_MANAGER_TYPE`
|
||||
if specified and will default to `"MT"` if MT is supported and serial if MT is not supported.
|
||||
If the `G4FORCE_RUN_MANAGER_TYPE` environment variable is set, this variable will override the
|
||||
value passed to the `CreateRunManager` function unless `G4RunManagerType` matches one of the `<TYPE>Only`
|
||||
values. In this case, the environment variable is ignored and the run manager will be `<TYPE>`.
|
||||
|
||||
| Environment Variable | Options | Description |
|
||||
| -------------------------- | ---------------------------------------- | -------------------------------------------------------------------------------------- |
|
||||
| `G4RUN_MANAGER_TYPE` | `"Serial"`, `"MT"`, `"Tasking"`, `"TBB"` | Only applicable when `G4RunManagerType::Default` is used |
|
||||
| `G4FORCE_RUN_MANAGER_TYPE` | `"Serial"`, `"MT"`, `"Tasking"`, `"TBB"` | Will override explicitly specifed `G4RunManagerType` if application allows and fail if type is not available |
|
||||
|
||||
## Creating the G4RunManager
|
||||
|
||||
- The `G4RunManagerFactory::CreateRunManager(...)` function takes either `G4RunManagerType` enumerated type or string to specify the desired G4RunManager
|
||||
- If a string is used, regex matching is used which is case-insensitive
|
||||
- Returns a `G4RunManager*`
|
||||
- Various overloads exist which just reorder passing in:
|
||||
- `int numberOfThreads` - executes `G4MTRunManager::SetNumberOfThreads(numberOfThreads)` before returning if > 0
|
||||
- default: `0`
|
||||
- `bool fail_if_unavail` - will cause a runtime failure if requested type is not available with Geant4 build
|
||||
- default: `true`
|
||||
- `G4VTaskQueue*` - a task-queue manager
|
||||
- default: `nullptr`
|
||||
|
||||
```cpp
|
||||
#include "G4RunManagerFactory.hh"
|
||||
|
||||
int main()
|
||||
{
|
||||
// specify {Serial, MT, Tasking, TBB} as the default, can be overridden
|
||||
// with "G4FORCE_RUN_MANAGER_TYPE" env variable
|
||||
auto* runmanager = G4RunManagerFactory::CreateRunManager(G4RunManagerType::Serial);
|
||||
auto* runmanager = G4RunManagerFactory::CreateRunManager(G4RunManagerType::MT);
|
||||
auto* runmanager = G4RunManagerFactory::CreateRunManager(G4RunManagerType::Tasking);
|
||||
auto* runmanager = G4RunManagerFactory::CreateRunManager(G4RunManagerType::TBB);
|
||||
|
||||
// specify {Serial, MT, Tasking, TBB} as the required type, cannot be overridden
|
||||
// with "G4FORCE_RUN_MANAGER_TYPE" env variable
|
||||
auto* runmanager = G4RunManagerFactory::CreateRunManager(G4RunManagerType::SerialOnly);
|
||||
auto* runmanager = G4RunManagerFactory::CreateRunManager(G4RunManagerType::MTOnly);
|
||||
auto* runmanager = G4RunManagerFactory::CreateRunManager(G4RunManagerType::TaskingOnly);
|
||||
auto* runmanager = G4RunManagerFactory::CreateRunManager(G4RunManagerType::TBBOnly);
|
||||
|
||||
// defer to "G4RUN_MANAGER_TYPE" env variable and default to MT if
|
||||
// env variable is not set
|
||||
auto* runmanager = G4RunManagerFactory::CreateRunManager(G4RunManagerType::Default);
|
||||
|
||||
// same as above
|
||||
auto* runmanager = G4RunManagerFactory::CreateRunManager();
|
||||
}
|
||||
```
|
||||
|
||||
## Using the Tasking System
|
||||
|
||||
With G4TaskRunManager, Geant4 events will be launched asynchronously as tasks. These tasks are
|
||||
placed into a queue until one of the thread in the pool is available to execute the task. Users can
|
||||
take advantage of this system to load-balance expensive sub-event calculations which might have
|
||||
previously resulted in serial bottlenecks. For example, if an application needs to do extensive event
|
||||
analysis on electrons and thread #1 ends up with 10x as many of these events, the other threads
|
||||
might finish their G4Run significantly eariler and be idle while thread #1 has a lot of work.
|
||||
Tasking allows these analysis calculations to be offload back into the queue so that other
|
||||
threads can contribute to their completion.
|
||||
|
||||
### Option 1 - Submit Directly to Thread-Pool
|
||||
|
||||
- To execute the function `foo(int, double)` asynchronously:
|
||||
|
||||
```cpp
|
||||
// get the task manager
|
||||
auto* task_manager = G4TaskRunManager::GetTaskManager();
|
||||
|
||||
// submit task to thread-pool and receive a future for when the result is need
|
||||
std::future<void> _fvoid = task_manager->async<void>(foo, 1, 1.0);
|
||||
std::future<int> _fint = task_manager->async<int>(bar, 1.0);
|
||||
|
||||
// wait for task to execute
|
||||
_fvoid.wait();
|
||||
_fint.wait();
|
||||
|
||||
// get the result (if non-void)
|
||||
auto result = _fint.get();
|
||||
```
|
||||
|
||||
### Option 2 - Submit to task-group
|
||||
|
||||
- Obtain a pointer to the thread-pool instance
|
||||
- Create a `task_group<T>` object where `T` is the return type of all the functions in the group
|
||||
- If `T` is non-void, you must provide a join functor who return type and first argument are both references
|
||||
to the joined type and the second argument is type `T`, e.g. `task_group<int>` can provide a join functor
|
||||
with `vector<int>&` as the return type and `T` as the second argument or `int&` as the return and first argument
|
||||
and `int` as the second argument
|
||||
- If `T` is void, the join functor is optional and can be treated as a final synchronization operation after
|
||||
all the tasks have been completed.
|
||||
|
||||
> NOTE: The join functor for task-groups are called sequentially on the thread that is
|
||||
> waiting on `task_group<T>::join()` member function.
|
||||
|
||||
#### Global Definitions for Examples
|
||||
|
||||
```cpp
|
||||
// obtain thread-pool instance from task manager
|
||||
static auto* thread_pool = G4TaskRunManager::GetThreadPool();
|
||||
|
||||
// trivial int function which just returns value passed
|
||||
int foo(int v) { return v; }
|
||||
|
||||
// function which launches CUDA kernel
|
||||
void bar(int v)
|
||||
{
|
||||
cuda_bar<<<512, 1>>>(v);
|
||||
}
|
||||
```
|
||||
|
||||
#### Example with non-void return types from tasks
|
||||
|
||||
```cpp
|
||||
// put all return values from tasks into an array
|
||||
auto join_vec = [](std::vector<int>& lhs, int rhs) { lhs.push_back(rhs); return lhs; };
|
||||
|
||||
// sum the values returned by tasks
|
||||
auto sum_int = [](int& lhs, int rhs) { return lhs += rhs; };
|
||||
|
||||
// task group which applies 'join_vec' to all task return values
|
||||
task_group<int> vec_tg(join_vec, thread_pool);
|
||||
// task group with applies 'sum_int' to all task return values
|
||||
task_group<int> sum_tg(sum_int, thread_pool);
|
||||
|
||||
// submit work to task-groups
|
||||
vec_tg.exec(foo, 1);
|
||||
vec_tg.exec(foo, 2);
|
||||
sum_tg.exec(foo, 1);
|
||||
sum_tg.exec(foo, 2);
|
||||
|
||||
// produces std::vector{ 1, 2 };
|
||||
auto vec_result = vec_tg.join();
|
||||
|
||||
// produces 1 + 2 = 3
|
||||
auto sum_result = sum_tg.join();
|
||||
```
|
||||
|
||||
#### Example with void return type from tasks
|
||||
|
||||
```cpp
|
||||
// wait for the GPU to finish
|
||||
auto sync = []() { cudaDeviceSynchronize(); };
|
||||
|
||||
// task group which applies 'sync' after all tasks have been executed
|
||||
task_group<void> gpu_tg(sync, thread_pool);
|
||||
// generic task group w/o a join functor
|
||||
task_group<void> general_tg(thread_pool);
|
||||
|
||||
// submit work to task-groups
|
||||
gpu_tg.exec(bar, 1);
|
||||
gpu_tg.exec(bar, 2);
|
||||
general_tg.exec(bar, 1);
|
||||
general_tg.exec(bar, 2);
|
||||
|
||||
// 'sync()' will get called after all tasks in group have executed
|
||||
// (i.e. return from 'bar' function). 'sync' will then block until
|
||||
// all GPU work has been completed
|
||||
gpu_tg.join();
|
||||
|
||||
// will block only until all tasks in group have been executed
|
||||
// (i.e. returned from 'bar' function)
|
||||
generic_tg.join();
|
||||
|
||||
```
|
||||
@@ -0,0 +1,30 @@
|
||||
<< Portability >>
|
||||
|
||||
Compilation of DAWN-file and DAWN-network drivers
|
||||
are confirmed at the following platforms:
|
||||
|
||||
Linux, DEC, HP, AIX, Solaris, IRIX
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,152 @@
|
||||
This G4 Graphics Driver creates a HepRep File suitable for viewing
|
||||
by the HepRApp, Wired4 or FRED Event Display clients.
|
||||
It requires no external packages.
|
||||
|
||||
The HepRep graphics format is further described at
|
||||
http://www.slac.stanford.edu/~perl/heprep/
|
||||
|
||||
|
||||
Two different drivers are available for either HepRep1 or HepRep2.
|
||||
|
||||
|
||||
Driver: HepRepFile
|
||||
------------------
|
||||
The version of HepRep produced by this driver is HepRep Version 1.
|
||||
|
||||
Writes files with file extension .heprep.
|
||||
|
||||
First file is written to current directory and is named G4Data0.heprep.
|
||||
Subsequent files increment the number, as in G4Data1.heprep, G4Data2.heprep...
|
||||
|
||||
To specify a different output file directory (instead of current directory),
|
||||
set G4HEPREPFILE_DIR
|
||||
|
||||
To specify a different output file name (instead of G4Data),
|
||||
set G4HEPREPFILE_NAME
|
||||
|
||||
To repeatedly overwrite the same output file (instead of having incremental
|
||||
numbers at the end of the file name),
|
||||
set G4HEPREPFILE_OVERWRITE
|
||||
|
||||
By default, invisible objects are not culled but are left in the heprep file
|
||||
with their visibility initially set to false (so that you can subsequently
|
||||
choose to make them visible from within the heprep browser).
|
||||
To force culling of invisible objects,
|
||||
set G44HEPREPFILE_CULL
|
||||
|
||||
View the file using the HepRApp HepRep Browser, available from:
|
||||
http://www.slac.stanford.edu/~perl/HepRApp
|
||||
|
||||
HepRApp can read xml files in zipped format as well as unzipped,
|
||||
so you can save space by applying gzip to the xml file.
|
||||
This will reduce the file to about five percent of its original size.
|
||||
|
||||
Joseph Perl
|
||||
15 November 2007
|
||||
|
||||
|
||||
Driver: HepRepXML
|
||||
-----------------
|
||||
The version of HepRep produced by this driver is HepRep Version 2.
|
||||
|
||||
This driver can write both Binary HepRep (.bheprep) and XML HepRep
|
||||
(.heprep) files. Binary HepRep files are a one-to-one translation
|
||||
of XML HepRep files, but they are considerably shorter and faster
|
||||
to parse by a HepRepViewer such as WIRED 4.
|
||||
|
||||
You can view the files using the WIRED 4 Event Display, available from:
|
||||
|
||||
http://wired4.freehep.org
|
||||
|
||||
Both Binary HepRep and XML HepRep can be compressed using the standard
|
||||
zlib library if linked into Geant4 using G4LIB_USE_ZLIB. If a standard
|
||||
zlib is not available (WIN32-VC for instance) you should also set
|
||||
G4LIB_BUILD_ZLIB to build G4zlib included with Geant4.
|
||||
|
||||
HepRep files (Binary and XML) can contain multiple HepRep events/geometries.
|
||||
If the file contains more than one HepRep it is not strictly XML anymore.
|
||||
Files can be written in .heprep.zip, .heprep.gz or .heprep format and their
|
||||
binary versions .bheprep.zip, .bheprep.gz or .bheprep.
|
||||
|
||||
The .heprep.zip is the default for file output, the .heprep is the default
|
||||
for stdout and stderr.
|
||||
|
||||
(Optional) To set the filename with a particular extension such as:
|
||||
.heprep.zip, .heprep.gz, .heprep, .bheprep.zip, .bheprep.gz or .bheprep
|
||||
use for instance:
|
||||
|
||||
/vis/scene/create filename.bheprep.zip
|
||||
|
||||
|
||||
(Optional) To create separate files for each event, you can set a suffix such as
|
||||
"-0001" to start writing files from filename-0001.bheprep.zip to
|
||||
filename-9999.bheprep.zip (or up), while "-55-sub" will start write files
|
||||
filename-55-sub.bheprep.zip to filename-99-sub.bheprep.zip (or up).
|
||||
|
||||
/vis/heprep/setEventNumberSuffix -0001
|
||||
(Note: suffix has to contain at least one digit)
|
||||
|
||||
|
||||
(Optional) To route the HepRep XML output to stdout (or stderr),
|
||||
by default uncompressed, use:
|
||||
|
||||
/vis/scene/create stdout
|
||||
|
||||
|
||||
To select the driver, where the file if not create by scene is set to
|
||||
G4HepRepOutput.heprep.zip, use:
|
||||
|
||||
/vis/open HepRepXML
|
||||
|
||||
|
||||
(Optional) To write a geometry, use:
|
||||
|
||||
/vis/viewer/flush
|
||||
|
||||
|
||||
(Optional) To signal a change in geometry (to be written with the next event), use:
|
||||
|
||||
/vis/viewer/refresh
|
||||
|
||||
|
||||
To write 10 events (and geometries), use:
|
||||
|
||||
/run/beamOn 10
|
||||
|
||||
|
||||
(Optional) To accumulate multiple (5) G4 events into one HepRep event, use:
|
||||
/vis/scene/endOfEventAction accumulate
|
||||
/run/beamOn 5
|
||||
/vis/viewer/update
|
||||
|
||||
|
||||
(Optional) To add attributes to each point on a trajectory, use:
|
||||
/vis/heprep/addPointAttributes 1
|
||||
Be aware that this may increase the size of the output dramatically.
|
||||
|
||||
|
||||
(Optional) You may use the commands:
|
||||
/vis/viewer/zoom to set an initial zoom factor
|
||||
/vis/viewer/set/viewpointThetaPhi to set an initial view point
|
||||
/vis/heprep/setCoordinateSystem uvw to change the coordinate system, where uvw can be "xyz", "zxy", ...
|
||||
|
||||
|
||||
(Optional) You may decide to write .zip files with events and geometry separated (but linked).
|
||||
This results in a smaller zip file, as the geometry is only written once. Use the command:
|
||||
|
||||
/vis/heprep/appendGeometry false
|
||||
|
||||
|
||||
(Optional) To close the file, remove the SceneHandler, use:
|
||||
|
||||
/vis/sceneHandler/remove scene-handler-0
|
||||
|
||||
|
||||
Limitations:
|
||||
|
||||
Only one SceneHandler can exist at any time, connected to a single Viewer.
|
||||
Since the HepRep format is a model rather than a view this is not a real
|
||||
limitation. In WIRED 4 you can create as many views (SceneHandlers) as you like.
|
||||
|
||||
1 June 2005
|
||||
Mark.Donszelmann@slac.stanford.edu
|
||||
@@ -0,0 +1,23 @@
|
||||
Apart from the heprep1 files:
|
||||
|
||||
G4HepRepFile.hh
|
||||
G4HepRepFileSceneHandler.hh
|
||||
G4HepRepFileViewer.hh
|
||||
G4HepRepFileXMLWriter.hh
|
||||
|
||||
and heprep2 files:
|
||||
|
||||
G4HepRep.hh
|
||||
G4HepRepSceneHandler.hh
|
||||
G4HepRepMessenger.hh
|
||||
G4HepRepViewer.hh
|
||||
|
||||
the other sources are copies from the FreeHEP library
|
||||
(java.freehep.org) and are maintained there.
|
||||
|
||||
The files starting with G4 are geant4 compliant, the others may not be.
|
||||
|
||||
Changes made here may be overwritten.
|
||||
|
||||
4 May 2005
|
||||
Mark Donszelmann
|
||||
@@ -0,0 +1,186 @@
|
||||
Extended OI Xt viewer
|
||||
=====================
|
||||
INCOMPLETE DRAFT
|
||||
|
||||
G4OpenInventorXtExaminerViewer is based on and is
|
||||
a plug-in replacement for SoXtExaminerViewer which
|
||||
is a base class viewer provided by the SoXt (Coin3d)
|
||||
library. SoXtExaminerViewer is the normal viewer
|
||||
that you get when doing /vis/open OIX.
|
||||
These viewers depend on X, Xt and Xm and so are
|
||||
limited to UNIX/MAC and will not run on native
|
||||
Windows.
|
||||
|
||||
The SoXtExaminerViewer is instantiated by
|
||||
G4OpenInventorXtViewer. This has been temporarily
|
||||
disabled and has been replaced by an instantiation
|
||||
of G4OpenInventorXtExaminerViewer, together with
|
||||
some additional configuration. The intention
|
||||
is to find a suitable mechanism to allow a choice
|
||||
of viewer (standard or extended) at run time.
|
||||
|
||||
No modifications to user code or to any other
|
||||
Geant4 categories are required to use the extended
|
||||
viewer. Many of the implemented features are made
|
||||
possible by the SCENE GRAPH technology in Open
|
||||
Inventor which stores the scene elements and
|
||||
associated information in a structured way.
|
||||
|
||||
Features
|
||||
========
|
||||
|
||||
Reference Path navigation
|
||||
-------------------------
|
||||
|
||||
Most of the new features are concerned with navigation
|
||||
along a "reference path" which is a piecewise
|
||||
linear path through the world. The reference path
|
||||
can be any particle trajectory, chosen as follows:
|
||||
|
||||
The application can attach a "reference trajectory"
|
||||
attribute to a particular trajectory.
|
||||
|
||||
If there is no such designated trajectory, the viewer
|
||||
chooses the longest trajectory as the initial reference
|
||||
path.
|
||||
|
||||
Any other trajectory can be selected as the reference
|
||||
by selecting it with the mouse.
|
||||
|
||||
Elements are assigned a "distance" along the reference
|
||||
path, based on the perpendicular from the element's
|
||||
placement coordinates to the path. Elements are then
|
||||
sorted by distance and the list is displayed in an
|
||||
auxiliary window of the viewer. NOTE: at present
|
||||
the path is not extrapolated at the ends, so elements
|
||||
"before" or "after" the path are assigned distances
|
||||
of 0 or the total path length respectively. This
|
||||
will be generalized in future.
|
||||
|
||||
Reference path navigation controls:
|
||||
|
||||
Select an element from the list: navigate along the
|
||||
path to the element's "location" (distance along
|
||||
the path.
|
||||
|
||||
L,R,U,D refer to the arrow keys.
|
||||
|
||||
Shift-L and Shift-R: navigate to the previous or next
|
||||
element on the path (with wraparound).
|
||||
|
||||
L and R: rotate 90 degrees around the vertical axis
|
||||
|
||||
U and D: rotate 90 degrees around the path
|
||||
|
||||
Ctrl-L and Ctrl-R: rotate 90 degrees around the horizontal axis
|
||||
|
||||
All these keys have a "repeat" function for continuous motion.
|
||||
|
||||
The rotation keys put the camera in a definite orientation.
|
||||
The Shift-L and Shift-R keys can be used to "fly" along the
|
||||
path in whatever orientation is in effect.
|
||||
NOTE: if this appears to be "stuck", try switching from
|
||||
orthonormal camera to perspective camera ("cube" viewer button).
|
||||
|
||||
Tools / Go to start of reference path: useful if you get lost
|
||||
|
||||
Tools / Invert reference path: flips the direction of travel
|
||||
and the distance readout
|
||||
|
||||
|
||||
Reference path animation
|
||||
|
||||
This is a special mode which flys the camera steadily along the
|
||||
path, without wraparound. Special controls are:
|
||||
|
||||
Tools / Animate Ref Particle: start animation mode
|
||||
|
||||
Page-Up: increase speed
|
||||
Page-Down: decrease speed
|
||||
U: raise camera
|
||||
D: lower camera
|
||||
ESC: exit animation mode
|
||||
|
||||
For suitable geometries the U and D keys can be used to
|
||||
get "Star Wars" style fly-over and fly-under effects.
|
||||
|
||||
Bookmarks
|
||||
|
||||
At any time, the viewpoint and other camera parameters can
|
||||
be saved in a file as a labelled "bookmark".
|
||||
The view can then be restored later in the current run or
|
||||
in another run.
|
||||
|
||||
The default name for the bookmark file is ".bookmarkFile"
|
||||
The first time a viewpoint is saved, this file will be
|
||||
created if it does not already exist. When the viewer
|
||||
is first opened, it will automatically read this file
|
||||
if present and load the viewpoints into the left-hand
|
||||
panel of the viewer's auxiliary window.
|
||||
|
||||
Controls:
|
||||
|
||||
Select viewpoint from list: restore this view
|
||||
|
||||
Right-arrow VIEWER button: go to next viewpoint
|
||||
Left-arrow VIEWER button: go to next viewpoint
|
||||
|
||||
"Floppy Disk" button: save current view.
|
||||
The user can type in a label for the view,
|
||||
or use the default label provided.
|
||||
|
||||
File / Open Viewpoint File: loads an existing bookmark file
|
||||
File / New Viewpoint File: creates a new bookmark file for
|
||||
saving subsequent views
|
||||
|
||||
|
||||
Special Picking Modes
|
||||
|
||||
"Console" VIEWER button: enable brief trajectory picking and
|
||||
mouse-over element readout
|
||||
For trajectories, the list of all trajectory points is
|
||||
replaced by the first and last point only, allowing easier
|
||||
identification of the particle without scrolling back.
|
||||
Passing the mouse over an element will give a readout
|
||||
of the volume name, material, and position on the
|
||||
reference path.
|
||||
|
||||
"Star" VIEWER button: select new reference path
|
||||
The cursor will change to a small cross (+)
|
||||
after which a trajectory can be selected to become
|
||||
the new reference path.
|
||||
|
||||
Convenience feature
|
||||
|
||||
Escape from viewer without using the mouse:
|
||||
In addition to the File / Escape menu item, pressing the "e"
|
||||
key on the keyboard will exit from the viewer's X event loop.
|
||||
The viewer becomes inactive and control returns to the
|
||||
Geant4 UI prompt.
|
||||
|
||||
Prototype only:
|
||||
|
||||
File / Save-Load Ref Coords: status to be determined
|
||||
|
||||
File / Save-Load Scene Graph: this saves the current scene graph,
|
||||
(whatever is being viewed and navigated in the viewer)
|
||||
including the geometry, camera, lighting information, into a
|
||||
file which can be read back, thus returning to a previous
|
||||
viewing "experience". This only partially works and some
|
||||
or all of the geometry may be missing. Geant4-specific
|
||||
scene elements may be lacking a "save" method.
|
||||
|
||||
Known problems:
|
||||
|
||||
Viewer occasionally hangs in an unknown state.
|
||||
Usually can be "cleared" by trying various viewer buttons
|
||||
or menu items. Last resort: escape to the G4 prompt and
|
||||
run more events. Viewer will usually be o.k. afterwards.
|
||||
|
||||
Unpredictable mode-switching behaviour: switching between
|
||||
orthonormal and perspective camera may give wierd results.
|
||||
Navigation may appear "stuck" with orthonormal camera.
|
||||
|
||||
Both the standard and extended viewers can crash the
|
||||
executable or even the X server if they are pushed
|
||||
too far (e.g. by excessive zooming).
|
||||
@@ -0,0 +1,82 @@
|
||||
|
||||
G4RayTracer version 1.0 (29/Jan/00)
|
||||
|
||||
1. Introduction
|
||||
|
||||
G4RayTracer is a "ray tracing" package which uses Geant4 kernel mechanism
|
||||
of tracking/navigation. It visualizes any kinds of solids that Geant4
|
||||
kernel can navigate.
|
||||
|
||||
2. Building a library
|
||||
|
||||
G4RayTracer is one of visualization driver which Geant4 supports. To build
|
||||
a library of G4RayTracer (library name G4RayTracer), set an environment
|
||||
variable G4VIS_BUILD_RAYTRACER_DRIVER.
|
||||
|
||||
$ setenv G4VIS_BUILD_RAYTRACER_DRIVER 1
|
||||
|
||||
3. Using G4RayTracer
|
||||
|
||||
To use G4RayTracer, set an environment variable G4VIS_USE_RAYTRACER.
|
||||
|
||||
$ setenv G4VIS_USE_RAYTRACER 1
|
||||
|
||||
Also, G4RayTracer has to be registored to the user's concrete VisManager.
|
||||
Refer an example given in
|
||||
geant4/source/visualization/management/include/MyVisManager.cc.
|
||||
|
||||
4. Notes
|
||||
|
||||
a) G4RayTracer generates JPEG file(s). To visualize these files, use your
|
||||
local program such as NetScape or xview, etc.
|
||||
|
||||
b) The eye position must be inside of the defined world volume. If you want
|
||||
to draw your detector setup from very far position, you need to enlarge
|
||||
your world volume.
|
||||
|
||||
c) G4RayTracer ignores volumes without G4VisAttributes, volumes which are
|
||||
set as "forced wire frame", and volumes which are set as "invisible".
|
||||
|
||||
d) In case you get unexpected figure, check
|
||||
d.1) eye position and target position are properly set,
|
||||
d.2) light direction is properly set (note light direction is from
|
||||
illumination light source to the objects),
|
||||
d.3) span angle (given by angle for 100 pixels) is reasonable,
|
||||
d.4) there is no surrounding volume(s) without transparency.
|
||||
|
||||
e) G4RayTracer can be executed ONLY AT "Idle" state.
|
||||
|
||||
5. Basic UI commands
|
||||
|
||||
a) /vis/rayTracer/eyePosition x y z unit
|
||||
eye position
|
||||
|
||||
b) /vis/rayTracer/target x y z unit
|
||||
target position
|
||||
in default it is set to the origine
|
||||
|
||||
c) /vis/rayTracer/lightDirection ex ey ez
|
||||
vector of the illuminating light (need not to be a unit vector)
|
||||
note light direction is from illumination light source to the objects
|
||||
|
||||
d) /vis/rayTracer/column nColumn
|
||||
number of holizontal pixels
|
||||
in default 640 pixels
|
||||
|
||||
e) /vis/rayTracer/row nRow
|
||||
number of virtical pixels
|
||||
in default 640 pixels
|
||||
|
||||
f) /vis/rayTracer/span angle unit
|
||||
angle for 100 pixels
|
||||
in default 5 degree
|
||||
|
||||
g) /vis/rayTracer/trace fileName
|
||||
execution of G4RayTracer
|
||||
"fileName" is the out put JPEG file name
|
||||
in default "g4RayTracer.jpeg"
|
||||
NOTE THAT THIS COMMAND IS AVAILABLE ONLY AT IDLE STATE
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
//-- gMocren-file driver --//
|
||||
|
||||
Oct. 12, 2009 : Akinori Kimura
|
||||
Beta release.
|
||||
It supports a geometry constructed with G4PhantomParameterisation or
|
||||
G4VNestedParameterisation and a hits collection based on G4VHits,
|
||||
primitive scorer or the interactive scorer.
|
||||
|
||||
Apr. 1, 2009 : Akinori Kimura
|
||||
|
||||
First version of the gMocren-file driver.
|
||||
This is a prototype, not a release version.
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
Modeling
|
||||
=======
|
||||
|
||||
The idea is to put GEANT4-aware but user-enviroment-independent code
|
||||
here. It introduces the concept of a G4VModel.
|
||||
|
||||
Reference in New Issue
Block a user