searchindex.en.js

var relearn_searchindex = [
  {
    "breadcrumb": "VMC Project \u003e Installation \u003e Installing and Running Examples",
    "content": "Overview of the available options for building VMC examples and their default values:\nVMC_WITH_Geant4 Build with Geant4 OFF VMC_WITH_Geant3 Build with Geant3 OFF VMC_WITH_Multi Build with multiple engines OFF VMC_INSTALL_EXAMPLES Install examples libraries and programs ON Geant4 VMC build options are automatically exported in Geant4VMCConfig.cmake. If Geant4 VMC was built with VGM, the VGM installation path has to be provided via -DVGM_DIR option.",
    "description": "Overview of the available options for building VMC examples and their default values:\nVMC_WITH_Geant4 Build with Geant4 OFF VMC_WITH_Geant3 Build with Geant3 OFF VMC_WITH_Multi Build with multiple engines OFF VMC_INSTALL_EXAMPLES Install examples libraries and programs ON Geant4 VMC build options are automatically exported in Geant4VMCConfig.cmake. If Geant4 VMC was built with VGM, the VGM installation path has to be provided via -DVGM_DIR option.",
    "tags": [],
    "title": "Build Options",
    "uri": "/installation/examples/build-options/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Installation \u003e Installing Geant4 VMC",
    "content": "Geant4 VMC includes the G4Root package and examples, which are independent from Geant4 VMC and can be build and used stand-alone. Use of G4Root, VGM, Geant4 G3toG4, UI and VIS packages in Geant4 VMC library is optional and can be switched on/off during CMake build.\nOverview of available options and their default values:\nGeant4VMC_BUILD_G4Root Build G4Root ON Geant4VMC_BUILD_MTRoot Build MTRoot ON Geant4VMC_BUILD_Geant4VMC Build Geant4VMC ON Geant4VMC_BUILD_EXAMPLES Build VMC examples ON Geant4VMC_USE_G4Root Build with G4Root ON Geant4VMC_USE_VGM Build with VGM OFF Geant4VMC_USE_GEANT4_UI Build with Geant4 UI drivers ON Geant4VMC_USE_GEANT4_VIS Build with Geant4 Vis drivers ON Geant4VMC_USE_GEANT4_G3TOG4 Build with Geant4 G3toG4 library OFF Geant4VMC_INSTALL_EXAMPLES Install examples ON",
    "description": "Geant4 VMC includes the G4Root package and examples, which are independent from Geant4 VMC and can be build and used stand-alone. Use of G4Root, VGM, Geant4 G3toG4, UI and VIS packages in Geant4 VMC library is optional and can be switched on/off during CMake build.\nOverview of available options and their default values:\nGeant4VMC_BUILD_G4Root Build G4Root ON Geant4VMC_BUILD_MTRoot Build MTRoot ON Geant4VMC_BUILD_Geant4VMC Build Geant4VMC ON Geant4VMC_BUILD_EXAMPLES Build VMC examples ON Geant4VMC_USE_G4Root Build with G4Root ON Geant4VMC_USE_VGM Build with VGM OFF Geant4VMC_USE_GEANT4_UI Build with Geant4 UI drivers ON Geant4VMC_USE_GEANT4_VIS Build with Geant4 Vis drivers ON Geant4VMC_USE_GEANT4_G3TOG4 Build with Geant4 G3toG4 library OFF Geant4VMC_INSTALL_EXAMPLES Install examples ON",
    "tags": [],
    "title": "Build Options",
    "uri": "/installation/geant4_vmc/build-options/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Installation \u003e Installing and Running Examples",
    "content": "The following instructions apply only to 3.00.b01 (beta) version and are kept for reference purpose only. For the production version (3.0) see Installing and Running Examples page. Since Geant4 VMC 3.0.x, there are also provided examples main programs which can be built with either shared or static libraries of all packages. Building with static libraries can make execution faster, especially when running in multi-threaded mode, than when running with dynamic loading of shared libraries in a \"traditional\" way. The programs can be built using CMake in a standard way. The CMake configuration files, CMakeLists.txt, provided within examples are defined with use of a generic configuration files UseVMC.cmake and FindVMC.cmake, provided in geant4_vmc/cmake directory together with other Find modules for all used packages. FindVMC.cmake is used to find all used packages which selection is made by the user via the CMake options defined in this file. Build with Geant4: cd geant4_vmc mkdir examples_build_g4 cd examples_build_g4 cmake \\ -DGeant4VMC_DIR=/my_path/geant4_vmc \\ -DWITH_GEANT4=ON \\ -DWITH_MTROOT=ON \\ -DWITH_VGM=ON \\ ../examples make -jN Build with Geant3: (Note that WITH_GEANT4 option has to be set OFF explicitly, as its default is ON.)\ncd geant4_vmc mkdir examples_build_g3 cd examples_build_g3 cmake \\ -DGeant4VMC_DIR=/my_path/geant4_vmc \\ -DGeant3VMC_DIR=/my_path/geant3 \\ -DWITH_GEANT4=OFF \\ -DWITH_GEANT3=ON \\ -DWITH_MTROOT=ON \\ ../examples make -jN The example can be then run by calling the executable in the build directory: cd geant4_vmc/examples/E01 ../../examples_build_g4/E01/exampleE01 For keeping maximum simplicity of the code, a fixed configuration is defined in the examples main() function. More flexible version of the main() function is provided in the test programs which default configuration options can be changed by running the program with selected command line options, eg. testE01 [-g4g, --g4-geometry] Geant4 VMC geometry option [-g4pl, --g4-physics-list] Geant4 physics list selection [-g4sp, --g4-special-physics] Geant4 special physics selection [-g4m, --g4-macro] Geant4 macro [-g4vm, --g4-vis-macro] Geant4 visualization macro [-g3g, --g3-geometry] Geant3 geometry option (TGeant3,TGeant3TGeo) [-r4m, --root-macro] Root macro [-v, --verbose] verbose option (yes,no) Note that the g4* and g3* options are available only when the program was built with the corresponding WITH_GEANT3 or WITH_GEANT3 option. Root macro with arguments has to be passed in a single string, eg.: --root-macro 'test_E01.C(\"\",kFALSE)'",
    "description": "The following instructions apply only to 3.00.b01 (beta) version and are kept for reference purpose only. For the production version (3.0) see Installing and Running Examples page. Since Geant4 VMC 3.0.x, there are also provided examples main programs which can be built with either shared or static libraries of all packages. Building with static libraries can make execution faster, especially when running in multi-threaded mode, than when running with dynamic loading of shared libraries in a \"traditional\" way.",
    "tags": [],
    "title": "Building examples application programs - With 3.00.b01",
    "uri": "/installation/examples/examples-old/index.html"
  },
  {
    "breadcrumb": "VMC Project",
    "content": "The VMC packages sources are available from the vmc-project organization in GitHub. See the detailed instructions in the next sections.\nVMC Geant4 VMC Geant3 Tar Files",
    "description": "The VMC packages sources are available from the vmc-project organization in GitHub. See the detailed instructions in the next sections.\nVMC Geant4 VMC Geant3 Tar Files",
    "tags": [],
    "title": "Download",
    "uri": "/download/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Geant4 VMC",
    "content": "Geometry definition The VMC supports two ways of geometry definition:\nvia Root geometry package (TGeo) via TVirtualMC interface (historically the first way) The first (newer) way is recommended for new users, the way via VMC is kept for a backward compatibility.\nSince the version 2.0, user can choose between Geant4 native navigation and G4Root navigation, if geometry is define via TGeo. The choice of the navigation is done via the option specified with creating TG4RunConfiguration object (see VMC examples for more details):\ngeomVMCtoGeant4 - geometry defined via VMC, G4 native navigation geomVMCtoRoot - geometry defined via VMC, Root navigation geomRoot - geometry defined via Root, Root navigation geomRootToGeant4 - geometry defined via Root, G4 native navigation geomGeant4 - geometry defined via Geant4, G4 native navigation Below we shortly comment the implementation of these options:\ngeomVMCtoGeant4: The interfaces to functions for geometry definitions provided by VMC were strongly inspired by Geant3; the implementation of these functions in Geant4 VMC is therefore made with use of the G3toG4 tool provided by Geant4.\ngeomVMCtoRoot: The implementation of this option uses TGeoMCGeometry provided in the root/vmc package. The same class is used also by TGeant3TGeo and TFluka for supporting user geometry defined via VMC.\ngeomRoot: If geometry is defined via Root and G4Root navigation is selected, Geant4 VMC only converts the parameters defined in TGeoMedium objects to Geant4 objects.\ngeomRootToGeant4: The geometry defined via TGeo is converted in Geant4 geometry using the external Virtual Geometry Model (VGM), which has replaced the old one-way converters from Geant4 VMC (G4toXML, RootToG4), removed from Geant4 VMC with the version 1.7. In the VGM, these convertors has been generalized and improved.\ngeomGeant4: User Geant4 detector construction class can be passed to Geant4 VMC via user defined run configuration class (see User Geant4 Classes). If Geant4 VMC is built with VGM, geometry can be exported in Root using the built-in command:\n/vgm/generateRoot and reused in Geant3 or Fluka (when available) VMC simulation.\nUseful commands Geant4 VMC implements various commands which allow users to get more information about their application setup:\n/mcDet/printMaterials /mcDet/printMaterialsProperties /mcDet/printMedia /mcDet/printVolumes prints materials, material properties, tracking media, volumes\nIn Geant4 VMC, there is by default set a step limit 10 cm for all materials with density lower than 0.001 g/cm3. This default setting can be overridden via the following commands:\n/mcDet/setLimitDensity 1.e-6 g/cm3 /mcDet/setMaxStepInLowDensityMaterials 1 mm How to apply Geant4 commands in a Root user session is explained at the section on Switching User Interfaces.\nGeometry in XML The VGM provides also the XML exporters which enable to generate XML files with geometry description in the AGDD or GDML formats. If Geant4 VMC is compiled with USE_VGM option, geometry can be exported to XML using the built-in commands:\n/vgm/generateAGDD [volumeName] /vgm/generateGDML [volumeName] If volumeName is not specified, the whole geometry volume tree is exported. The geometry can be then browsed and visualized using GraXML tool.\n“MANY” positions As Geant4 does not support overlapping geometries, the positions with MANY option are not allowed with Geant4 navigation.\nIn case of geomVMCtoGeant4 option, user has a possibility to identify all ONLY volumes that overlap with the MANY ones using TVirtualMC::Gsbool() function for each overlap. This info is then used to perform automatically Boolean operations on the concerned solids. The volume with a “MANY” position can have only this position if Gsbool is used.\nIn case of geomRootToGeant4 option, the MANY option is ignored and if present in geometry, Gean4 geometry will be incorrect.\nThere is no limitation on use of the MANY option with G4Root navigation (options geomVMCtoRoot, geomRoot).",
    "description": "Geometry definition The VMC supports two ways of geometry definition:\nvia Root geometry package (TGeo) via TVirtualMC interface (historically the first way) The first (newer) way is recommended for new users, the way via VMC is kept for a backward compatibility.\nSince the version 2.0, user can choose between Geant4 native navigation and G4Root navigation, if geometry is define via TGeo. The choice of the navigation is done via the option specified with creating TG4RunConfiguration object (see VMC examples for more details):",
    "tags": [],
    "title": "Geometry Definition \u0026 Navigation",
    "uri": "/user-guide/geant4_vmc/geometry-definition-navigation/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Installation \u003e Installing Geant3",
    "content": "The following instructions apply to the installation of the versions \u003c 2.0.\nFirst get the Geant3 source from the Download page. No special configuration option for Root installation is needed with the actual version of Root. With old Root v5.20/00, you have to specify your Fortran compiler: --with-f77=g77   geant3 requires Pythia6 library. You can follow ROOT installation instructions or directly the Pythia site.   To install geant3:\ncd geant3 make",
    "description": "The following instructions apply to the installation of the versions \u003c 2.0.\nFirst get the Geant3 source from the Download page. No special configuration option for Root installation is needed with the actual version of Root. With old Root v5.20/00, you have to specify your Fortran compiler: --with-f77=g77   geant3 requires Pythia6 library. You can follow ROOT installation instructions or directly the Pythia site.   To install geant3:\ncd geant3 make",
    "tags": [],
    "title": "Installing Geant3 - Older Versions",
    "uri": "/installation/geant3/geant3-old/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Installation \u003e Installing Geant4 VMC",
    "content": "The following instructions apply to the installation of versions \u003c 3.0. For the required configurations of Root and Geant4 for these older versions see Special installations page. Getting source First get the Geant4 VMC source from the Download page. Root configuration Since the version 2.9 there are no special configuration options for Root needed. The path to Root installation can be defined in two complementary ways:\na) With the environment variable ROOTSYS: ROOTSYS ... path to Root b) With the Root configuration script root-config ... Root configuration script Note that if the ROOTSYS environment variable is defined the root-config script is not used. For the older geant4_vmc versions (2.x - 2.8) see below. Geant4 configuration (with CMake) To install Geant4 - download the source from Geant4 Download page and follow the Geant4 Installation Guide together with the tips relevant to using it with VMC described below. Geant4 installation options: G3toG4 tool The G3toG4 package is used in geant4_vmc to support geometry definition via VMC with Geant4 native navigation (geomVMCtoGeant4 option). It is required by default. As the G3toG4 package is optional its build has to be activated when building Geant4 by the following CMake options: -DGEANT4_USE_G3TOG4=ON Since the version 2.14, the user applications which build geometry via Root (or Geant4), can be built with Geant4 installed without G3toG4 package. The G3toG4 dependent code in geant4_vmc has to be then inactivated by setting the following environment variable: NO_G3TOG4 ... set to 1 to disable the code dependent on G3toG4 If this variable is set the geomVMCtoGeant4 option is unavailable. \u003cli\u003e\u003cb\u003eOpenGL visualization \u003c/b\u003e \u003cbr\u003e It is recommended to build Geant4 X11 OpenGL visualization driver used in the VMC examples. It is handled in Geant4 CMake build via the following CMake option:\n-DGEANT4_USE_OPENGL_X11=ON Multi-threading Geant4 VMC can be built against Geant4 installation in multi-threading mode (with -DG4MULTITHREADED cmake option). Dynamic loading of Geant4 libraries, as used in VMC, requires to change the Geant4 default option (defined in geant4/cmake/Modules/Geant4MakeRules_cxx.cmake) -ftls-model=initial-exec with -ftls-model=global-dynamic Geant4 VMC 2.15x version is not migrated to Geant4 multi-threading and it can be built against both Geant4 sequential and Geant4 multi-threading installations. The Geant4 MT installation requires -ftls-model=global-dynamic model. The VMC application will run in a sequential mode in both cases. Geant4 VMC 3.00.x version is migrated to Geant4 multi-threading and can be built against both Geant4 sequential and Geant4 multi-threading installations. The -ftls-model=global-dynamic model is required for running VMC applications from Root session (in a \"traditional\" way with dynamic loading of libraries). Since 3.00.x version, CMake configuration files are provided to build VMC application main program linked with all libraries, Geant4 built with -ftls-model=initial-exec model (default) can be then used. Only VMC applications which are migrated to multi-threading mode can be built and run against Geant4 multi-threading installation. Non migrated application have to be built against Geant4 sequential installation. The path to the Geant4 installation is defined with the Geant4 configuration script: geant4-config ... Geant4 configuration script To make Geant4 binaries (geant4-config) and libraries available on your PATH and library path (LD_LIBRARY_PATH on Linux, DYLD_LIBRARY_PATH on Mac OS X), you should source the relevant script from your Geant4 installation (CMAKE_INSTALL_PREFIX): $ . bin/geant4.sh ... on bourne shells (eg. bash) or $ source bin/geant4.csh ... on C shells Note that the G4INSTALL environment variable should NOT be set in this case as it would trigger building geant4_vmc against the Geant4 configuration via GNUmake build. VGM (optional) Since the version 2.0, you can choose to run Geant4 with the Geant4 native geometry navigation or the G4Root navigation. To run with the Geant4 native geometry navigation in case your geometry is defined via the Root geometry package, you will have to install the Virtual Geometry Model (VGM) package. See the VGM Web site how to do it. VGM is used in Geant4 VMC for a geometry in memory conversion from Root TGeo objects to the Geant4 native geometry. More details about this can be found at the page on geometry definition and navigation. The following environment variables that defines the paths to used systems have to be set: VGM_INSTALL ... path to VGM USE_VGM ... set to 1 to build VGM dependent code \u003c/li\u003e \u003cli\u003e \u003ch3\u003e Geant4 VMC \u003c/h3\u003e For the versions (2.9 - 2.15x), to install geant4_vmc: cd geant4_vmc make This will build g4root, geant4_vmc and VMC examples. For the older versions (2.x - 2.8) of geant4_vmc: cd geant4_vmc/source make VMC Examples The examples are provided within geant4_vmc package; to build all available examples: cd geant4_vmc/examples make",
    "description": "The following instructions apply to the installation of versions \u003c 3.0. For the required configurations of Root and Geant4 for these older versions see Special installations page. Getting source First get the Geant4 VMC source from the Download page. Root configuration Since the version 2.9 there are no special configuration options for Root needed. The path to Root installation can be defined in two complementary ways:\na) With the environment variable ROOTSYS: ROOTSYS ... path to Root b) With the Root configuration script root-config ... Root configuration script Note that if the ROOTSYS environment variable is defined the root-config script is not used. For the older geant4_vmc versions (2.x - 2.8) see below. Geant4 configuration (with CMake) To install Geant4 - download the source from Geant4 Download page and follow the Geant4 Installation Guide together with the tips relevant to using it with VMC described below. Geant4 installation options: G3toG4 tool The G3toG4 package is used in geant4_vmc to support geometry definition via VMC with Geant4 native navigation (geomVMCtoGeant4 option). It is required by default. As the G3toG4 package is optional its build has to be activated when building Geant4 by the following CMake options: -DGEANT4_USE_G3TOG4=ON Since the version 2.14, the user applications which build geometry via Root (or Geant4), can be built with Geant4 installed without G3toG4 package. The G3toG4 dependent code in geant4_vmc has to be then inactivated by setting the following environment variable: NO_G3TOG4 ... set to 1 to disable the code dependent on G3toG4 If this variable is set the geomVMCtoGeant4 option is unavailable. \u003cli\u003e\u003cb\u003eOpenGL visualization \u003c/b\u003e \u003cbr\u003e It is recommended to build Geant4 X11 OpenGL visualization driver used in the VMC examples. It is handled in Geant4 CMake build via the following CMake option:\n-DGEANT4_USE_OPENGL_X11=ON",
    "tags": [],
    "title": "Installing Geant4 VMC - Older Versions",
    "uri": "/installation/geant4_vmc/geant4_vmc-old/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Installation",
    "content": "VMC requires ROOT.\nThe vmc core package was separated from the ROOT source into a new stand-alone vmc package in the GitHub vmc-project organization. The motivation for this step was a gain in flexibility and faster workflow for new developments of multiple engine mode. The vmc package in ROOT is deprecated since ROOT version 6.18 (its compilation is optional) and it is going to be removed in the next ROOT version, 6.26. The VMC stand-alone is then needed for building Geant3 and Geant4 VMC when using ROOT compiled with the vmc disabled (default).\nVMC uses CMake to configure a build system for compiling and installing the headers, libraries and Cmake configuration files. To install VMC:\nFirst get the VMC source from the Download page. We will assume that the VMC package sits in a subdirectory /mypath/vmc Create build directory alongside our source directory $ cd /mypath $ mkdir vmc_build $ ls vmc vmc_build To configure the build, change into the build directory and run CMake: $ cd /mypath/vmc_build $ cmake -DCMAKE_INSTALL_PREFIX=/mypath/vmc_install /mypath/vmc If ROOT environment was defined using thisroot.{c}sh script, there is no need to provide the path to its installation. Otherwise, they can be provided using -DROOT_DIR cmake option.\nThe VMC core is built by default in RelWithDebInfo build mode (Optimized build with debugging symbols). This default can be changed via the standard CMake option CMAKE_BUILD_TYPE. The other useful values are Release : Optimized build, no debugging symbols Debug : Debugging symbols, no optimization After the configuration has run, CMake will have generated Unix Makefiles for building VMC. To run the build, simply execute make in the build directory: $ make -jN where N is the number of parallel jobs you require (e.g. if your machine has a dual core processor, you could set N to 2).\nIf you need more output to help resolve issues or simply for information, run make as $ make -jN VERBOSE=1 Once the build has completed, you can install VMC to the directory you specified earlier in CMAKE_INSTALL_PREFIX by running $ make install",
    "description": "VMC requires ROOT.\nThe vmc core package was separated from the ROOT source into a new stand-alone vmc package in the GitHub vmc-project organization. The motivation for this step was a gain in flexibility and faster workflow for new developments of multiple engine mode. The vmc package in ROOT is deprecated since ROOT version 6.18 (its compilation is optional) and it is going to be removed in the next ROOT version, 6.26. The VMC stand-alone is then needed for building Geant3 and Geant4 VMC when using ROOT compiled with the vmc disabled (default).",
    "tags": [],
    "title": "Installing VMC",
    "uri": "/installation/vmc/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide",
    "content": "This chapter presents the VMC concept, and gives an overview of the packages provided in vmc-project.\nVMC Concept VMC Project",
    "description": "This chapter presents the VMC concept, and gives an overview of the packages provided in vmc-project.\nVMC Concept VMC Project",
    "tags": [],
    "title": "Introduction",
    "uri": "/user-guide/introduction/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Geant4 VMC",
    "content": "The user magnetic field is in VMC defined via TVirtualMagField interface and then set to VMC using TVirtualMC::SetMagField(TVirtualMagField*) function. The propagation of tracks inside the magnetic field in Geant4 can be performed to a user-defined accuracy. See more details in the Electromagnetic Field section in the Geant4 User Guide for Application Developers. Note that while Geant4 allows magnetic, electric and electromagnetic fields, the VMC is currently limited to magnetic fields only.\nLocal fields Since Geant4 VMC version 3.2, it is possible to define local magnetic fields. The local field is defined in the same way as a global field, via TVirtualMagField interface, but then it has to be associated with a selected volume using TGeoVolume::SetField(TObject*) function. The local magnetic field is applied also to all volume daughters, it is possible to combine a global field with one or more local fields. Note that the local fields are supported only with Geant4 and an equivalent global magnetic field has to be provided for Geant3 simulation.\nThe local fields defined in Root geometry are not taken into account automatically (to avoid unnecessary processing of the volume tree in applications which do not define local magnetic fields) and their usage has to be activated via:\n/mcDet/setIsLocalMagField true Since Geant4 VMC version 3.5, it is possible to propagate the zero magnetic field defined in tracking media in Geant4 geometry. A local zero magnetic field is set to all logical volumes associated with the tracking medium with ‘ifield = 0’ if a global magnetic field is defined. This feature (not switched on by default) can be activated via:\n/mcDet/setIsZeroMagField true Customization of Field Parameters Since Geant4 11.3, the UI commands to customize the default integration method and the default accuracy parameters with a set of dedicated commands were integrated in Geant4 and removed from Geant4 VMC.\nPlease, refer to the Creating a Field for a Detector section in Geant4 Applicator Developer Guide.\nThe commands described below are available in the /field/ command directory.\nCustomization of Field Parameters (OLD) In Geant4 VMC versions before 6.7, user can customize the default integration method and the default accuracy parameters with a set of dedicated commands. It is a user responsibility to choose the type of equation of motion and the integration method compatible with the user field. (The defined commands are not limited to magnetic field only in order to make easier an eventual future extension of VMC to electric and electromagnetic fields.)\nThe available commands:\nSelect the integrator (stepper) of particle’s equation of motion; the default stepper is G4ClassicalRK4:\n/mcMagField/stepperType stepperType Select the type of equation of motion of a particle in a field; the default is G4Mag_UsualEqRhs:\n/mcMagField/equationType eqType Set the accuracy parameters delta intersection and delta one step of the G4 Field Manager. The default values in Geant4 are 0.001mm and 0.01mm respectively.\n/mcMagField/setDeltaIntersection value [unit] /mcMagField/setDeltaOneStep value [unit] Set the step minimum and delta chord parameters to G4 Chord Finder. The default values in Geant4 are 0.01mm and 0.25mm respectively.:\n/mcMagField/setStepMinimum value [unit] /mcMagField/setDeltaChord value [unit] Set the MinimumEpsilonStep and the MaximumEpsilonStep parameters of the G4 Field Manager. The default values in Geant4 are 5.0e-5 and 0.001 respectively.\n/mcMagField/setMinimumEpsilonStep value /mcMagField/setMaximumEpsilonStep value Activate utilizing of a “cached magnetic field” (available since version 3.2) . The cached field value (the value from a previous call) is returned in case a new call is performed for a point which distance from a previous one is smaller than the value of the “ConstDistance” parameter.\n/mcMagField/setConstDistance value [unit] To customize local field parameters, a command directory for the local field has to be created first using:\n/mcDet/createMagFieldParameters volumeName The same commands as for a global field are then available under this directory:\n/mcMagField/volumeName/stepperType stepperType /mcMagField/volumeName/equationType eqType ... Since Geant4 VMC version 3.2, users can also provide their own magnetic field equation of motion and/or its integrator. These objects should be instantiated in a detector construction class derived from TG4DetConstruction or post-detector construction class derived from TG4VUserPostDetConstruction if using ROOT navigation. This use case is demonstrated in the E03 example in Ex03PostDetConstruction and Ex03RunConfiguration4 classes. How to include user Geant4 classes in a VMC application is explained at the section on User Geant4 classes.\nControl of the parameters for killing looping particles Since Geant4 10.5, users can change the thresholds for killing ‘looping’ tracks, which criteria can be used to ensure that a track continues to propagate and for how many steps an ‘important’ track that is ‘looping’ can survive (see more details in Transportation in Magnetic Field - Further Details section in Geant4 Guide for Application Developers).\nThe following UI commands were introduced in Geant4 VMC development version, and back-ported to Geant4 VMC 5.0.p5, for this control.\nThe commands for using preset thresholds for killing loopers:\n/mcPhysics/useLowLooperThresholds /mcPhysics/useHighLooperThresholds The commands for modifying the parameters for killing looping particles\n/mcRun/setLooperThresholdWarningEnergy value unit /mcRun/setLooperThresholImportantEnergy value unit /mcRun/setNumberOfLooperThresholdTrials value These commands must be called before the run initialization, so that Geant4 VMC performs the setting at the right time.\nHow to apply Geant4 commands in a Root user session is explained at the section on Switching User Interfaces.",
    "description": "The user magnetic field is in VMC defined via TVirtualMagField interface and then set to VMC using TVirtualMC::SetMagField(TVirtualMagField*) function. The propagation of tracks inside the magnetic field in Geant4 can be performed to a user-defined accuracy. See more details in the Electromagnetic Field section in the Geant4 User Guide for Application Developers. Note that while Geant4 allows magnetic, electric and electromagnetic fields, the VMC is currently limited to magnetic fields only.\nLocal fields Since Geant4 VMC version 3.2, it is possible to define local magnetic fields. The local field is defined in the same way as a global field, via TVirtualMagField interface, but then it has to be associated with a selected volume using TGeoVolume::SetField(TObject*) function. The local magnetic field is applied also to all volume daughters, it is possible to combine a global field with one or more local fields. Note that the local fields are supported only with Geant4 and an equivalent global magnetic field has to be provided for Geant3 simulation.",
    "tags": [],
    "title": "Magnetic Field",
    "uri": "/user-guide/geant4_vmc/magnetic-field/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Support",
    "content": "The mailing list is used to keep you up to date about new developments in VMC packages, releases and bug fixes. This list is also used to discuss use of VMC with other users and with the developers. If you want to report a bug, please, use Bug Reports.\nTo join the root-vmc@cern.ch mailing list, do the following:\nIf you don’t have a CERN account, create a light weight CERN account. Add yourself to the root-vmc mailing list, by clicking on the “Members” tab and then on the “Add me” button. To remove yourself from the mailing list click on the “Remove me” button on the same above “Members” page. Mailing list archive: VMC Digest",
    "description": "The mailing list is used to keep you up to date about new developments in VMC packages, releases and bug fixes. This list is also used to discuss use of VMC with other users and with the developers. If you want to report a bug, please, use Bug Reports.\nTo join the root-vmc@cern.ch mailing list, do the following:\nIf you don’t have a CERN account, create a light weight CERN account. Add yourself to the root-vmc mailing list, by clicking on the “Members” tab and then on the “Add me” button. To remove yourself from the mailing list click on the “Remove me” button on the same above “Members” page. Mailing list archive: VMC Digest",
    "tags": [],
    "title": "Mailing List",
    "uri": "/support/mailing-list/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Publications",
    "content": "Please refer to the paper below when publishing results base on simulations with VMC:\nInfo Reference paper\nHřivnáčová I et al: The Virtual MonteCarlo,\nECONF C0303241:THJT006,2003; e-Print: cs.SE/0306005\nAll publications listed in time reversed order:\nNew Developments in the VMC Project,\nI Hřivnáčová, B Volkel 2020 EPJ Web Conf. Volume 245 02005\ndoi: 10.1051/epjconf/202024502005\nUsing multiple engines in the Virtual Monte Carlo package,\nB Volkel et al 2020 EPJ Web Conf. Volume 245 02008\ndoi: 10.1051/epjconf/202024502008\nGeant4 VMC 3.0,\nI Hřivnáčová, A Gheata 2015 J. Phys.: Conf. Ser. 664 072020\ndoi: 10.1088 /1742-6596/664/7/072020\nThe Geant4 Virtual Monte Carlo,\nI Hřivnáčová 2012 J. Phys.: Conf. Ser. 396 022024\ndoi:10.1088 /1742-6596/119/3/032025\nPhysics lists in Geant4 VMC,\npresentation at ALICE-FAIR Computing Meeting, 28-29 April 2008, GSI\nThe Geant4 Virtual Monte Carlo,\nI Hřivnáčová 2008 J. Phys.: Conf. Ser. 119 032025\ndoi: 10.1088 /1742-6596/119/3/032025\nFLUKA and the Virtual Monte Carlo,\nA. Morsch - presentation at CHEP 2006, 13-17th February 2006, Mumbai, India\nThe Virtual MonteCarlo: status and applications,\nR. Brun et al - presentation at CHEP 2004, 27 September 2004 to 01 October 2004, Interlaken, Switzerland\nThe Virtual MonteCarlo,\nHřivnáčová I et al 2003 Proc. of Computing in High Energy and Nuclear Physics (La Jolla) pp THJT006\nECONF C0303241:THJT006,2003; e-Print: cs.SE/0306005\n(Reference paper)",
    "description": "Please refer to the paper below when publishing results base on simulations with VMC:\nInfo Reference paper\nHřivnáčová I et al: The Virtual MonteCarlo,\nECONF C0303241:THJT006,2003; e-Print: cs.SE/0306005\nAll publications listed in time reversed order:\nNew Developments in the VMC Project,\nI Hřivnáčová, B Volkel 2020 EPJ Web Conf. Volume 245 02005\ndoi: 10.1051/epjconf/202024502005\nUsing multiple engines in the Virtual Monte Carlo package,\nB Volkel et al 2020 EPJ Web Conf. Volume 245 02008\ndoi: 10.1051/epjconf/202024502008",
    "tags": [],
    "title": "Publications List",
    "uri": "/publications/publications-list/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Installation \u003e Installing and Running Examples",
    "content": "First, make sure that you have included all libraries paths in your shared library path.\nFor all MCs:\n/your_path/root_install/lib /your_path/vmc_install/lib For Geant3 only:\npath to Pythia6 library /your_path/geant3_install/lib[64] /your_path/examples_install_g3/lib[64] For Geant4 only:\n/your_path/geant4_install/lib[64] /your_path/geant4_vmc_install/lib[64] /your_path/examples_install_g4/lib[64] Running examples from Root session The example can be run by calling the provided macros from Root session:\n$ cd geant4_vmc/examples/E01 $ root root[0] .x load_g4.C # load all libraries needed to run with Geant4 root[1] .x run_g4.C # run with Geant4 or root[0] .x load_g3.C # load all libraries needed to run with Geant3 root[1] .x run_g3.C # run with Geant3 Running examples application programs The example can be also run by calling the executable from the examples installation directory:\n$ cd geant4_vmc/examples/E01 $ /mypath/examples_install_g4/bin/g4vmc_exampleE01 For keeping maximum simplicity of the code, a fixed configuration is defined in the examples main() function. More flexible version of the main() function is provided in the test programs which default configuration options can be changed by running the program with selected command line options, eg.\n$ g4vmc_testE01 [-g4g, --g4-geometry] Geant4 VMC geometry option [-g4pl, --g4-physics-list] Geant4 physics list selection [-g4sp, --g4-special-physics] Geant4 special physics selection [-g4m, --g4-macro] Geant4 macro [-g4vm, --g4-vis-macro] Geant4 visualization macro [-r4m, --root-macro] Root macro [-v, --verbose] verbose option (yes,no) or\n$ g3vmc_testE01 [-g3g, --g3-geometry] Geant3 geometry option [-r4m, --root-macro] Root macro [-v, --verbose] verbose option (yes,no) Note that the g4* and g3* options are available only when the program was built with the corresponding VMC_WITH_Geant4 or VMC_WITH_Geant3 option. Root macro with arguments has to be passed in a single string, eg.:\n--root-macro 'test_E01.C(\"\",kFALSE)'",
    "description": "First, make sure that you have included all libraries paths in your shared library path.\nFor all MCs:\n/your_path/root_install/lib /your_path/vmc_install/lib For Geant3 only:\npath to Pythia6 library /your_path/geant3_install/lib[64] /your_path/examples_install_g3/lib[64] For Geant4 only:\n/your_path/geant4_install/lib[64] /your_path/geant4_vmc_install/lib[64] /your_path/examples_install_g4/lib[64] Running examples from Root session The example can be run by calling the provided macros from Root session:\n$ cd geant4_vmc/examples/E01 $ root root[0] .x load_g4.C # load all libraries needed to run with Geant4 root[1] .x run_g4.C # run with Geant4 or root[0] .x load_g3.C # load all libraries needed to run with Geant3 root[1] .x run_g3.C # run with Geant3 Running examples application programs The example can be also run by calling the executable from the examples installation directory:",
    "tags": [],
    "title": "Running examples",
    "uri": "/installation/examples/running-examples/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Introduction",
    "content": "The Virtual Monte Carlo (VMC) allows to run different simulation Monte Carlo without changing the user code and therefore the input and output format as well as the geometry and detector response definition.\nThe core of the VMC is the category of classes vmc. It provides a set of interfaces which completely decouple the dependencies between the user code and the concrete Monte Carlo, two of which have the key role:\nTVirtualMC: Interface to the concrete Monte Carlo program TVirtualMCApplication: Interface to the user’s Monte Carlo application The implementation of the TVirtualMC interface is provided for two Monte Carlo transport codes, GEANT3 and Geant4, with the VMC packages listed below. The implementation for the third Monte Carlo transport code, FLUKA, has been discontinued by the FLUKA team in 2010.\nThe other interfaces are implemented in the user application. The user VMC application is independent from concrete transport codes (GEANT3, Geant4, FLUKA). The transport code which will be used for simulation is selected at run time - when processing a ROOT macro where the concrete Monte Carlo is instantiated.\nVMC and TGeo The VMC is fully integrated with the Root geometry package, TGeo, and users can easily define their VMC application with TGeo geometry and this way of geometry definition is recommended for new users.\nIt is also possible to define geometry via Geant3-like functions defined in the VMC interface, however this way is kept only for backward compatibility and should not be used by new VMC users.\nMultiple VMCs Since the development version the simulation can be shared among multiple different engines deriving from TVirtualMC which are handled by a singleton TMCManager object.\nSee more detailed description in the dedicated section.",
    "description": "The Virtual Monte Carlo (VMC) allows to run different simulation Monte Carlo without changing the user code and therefore the input and output format as well as the geometry and detector response definition.\nThe core of the VMC is the category of classes vmc. It provides a set of interfaces which completely decouple the dependencies between the user code and the concrete Monte Carlo, two of which have the key role:",
    "tags": [],
    "title": "VMC Concept",
    "uri": "/user-guide/introduction/vmc-concept/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Examples",
    "content": "A set of examples of usage of VMC is included in geant4_vmc.\nThough provided within Geant4 VMC, they can be built independently and do not require Geant4 installation in case you want to run them with GEANT3 only.\nSee more details on the VMC Examples web page.",
    "description": "A set of examples of usage of VMC is included in geant4_vmc.\nThough provided within Geant4 VMC, they can be built independently and do not require Geant4 installation in case you want to run them with GEANT3 only.\nSee more details on the VMC Examples web page.",
    "tags": [],
    "title": "VMC Examples",
    "uri": "/examples/vmc-examples/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Introduction",
    "content": "The vmc-project GitGub organization provides the following packages:\nvmc -\u003e The core of the VMC provides the interfaces and classes independent from the Monte Carlo transport code.\nSee more in the VMC Core section.\ngeant3 -\u003e The updated version of Geant3.21 that includes several bug fixes compared to the standard version in CERNLIB. The directory TGeant3 contains the classes which implement the TVirtualMC interface for Geant3\nSee more in the Geant3 section.\ngeant4_vmc -\u003e Geant4 VMC contains the classes which implement the TVirtualMC interface for Geant4.\nFor historical reasons, it also includes the G4Root package, which is independent from Geant4 VMC and can be built and used stand-alone, and VMC Examples, that can also be built independently and do not require Geant4 installation in case you want to run them with GEANT3.\nSee more in the Geant4 VMC, G4Root and Examples sections.\nOther packages In addition to these VMC packages, the vmc-project includes also the geometry conversion tool VGM and the VMC and VGM documentation repositories.",
    "description": "The vmc-project GitGub organization provides the following packages:\nvmc -\u003e The core of the VMC provides the interfaces and classes independent from the Monte Carlo transport code.\nSee more in the VMC Core section.\ngeant3 -\u003e The updated version of Geant3.21 that includes several bug fixes compared to the standard version in CERNLIB. The directory TGeant3 contains the classes which implement the TVirtualMC interface for Geant3\nSee more in the Geant3 section.\ngeant4_vmc -\u003e Geant4 VMC contains the classes which implement the TVirtualMC interface for Geant4.",
    "tags": [],
    "title": "VMC Project",
    "uri": "/user-guide/introduction/vmc-project/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Support",
    "content": "We use JIRA to track bugs and to gather feature requests.\nReport a bug in VMC packages.",
    "description": "We use JIRA to track bugs and to gather feature requests.\nReport a bug in VMC packages.",
    "tags": [],
    "title": "Bug Reports",
    "uri": "/support/bug-reports/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Examples",
    "content": "VMC was developed by the ALICE Software Project and, since then it was adopted by other experiment frameworks.\nALICE AliRoot - the ALICE software framework (for LHC Run 1 and 2) O2 - the new ALICE software framework in development (for LHC Run 3 and 4) FAIR FairRoot - A simulation, reconstruction and analysis framework, based on the ROOT system, for FAIR experiments",
    "description": "VMC was developed by the ALICE Software Project and, since then it was adopted by other experiment frameworks.\nALICE AliRoot - the ALICE software framework (for LHC Run 1 and 2) O2 - the new ALICE software framework in development (for LHC Run 3 and 4) FAIR FairRoot - A simulation, reconstruction and analysis framework, based on the ROOT system, for FAIR experiments",
    "tags": [],
    "title": "Experiment Frameworks",
    "uri": "/examples/experiment-frameworks/index.html"
  },
  {
    "breadcrumb": "VMC Project",
    "content": "Installing VMC Installing Geant4 VMC Build Options Required and Optional Packages Installing Geant3 Installing and Running Examples Build Options Running examples",
    "description": "Installing VMC Installing Geant4 VMC Build Options Required and Optional Packages Installing Geant3 Installing and Running Examples Build Options Running examples",
    "tags": [],
    "title": "Installation",
    "uri": "/installation/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Installation",
    "content": "Geant4 VMC requires the VMC core package, ROOT and Geant4 installed, and optionally, it can be built with VGM. See below tips for configuration and installation of these packages.\nThe vmc core package was separated from the ROOT source into a new stand-alone vmc package in the GitHub vmc-project organization. The motivation for this step was a gain in flexibility and faster workflow for new developments of multiple engine mode. The vmc package in ROOT is deprecated since ROOT version 6.18 (its compilation is optional) and it is going to be removed in the next ROOT version, 6.26. The VMC stand-alone is supported since Geant4 VMC 5.0.\nGeant4 VMC uses CMake to configure a build system for compiling and installing the headers, libraries and CMake configuration files. To install geant4_vmc:\nFirst get the Geant4 VMC source from the Download page. We will assume that the Geant4 VMC package sits in a subdirectory /mypath/geant4_vmc Create build directory alongside our source directory $ cd /mypath $ mkdir geant4_vmc_build $ ls geant4_vmc geant4_vmc_build To configure the build, change into the build directory and run CMake: $ cd /mypath/geant4_vmc_build $ cmake -DCMAKE_INSTALL_PREFIX=/mypath/geant4_vmc_install /mypath/geant4_vmc If ROOT and Geant4 environment was defined using thisroot.[c]sh and geant4.[c]sh scripts, there is no need to provide path to their installations. Otherwise, they can be provided using -DROOT_DIR and -DGeant4_DIR cmake options.\nSince Geant4 VMC 5.4, the VMC stand-alone library has to be provided using -DVMC_DIR cmake option. If the VMC stand-alone library is not found, the deprecated VMC library in ROOT (availble if ROOT was built with the vmc option enabled) can still be used, a deprecation warning will be issued in this case.\nSince Geant4 VMC 6.0, the deprecated VMC library in ROOT cannot be used and building against ROOT built with the vmc option enabled will fail with CMake error.\nAfter the configuration has run, CMake will have generated Unix Makefiles for building Geant4 VMC. To run the build, simply execute make in the build directory: $ make -jN where N is the number of parallel jobs you require (e.g. if your machine has a dual core processor, you could set N to 2).\nIf you need more output to help resolve issues or simply for information, run make as $ make -jN VERBOSE=1 Once the build has completed, you can install Geant4 VMC to the directory you specified earlier in CMAKE_INSTALL_PREFIX by running $ make install This will build geant4_vmc, g4root and examples packages. For VMC examples see VMC examples installation page.\nBuild Options Required and Optional Packages The instructions above apply to the installation since the version 3.0 built against Geant4 10.00.p03. For the installation of the previous versions see\nOlder Versions Special Installation",
    "description": "Geant4 VMC requires the VMC core package, ROOT and Geant4 installed, and optionally, it can be built with VGM. See below tips for configuration and installation of these packages.\nThe vmc core package was separated from the ROOT source into a new stand-alone vmc package in the GitHub vmc-project organization. The motivation for this step was a gain in flexibility and faster workflow for new developments of multiple engine mode. The vmc package in ROOT is deprecated since ROOT version 6.18 (its compilation is optional) and it is going to be removed in the next ROOT version, 6.26. The VMC stand-alone is supported since Geant4 VMC 5.0.",
    "tags": [],
    "title": "Installing Geant4 VMC",
    "uri": "/installation/geant4_vmc/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Installation \u003e Installing Geant4 VMC",
    "content": "Root Configuration for geant4_vmc versions (2.x - 2.8) The older geant4_vmc versions (2.x - 2.8) require Root to be configured with g4root package; for this you have to specify the following configure options:\n--enable-g4root \\ --with-g4-incdir=$G4INSTALL/include \\ --with-g4-libdir=$G4INSTALL/lib/Linux-g++ \\ --with-clhep-incdir=$CLHEP_BASE_DIR/include \\ \u003cli\u003e \u003ch3\u003eGeant4 configuration (version \u003e= 9.5) \u003cbr\u003e with manual installation (with GNUmake) \u003c/h3\u003e If you install Geant4 with the GNUmakefile build system and your own environment setting, you need to have set the following environment variables. This way of installation requires an experience in Geant4 and so it is not recommended for novice users.\nG4LIB_BUILD_SHARED set to 1 (required) G4LIB_USE_G3TOG4 set to 1 (required) G4VIS_BUILD_OPENGLX_DRIVER set to 1 (recommended) G4VIS_USE_OPENGLX set to 1 (recommended) The path to Geant4 installation is then defined with the environment variables. G4INSTALL ... path to Geant4 installation G4SYSTEM ... Geant4 system flavor CLHEP_BASE_DIR ... path to CLHEP If Geant4 is installed in a different path than the path to the source tree, the following additional variables have to be set: G4LIB … path to Geant4 libraries (optional) G4INCLUDE … path to Geant4 include files (option) Geant4 configuration (version \u003c= 9.4) Installation of Geant4 + Geant4 VMC requires the CLHEP shared library. Note that Geant4 VMC requires some Geant4 installation options which are not set by default during the Geant4 installation procedure: Geant4 shared libraries;\nAll Geant4 header files in the include directory Build Geant4 with the use of the G3toG4 tool It is also recommended to build Geant4 X11 OpenGL visualization driver which is used in the VMC examples. To get these options when using Configure program, you should reply y to the following questions. The Configure program will then generate automatically a script for an environment setup which should be sourced each time when using Geant4. Do you want to install all Geant4 headers in one directory? [n] y (required) Do you want to build shared libraries? [y] y (required) Enable building of visualization drivers? [y] y (recommended) Enable building of the X11 OpenGL visualization driver? [n] y (recommended) Enable build of the g3tog4 utility module? [n] y (required) If you install Geant4 with your own environment setting, you need to have set the following environment variables. This way of installation requires an experience in Geant4 and so it is not recommended for novice users. G4LIB_BUILD_SHARED set to 1 (required) G4LIB_USE_G3TOG4 set to 1 (required) G4VIS_BUILD_OPENGLX_DRIVER set to 1 (recommended) G4VIS_USE_OPENGLX set to 1 (recommended)",
    "description": "Root Configuration for geant4_vmc versions (2.x - 2.8) The older geant4_vmc versions (2.x - 2.8) require Root to be configured with g4root package; for this you have to specify the following configure options:\n--enable-g4root \\ --with-g4-incdir=$G4INSTALL/include \\ --with-g4-libdir=$G4INSTALL/lib/Linux-g++ \\ --with-clhep-incdir=$CLHEP_BASE_DIR/include \\ \u003cli\u003e \u003ch3\u003eGeant4 configuration (version \u003e= 9.5) \u003cbr\u003e with manual installation (with GNUmake) \u003c/h3\u003e If you install Geant4 with the GNUmakefile build system and your own environment setting, you need to have set the following environment variables. This way of installation requires an experience in Geant4 and so it is not recommended for novice users.\nG4LIB_BUILD_SHARED set to 1 (required) G4LIB_USE_G3TOG4 set to 1 (required) G4VIS_BUILD_OPENGLX_DRIVER set to 1 (recommended) G4VIS_USE_OPENGLX set to 1 (recommended)",
    "tags": [],
    "title": "Installing Geant4 VMC - Special Installations",
    "uri": "/installation/geant4_vmc/special-installations/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Installation \u003e Installing Geant4 VMC",
    "content": "Geant4 VMC requires ROOT and Geant4 installed, then the VMC core package if using ROOT built without vmc enabled, and optionally, it can be built with VGM. See below tips for configuration and installation of these packages.\nThe path to required and optional packages installations can be defined in the standard CMake way, via the paths to the CMake configuration file:\nGeant4_DIR ... path to Geant4Config.cmake ROOT_DIR ... path to ROOTConfig.cmake VMC_DIR ... path to VMCConfig.cmake VGM_DIR ... path to VGMConfig.cmake CMake will also find the CMake configuration files (for ROOT and Geant4) if you source the relevant script from the packages installations (CMAKE_INSTALL_PREFIX) so that they are available in the sestem paths:\n$ . bin/geant4.sh ... Geant4 - on bourne shells (eg. bash) $ . bin/thisroot.sh ... Root or $ source bin/geant4.csh ... Geant4 - on C shells $ source bin/thisroot.csh ... Root C++11 Geant4 VMC, as well as ROOT and Geant4, have moved to the C++11 standard. C++11 is used by default since Geant4 VMC 3.3, Geant4 10.2 and ROOT 6.\nWhen mixing other versions of Geant4 and ROOT together, the same standard must be used for both packages. See below how the override the default setting when needed.\nROOT To install ROOT - follow the Root Installation Page\nC++11 Geant4 VMC 3.3 built against ROOT 5.x requires ROOT built with C++11 (not default for this ROOT version), set via: -Dcxx11=ON option, when ROOT is built using CMake, or\n--enable-cxx11 option, when ROOT is built using configure script.\nGeant4 To install Geant4 - download the source from Geant4 Download page and follow the Geant4 Installation Guide together with the tips relevant to using it with VMC described below.\nC++11 Geant4 VMC 3.0 - 3.2 built against Geant4 10.0.x or 10.1.x and ROOT 6x requires Geant4 built with C++11 (not default for these Geant4 versions), set via: -DGEANT4_BUILD_CXXSTD=c++11 G3toG4 tool\nThe G3toG4 package is used in geant4_vmc to support geometry definition via VMC with Geant4 native navigation. The build of G3toG4 package can be activated when building Geant4 with the following CMake options: -DGEANT4_USE_G3TOG4=ON Since Geant4 VMC 3.0 the use of this package is optional.\nOpenGL visualization It is recommended to build Geant4 X11 OpenGL visualization driver used in the VMC examples. It is handled in Geant4 CMake build via the CMake option: -DGEANT4_USE_OPENGL_X11=ON Multi-threading Geant4 VMC can be built against Geant4 installation in multi-threading mode which is handled in Geant4 CMake build via the CMake option: -DG4MULTITHREADED=ON Dynamic loading of Geant4 libraries, as used in VMC, requires to change the Geant4 default TLS model, initial-exec, with global-dynamic via the CMake option:\n-DGEANT4_BUILD_TLS_MODEL=global-dynamic Geant4 VMC 3.00.x version is migrated to Geant4 multi-threading and can be built against both Geant4 sequential and Geant4 multi-threading installations. The global-dynamic model is required for running VMC applications from Root session (in a “traditional” way with dynamic loading of libraries). When the VMC application main program is linked with all libraries, Geant4 built with the default TLS model can be used.\nThe VMC application will run automatically in MT mode when Geant4 VMC is built against Geant4 MT. See the page on Multi-threaded processing how this default behaviour can be changed in the configuration of the application.\nVGM (optional) VGM is used in Geant4 VMC for a geometry in memory conversion from Root TGeo objects to the Geant4 native geometry. This conversion is performed when users geometry is defined via the Root geometry package and Geant4 native geometry navigation is selected.\nTo install VGM - follow the installation instructions on the VGM Web site.\nTo build Geant4 VMC with VGM, you have to select the option:\n-DGeant4VMC_USE_VGM=ON",
    "description": "Geant4 VMC requires ROOT and Geant4 installed, then the VMC core package if using ROOT built without vmc enabled, and optionally, it can be built with VGM. See below tips for configuration and installation of these packages.\nThe path to required and optional packages installations can be defined in the standard CMake way, via the paths to the CMake configuration file:\nGeant4_DIR ... path to Geant4Config.cmake ROOT_DIR ... path to ROOTConfig.cmake VMC_DIR ... path to VMCConfig.cmake VGM_DIR ... path to VGMConfig.cmake CMake will also find the CMake configuration files (for ROOT and Geant4) if you source the relevant script from the packages installations (CMAKE_INSTALL_PREFIX) so that they are available in the sestem paths:",
    "tags": [],
    "title": "Required and Optional Packages",
    "uri": "/installation/geant4_vmc/required-optional-packages/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Download",
    "content": "Development version (the whole repository):\ngit clone http://github.com/vmc-project/vmc.git To switch to ‘pro’ tagged version 2.1:\ncd vmc git checkout v2-1 To switch to the ‘old’ tagged version 1.1.p1:\ncd vmc git checkout v1-1-p1 The list of new developments, bug fixes and the required versions of ROOT and Geant4 for each version can be found in the History file.",
    "description": "Development version (the whole repository):\ngit clone http://github.com/vmc-project/vmc.git To switch to ‘pro’ tagged version 2.1:\ncd vmc git checkout v2-1 To switch to the ‘old’ tagged version 1.1.p1:\ncd vmc git checkout v1-1-p1 The list of new developments, bug fixes and the required versions of ROOT and Geant4 for each version can be found in the History file.",
    "tags": [],
    "title": "VMC",
    "uri": "/download/git-vmc/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide",
    "content": "This chapter presents the core VMC package and the new multiple engine functionality.\nVMC Core Multiple VMC Engines",
    "description": "This chapter presents the core VMC package and the new multiple engine functionality.\nVMC Core Multiple VMC Engines",
    "tags": [],
    "title": "VMC Core",
    "uri": "/user-guide/vmc/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e VMC Core",
    "content": "The core of the VMC, vmc, provides a set of interfaces which completely decouple the dependencies between the user code and the concrete Monte Carlo:\nTVirtualMC: Interface to the concrete Monte Carlo program TVirtualMCApplication: Interface to the user’s Monte Carlo application TVirtualMCStack: Interface to the particle stack TVirtualMCDecayer: Interface to the external decayer TVirtualMCSensitiveDetector: Interface to the user’s sensitive detector The implementation of the TVirtualMC interface is provided for two Monte Carlo transport codes, GEANT3 and Geant4, with the VMC packages listed below. The implementation for the third Monte Carlo transport code, FLUKA, has been discontinued by the FLUKA team in 2010.\nThe other three interfaces are implemented in the user application. The user has to implement two mandatory classes: the MC application (derived from TVirtualMCApplication) and the MC stack (derived from TVirtualMCStack), optionally an external decayer (derived from TVirtualMCDecayer) can be introduced. The user VMC application is independent from concrete transport codes (GEANT3, Geant4, FLUKA). The transport code which will be used for simulation is selected at run time - when processing a ROOT macro where the concrete Monte Carlo is instantiated.\nThe relationships between the interfaces and their implementations are illustrated in the class diagrams: User MC application , Virtual MC , demonstarting the decoupling between the user code and the concrete transport code.\nMultiple VMCs Since the development version the simulation can be shared among multiple different engines deriving from TVirtualMC which are handled by a singleton TMCManager object.\nSee more detailed description in the dedicated section.\nRoot IO Manager Root IO manager class, TMCRootManager, facilitates use of ROOT IO in VMC examples and it also handles necessary locking in multi-threaded applications.\nIt was first provided in Geant4 VMC in the MTRoot sub-package and moved to the VMC core (since vmc 2.0 and geant4_vmc 6.0).",
    "description": "The core of the VMC, vmc, provides a set of interfaces which completely decouple the dependencies between the user code and the concrete Monte Carlo:\nTVirtualMC: Interface to the concrete Monte Carlo program TVirtualMCApplication: Interface to the user’s Monte Carlo application TVirtualMCStack: Interface to the particle stack TVirtualMCDecayer: Interface to the external decayer TVirtualMCSensitiveDetector: Interface to the user’s sensitive detector The implementation of the TVirtualMC interface is provided for two Monte Carlo transport codes, GEANT3 and Geant4, with the VMC packages listed below. The implementation for the third Monte Carlo transport code, FLUKA, has been discontinued by the FLUKA team in 2010.",
    "tags": [],
    "title": "VMC Core",
    "uri": "/user-guide/vmc/vmc-core/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Download",
    "content": "Development version (the whole repository):\ngit clone http://github.com/vmc-project/geant4_vmc.git To switch to the ‘pro’ tagged version 6.8 (compatible with vmc 2.1, Geant4 11.4):\ncd geant4_vmc git checkout v6-8 To switch to the ‘old’ tagged version 6.7.p1 (compatible with vmc 2.x, Geant4 11.3.):\ncd geant4_vmc git checkout v6-7-p1 The list of new developments, bug fixes and the required versions of ROOT and Geant4 for each version can be found in the history file.\nDownload Geant4 - from the Geant4 Web site",
    "description": "Development version (the whole repository):\ngit clone http://github.com/vmc-project/geant4_vmc.git To switch to the ‘pro’ tagged version 6.8 (compatible with vmc 2.1, Geant4 11.4):\ncd geant4_vmc git checkout v6-8 To switch to the ‘old’ tagged version 6.7.p1 (compatible with vmc 2.x, Geant4 11.3.):\ncd geant4_vmc git checkout v6-7-p1 The list of new developments, bug fixes and the required versions of ROOT and Geant4 for each version can be found in the history file.",
    "tags": [],
    "title": "Geant4 VMC",
    "uri": "/download/git-geant4_vmc/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide",
    "content": "Geant4 VMC represents the realisation of the Virtual Monte Carlo (VMC) for Geant4. It can be also seen as a Geant4 application implemented via the VMC interfaces. It implements all Geant4 user mandatory classes and user action classes, which provide the default Geant4 VMC behaviour, that can be then customized by a user in many ways.\nGeometry Definition \u0026 Navigation Magnetic Field Sensitive Detectors and Volumes Geant4 Scoring Physics Lists Stacking of Particles Special Cuts and Regions User Geant4 Classes Visualization Switching User Interfaces Multi-threaded Processing Verbosity Verbosity for Developers Source code documentation",
    "description": "Geant4 VMC represents the realisation of the Virtual Monte Carlo (VMC) for Geant4. It can be also seen as a Geant4 application implemented via the VMC interfaces. It implements all Geant4 user mandatory classes and user action classes, which provide the default Geant4 VMC behaviour, that can be then customized by a user in many ways.\nGeometry Definition \u0026 Navigation Magnetic Field Sensitive Detectors and Volumes Geant4 Scoring Physics Lists Stacking of Particles Special Cuts and Regions User Geant4 Classes Visualization Switching User Interfaces Multi-threaded Processing Verbosity Verbosity for Developers Source code documentation",
    "tags": [],
    "title": "Geant4 VMC",
    "uri": "/user-guide/geant4_vmc/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Installation",
    "content": "Geant3 with VMC requires the VMC core package and ROOT.\nThe vmc core package was separated from the ROOT source into a new stand-alone vmc package in the GitHub vmc-project organization. The motivation for this step was a gain in flexibility and faster workflow for new developments of multiple engine mode. The vmc package in ROOT is deprecated since ROOT version 6.18 (its compilation is optional) and it is going to be removed in the next ROOT version, 6.26. The VMC stand-alone is supported since Geant3 3.0.\nGeant3 with VMC uses CMake to configure a build system for compiling and installing the headers, libraries and Cmake configuration files.\nTo install geant3:\nFirst get the Geant3 source from the Download page. We will assume that the Geant3 package sits in a subdirectory /mypath/geant3 Create build directory alongside our source directory $ cd /mypath $ mkdir geant3_build $ ls geant3 geant3_build To configure the build, change into the build directory and run CMake: $ cd /mypath/geant3_build $ cmake -DCMAKE_INSTALL_PREFIX=/mypath/geant3_install /mypath/geant3 If ROOT environment was defined using thisroot.{c}sh script, there is no need to provide the path to its installation. Otherwise, they can be provided using -DROOT_DIR cmake option.\nSince Geant3 3.9, the VMC stand-alone library has to be provided using -DVMC_DIR cmake option. If the VMC stand-alone library is not found, the deprecated VMC library in ROOT (availble if ROOT was built with the vmc option enabled) can still be used, a deprecation warning will be issued in this case.\nSince Geant3 4.0, the deprecated VMC library in ROOT cannot be used and building against ROOT built with the vmc option enabled will fail with CMake error.\nThe Geant3 library is built by default in RelWithDebInfo build mode (Optimized build with debugging symbols). This default can be changed via the standard CMake option CMAKE_BUILD_TYPE. The other useful values are Release : Optimized build, no debugging symbols Debug : Debugging symbols, no optimization After the configuration has run, CMake will have generated Unix Makefiles for building Geant3. To run the build, simply execute make in the build directory: $ make -jN where N is the number of parallel jobs you require (e.g. if your machine has a dual core processor, you could set N to 2).\nIf you need more output to help resolve issues or simply for information, run make as $ make -jN VERBOSE=1 Once the build has completed, you can install Geant3 to the directory you specified earlier in CMAKE_INSTALL_PREFIX by running $ make install The instructions above apply to the installation since the version 2.0. For the installation of the previous versions (1.x) see Installing geant3 - Older Versions",
    "description": "Geant3 with VMC requires the VMC core package and ROOT.\nThe vmc core package was separated from the ROOT source into a new stand-alone vmc package in the GitHub vmc-project organization. The motivation for this step was a gain in flexibility and faster workflow for new developments of multiple engine mode. The vmc package in ROOT is deprecated since ROOT version 6.18 (its compilation is optional) and it is going to be removed in the next ROOT version, 6.26. The VMC stand-alone is supported since Geant3 3.0.",
    "tags": [],
    "title": "Installing Geant3",
    "uri": "/installation/geant3/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e VMC Core",
    "content": "Introduction The VMC package allows splitting the event simulation among multiple engines. The criteria of how to split the simulation have to be defined by the user and among others the decision which engine to be used could depend on\ngeometry particle phase space particle type any combination of that … Running multiple engines is fully supported for\nGEANT3_VMC GEANT4_VMC This also allows the user to implement his/her own class deriving from TVirtualMC to be used in a split simulation. The communication between the engines is handled by a singleton object of type TMCManager such that the user does not have to deal with special implementation details. Hence, pausing an engine, re-starting it or transferring tracks between them is done automatically and at the same time the user stack is kept up-to-date. Furthermore, the same user application derived from TVirtualMCApplication together with the same user stack derived from TVirtualMCStack can be used for both a single engine run or a simulation split among multiple ones.\nHow multiple engines are handled To keep the overhead as small as possible, the TMCManager object has to be requested by the user explicitly during construction of the user application by calling TVirtualMCApplication::RequestManager(). That makes the manager available via the protected member TVirtualMCApplication::fMCManager and a pointer can also always be obtained via TMCManager::Instance(). In a single run, on the other hand, there is no such object and the VMC would directly interacts with the user’s particle stack. In that case the scenario of how that VMC is treated and interacts with other objects is the same as it was in previous versions of the VMC package.\nThe most important interfaces of the TMCManager to deal with multiple VMCs are:\nvoid SetUserStack(TVirtualMCStack* userStack)\nThis notifies the manager about the user stack such that it will be kept up-to-date during the simulation. Not setting it makes the TMCManager abort the execution. void ForwardTrack(Int_t toBeDone, Int_t trackId, Int_t parentId, TParticle* userParticle)\nThe user is always the owner of all track objects (aka TParticle) being created. Hence, all engine calls to TVirtualMCStack::PushTrack(...) are first redirected to the user stack where a TParticle has to be created on the heap. After that, this method has to be invoked to forward the pointer of the created TParticle object. If a particle should be pushed to an engine other than the one currently running, the engine’s ID has to be provided as the last argument. void TransferTrack(Int_t targetEngineId)\nFor instance during TVirtualMCApplication::Stepping() the user might decide that the current track should be transferred to another engine, e.g., if a certain volume is entered. By specifying the ID or the pointer to the target engine the manager will take care of interrupting the track in the current engine, extracting the kinematics and geometry state and it will save these information for the target engine. template \u003ctypename F\u003e void Apply(F f)\nThis assumes f to implement the () operator and taking a TVirtualMC pointer as an argument. f will be then called for all engines. template \u003ctypename F\u003e void Init(F f)\nThis works as TMCManager::Apply during the initialization of the engines. It can also be called without an argument such that no additional user routine is included. void Run(Int_t nEvents)\nA run involving all registered VMCs is steered for the specific number of events. void ConnectEnginePointers(TVirtualMC *\u0026mc)\nThis gives the possibility for a user to pass a pointer variable which will always be set to point to the currently running engine. Note, however, that there is a protected member TVirtualMCApplication::fMC which always points to the currently running engine and it can therefore be used within the application’s code. TVirtualMC *GetCurrentEngine()\nThis provides the user with a pointer to the currently running engine. An example of how the TMCManager is utilized in a multi-run can be found in E03c example of the geant4_vmc repository. The diff of e.g E03/E03a and E03/E03c nicely highlights the small amount of extensions necessary to use the same application and stack for both a single and a multi-run.\nImplementation and workflow example The general workflow of a multi-run is explained using some of the classes/implementations of the E03c example mentioned above.\nImplementation\nImplement your application and stack as you have done before. Request the TMCManager in your constructor by calling TVirtualMCApplication::RequestMCManager() Ex03MCApplication::Ex03MCApplication(const char* name, const char* title, Bool_t isMulti, Bool_t splitSimulation) { // some construction // user stack fStack = new Ex03MCStack(1000); if(isMulti) { RequestManager(); fMCManager-\u003eSetUserStack(fStack); } // further construction } At an appropriate stage (i.e. in UserStack::PushTrack(...)) you would call TMCManager::ForwardTrack(...) to forward the pointer to your newly constructed TParticle object. void Ex03MCStack::PushTrack(Int_t toBeDone, Int_t parent, ..., Int_t\u0026 ntr, ...) { // TParticle construction yielding pointer \"particle\" // User defines the track ID ntr = GetNtrack() - 1; // Forward to the TMCManager in case of multi-run if(auto mgr = TMCManager::Instance()) { mgr-\u003eForwardTrack(toBeDone, ntr, parent, particle); } // further implementations } Whenever needed, check the presence of TMCManager to decide whether the code should work for single or multi-run, e.g. in the constructor of Ex03DetectorConstruction where its member fMC is setup to point to the currently running VMC in the multi-run scenario. Ex03DetecorConstruction::Ex03DetectorConstruction(...) { // some construction if(auto mgr = TMCManager::Instance()) { mgr-\u003eConnectEnginePointer(fMC); // ... } // maybe some more construction } Transfer a track involving TMCManager::TransferTrack(...). If the target VMC ID coincides with the one currently running, nothing will happen and the simulation would just continue. Ex03MCApplication::Stepping() { // some implementation Int_t targetId = -1; if (fMC-\u003eGetId() == 0 \u0026\u0026 strcmp(fMC-\u003eGetCurrentVolName(), \"ABSO\") == 0) { targetId = 1; } else if (fMC-\u003eGetId() == 1 \u0026\u0026 strcmp(fMC-\u003eGetCurrentVolName(), \"GAPX\") == 0) { targetId = 0; } if (targetId \u003e -1) { if (fVerbose.GetLevel() \u003e 2) { Info(\"Stepping\", \"Transfer track\"); } fMCManager-\u003eTransferTrack(targetId); } // further implementations } To use the same stack in both scenarios (single and multi-run), one can always check whether the manager is present by checking if TMCManager::Instance() returns a valid pointer value. Usage\nInstantiate your application (here the user stack is created during construction of the application, see above) auto isMulti = true; auto splitSimulation = true; auto appl = new Ex03MCapplication(\"multiApplication\", \"multiApplication\", isMulti, splitSimulation); Instantiate the engines you want to use (these are registered automatically to the manager). In the E03c example this is done in TVirtualMCApplication::InitMC but to clarify, it is written here explicitely, auto engine1 = new TGeant3(...); auto engine2 = new TGeant4(...); // Nothing further to be done Call TMCManager::Init(...) (if needed with your custom initialization procedure, see above; that can of course also be wrapped into another method of your application as it is done here), void Ex03MCApplication::InitMC(std::initializer_list\u003cconst char*\u003e setupMacros) { // some implementation fMCManager-\u003eInit([this](TVirtualMC* mc) { mc-\u003eSetRootGeometry(); mc-\u003eSetMagField(fMagField); mc-\u003eInit(); mc-\u003eBuildPhysics(); }); // further implementations } The lambda argument will be called for each registered VMC separately. If necessary, it can be more specific. Instead of passing a lambda function, a function pointer could be given or also an object. The only requirement is that what is passed implements a () operator taking a VMC pointer as an argument. Call TMCManager::Run(...) specifying the desired number of events to be simulated. void Ex03MCApplication::RunMC(Int_t nofEvents) { // some implementation fMCManager-\u003eRun(nofEvents); // further implementations } Important comments\nThe geometry is built once centrally via the TMCManager calling\nTVirtualMCApplication::ConstructGeometry(), TVirtualMCApplication::MisalignGeometry(), TVirtualMCApplication::ConstructOpGeometry() and therefore, it is expected that these methods do not depend on any engine.\nIf multiple engines have been instantiated, never call TVirtualMC::ProcessRun(...) or other steering methods on the individual engine because that would bypass the TMCManager and will lead to inconsistent behavior.",
    "description": "Introduction The VMC package allows splitting the event simulation among multiple engines. The criteria of how to split the simulation have to be defined by the user and among others the decision which engine to be used could depend on\ngeometry particle phase space particle type any combination of that … Running multiple engines is fully supported for\nGEANT3_VMC GEANT4_VMC This also allows the user to implement his/her own class deriving from TVirtualMC to be used in a split simulation. The communication between the engines is handled by a singleton object of type TMCManager such that the user does not have to deal with special implementation details. Hence, pausing an engine, re-starting it or transferring tracks between them is done automatically and at the same time the user stack is kept up-to-date. Furthermore, the same user application derived from TVirtualMCApplication together with the same user stack derived from TVirtualMCStack can be used for both a single engine run or a simulation split among multiple ones.",
    "tags": [],
    "title": "Multiple VMC Engines",
    "uri": "/user-guide/vmc/multiple-vmc/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Geant4 VMC",
    "content": "Sensitive Detectors Recently (since ROOT version v6.13.04) a new interface to user sensitive detector, TVirtualMCSensitiveDetector, has been added in the set of VMC interfaces. The support for this new way of definig sensitive detector is available since geant3 2.6 and geant4_vmc 4.0.\nThe user sensitive detectors object should be associated to the selected volumes in the new dedicated MCApplication function: void TVirtualMCApplication::SetSensitiveDetectors() using the new TVirtualMC function: void TVirtualMC::SetSensitiveDetector( const TString\u0026 volumeName, TVirtualMCSensitiveDetector* userSD); Users can also choose whether scoring should be performed exclusively via sensitive detectors or via both sensitive detectors and MCApplication::Stepping() using the function void VirtualMC::SetExclusiveSDScoring(Bool_t); If exclusive scoring is selected, the MCApplication::Stepping() is not called by MC.\nTo demonstrate the usage of this new interfaces the E03 example was split in two variants:\nE03a - scoring via sensitive volumes and MCApplication::Stepping (old way) E03b - scoring via sensitive detectors derived from new TVirtualMCSensitiveDetector interface Sensitive Volumes The VMC interfaces did not provide functions for a user selection of sensitive volumes and (unless the new sensitive detector framework is used) the user MCApplication::Stepping() is called in all volumes. In order to speed up simulation, in Geant4 VMC (since version 2.13) the user has a possibility to select sensitive volumes. If any selection is provided, the user MCApplication::Stepping() is called only from the selected sensitive volumes.\nThe selection of sensitive volumes can be done in two ways:\nVia the following Geant4 VMC command:\n/mcDet/addSDSelection volName1 [volName2 ...] The command can be applied more times, the new selection is each time added to the existing ones.\nVia labeling volumes directly in TGeo geometry. In this case, user has to notify Geant4 VMC about using the sensitive volumes selection from TGeo by applying Geant4 VMC command:\n/mcDet/setSDSelectionFromTGeo true The volumes in TGeo geometry are set sensitive by setting the option “SV” to TGeoVolume objects: TGeoVolume* myVolume = ...; myVolume-\u003eSetOption(\"SV\"); User can also choose a different string than “SV” for sensitive volumes labeling. In this case, they have to notify Geant4 VMC about the label via the Geant4 VMC command:\n/mcDet/setSVLabel MyLabel Note that the option set via TGeoVolume::SetOption function is not persistent.",
    "description": "Sensitive Detectors Recently (since ROOT version v6.13.04) a new interface to user sensitive detector, TVirtualMCSensitiveDetector, has been added in the set of VMC interfaces. The support for this new way of definig sensitive detector is available since geant3 2.6 and geant4_vmc 4.0.\nThe user sensitive detectors object should be associated to the selected volumes in the new dedicated MCApplication function: void TVirtualMCApplication::SetSensitiveDetectors() using the new TVirtualMC function: void TVirtualMC::SetSensitiveDetector( const TString\u0026 volumeName, TVirtualMCSensitiveDetector* userSD); Users can also choose whether scoring should be performed exclusively via sensitive detectors or via both sensitive detectors and MCApplication::Stepping() using the function void VirtualMC::SetExclusiveSDScoring(Bool_t); If exclusive scoring is selected, the MCApplication::Stepping() is not called by MC.",
    "tags": [],
    "title": "Sensitive Detectors and Volumes",
    "uri": "/user-guide/geant4_vmc/sensitive-volumes/index.html"
  },
  {
    "breadcrumb": "VMC Project",
    "content": "Introduction VMC Concept VMC Project VMC Core VMC Core Multiple VMC Engines Geant4 VMC Geometry Definition \u0026 Navigation Magnetic Field Sensitive Detectors and Volumes Geant4 Scoring Physics Lists Stacking of Particles Special Cuts and Regions User Geant4 Classes Visualization Switching User Interfaces Multi-threaded Processing Verbosity Verbosity for Developers Source code documentation Geant3 + VMC Geant3 + VMC Content G4Root",
    "description": "Introduction VMC Concept VMC Project VMC Core VMC Core Multiple VMC Engines Geant4 VMC Geometry Definition \u0026 Navigation Magnetic Field Sensitive Detectors and Volumes Geant4 Scoring Physics Lists Stacking of Particles Special Cuts and Regions User Geant4 Classes Visualization Switching User Interfaces Multi-threaded Processing Verbosity Verbosity for Developers Source code documentation Geant3 + VMC Geant3 + VMC Content G4Root",
    "tags": [],
    "title": "User Guide",
    "uri": "/user-guide/index.html"
  },
  {
    "breadcrumb": "VMC Project",
    "content": "This chapter presents the examples of usage of VMC.\nVMC Examples Experiment Frameworks",
    "description": "This chapter presents the examples of usage of VMC.\nVMC Examples Experiment Frameworks",
    "tags": [],
    "title": "Examples",
    "uri": "/examples/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Download",
    "content": "Development version (the whole repository):\ngit clone http://github.com/vmc-project/geant3.git To switch to the ‘pro’ tagged version 4.4 (compatible with vmc 2.x, ROOT 6.x):\ncd geant3 git checkout v4-4 To switch to the ‘old’ tagged version 3.9.p1 (compatible with vmc 1,x, ROOT 6.x):\ncd geant3 git checkout v3-9-p1 To switch to the ‘old’ tagged version 2.7.p2 (compatible with ROOT 5.x):\ncd geant3 git checkout v2-7-p2 For older versions see the correspondent tag and the required version of ROOT in the history file.",
    "description": "Development version (the whole repository):\ngit clone http://github.com/vmc-project/geant3.git To switch to the ‘pro’ tagged version 4.4 (compatible with vmc 2.x, ROOT 6.x):\ncd geant3 git checkout v4-4 To switch to the ‘old’ tagged version 3.9.p1 (compatible with vmc 1,x, ROOT 6.x):\ncd geant3 git checkout v3-9-p1 To switch to the ‘old’ tagged version 2.7.p2 (compatible with ROOT 5.x):\ncd geant3 git checkout v2-7-p2 For older versions see the correspondent tag and the required version of ROOT in the history file.",
    "tags": [],
    "title": "Geant3",
    "uri": "/download/git-geant3/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide",
    "content": "The geant3 package provided in vmc-project contains both the Geant3.21 code itself and the implementation of the TVirtualMC interface, TGeant3.\nFor a detail description of Geant3, see the Geant3 manual.\nGeant3 + VMC Content",
    "description": "The geant3 package provided in vmc-project contains both the Geant3.21 code itself and the implementation of the TVirtualMC interface, TGeant3.\nFor a detail description of Geant3, see the Geant3 manual.\nGeant3 + VMC Content",
    "tags": [],
    "title": "Geant3 + VMC",
    "uri": "/user-guide/geant3+vmc/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Geant4 VMC",
    "content": "Geant4 command line scoring Since Geant4 VMC version 6.8, it is possible to activate Geant4 command line scoring (see details in the Geant4 Application developers Guide, section Command-based scoring).\nThe activation should be done via calling\nvoid TG4RunConfiguration::SetUseOfG4Scoring() in the user g4Config.C.\nThe scoring (mesh, scorers etc.) can be then defined via Geant UI commands, available in the ‘/score’ directory, in g4config.in.\nThe scoring data will be then automatically saved for each mesh in a mesh_name.txt file at the end of simulation run.\nUser defined scoring function Users can also provide their scoreweight function that takes (pdg, ekin) as arguments, defined via TG4ScoreWeightCalculator , using a new TG4RunConfiguration class` setter:\nvoid TG4RunConfiguration::SetScoreWeightCalculator(TG4ScoreWeightCalculator swc) The user function is then wrapped to G4ScoreWeightCalculator function, that takes (const G4Step*) as argument, and is applied to all Geant4 scorers with activated score weighting.",
    "description": "Geant4 command line scoring Since Geant4 VMC version 6.8, it is possible to activate Geant4 command line scoring (see details in the Geant4 Application developers Guide, section Command-based scoring).\nThe activation should be done via calling\nvoid TG4RunConfiguration::SetUseOfG4Scoring() in the user g4Config.C.\nThe scoring (mesh, scorers etc.) can be then defined via Geant UI commands, available in the ‘/score’ directory, in g4config.in.\nThe scoring data will be then automatically saved for each mesh in a mesh_name.txt file at the end of simulation run.",
    "tags": [],
    "title": "Geant4 Scoring",
    "uri": "/user-guide/geant4_vmc/geant4-scoring/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Installation",
    "content": "The following instructions apply to the installation since the version 3.00. Since this 3.00, VMC examples are installed with CMake.\nThe VMC examples libraries require ROOT installation and the VMC core package if using ROOT built without vmc enabled. The VMC examples programs can be built against Geant3 with VMC or Geant4 VMC libraries. Only the examples with the multiple engine mode (at present only E03c) can be built with both Geant3 and Geant4 VMC libraries. The VMC_WITH_Multi CMake option has to be set, too, in this special case.\nBy default, the VMC examples libraries and the VMC examples programs are built against Geant4 VMC libraries together with Geant4 VMC installation. Below we provide the instructions how to build VMC examples altogether outside Geant4 VMC. The analogous instructions can be used to build each example individually or to build a user application.\nTo install all examples\nFirst get the Geant4 VMC source from the Download page, as the examples are provided within this package. We will assume that the Geant4 VMC package sits in a subdirectory /mypath/geant4_vmc Create build directory alongside our source directory for installation with Geant4: $ cd /mypath $ mkdir examples_build_g4 $ ls geant4_vmc examples_build_g4 and/or for installation with Geant3: $ cd /mypath $ mkdir examples_build_g3 $ ls geant4_vmc examples_build_g3 and/or for the installation without specific MC (only libraries will be installed in this case): $ cd /mypath $ mkdir examples_build $ ls geant4_vmc examples_build To configure the build, change into the build directory and run CMake with either -DVMC_WITH_Geant4 $ cd /mypath/example_build_g4 $ cmake -DCMAKE_INSTALL_PREFIX=/mypath/examples_install_g4 \\ -DVMC_WITH_Geant4=ON \\ -DGeant4VMC_DIR=/mypath/geant4_vmc_install/lib[64]/Geant4VMC-3.0.0 \\ /mypath/geant4_vmc/examples or -DVMC_WITH_Geant3, $ cd /mypath/example_build_g3 $ cmake -DCMAKE_INSTALL_PREFIX=/mypath/examples_install_g3 \\ -DVMC_WITH_Geant3=ON \\ -DGeant3_DIR=/mypath/geant3_install/lib[64]/Geant3-2.0.0 \\ -DPythia6_LIB_DIR=/my_path_to_pythia6_library \\ /mypath/geant4_vmc/examples or with VMC_WITH_Multi, $ cd /mypath/example_build_multi $ cmake -DCMAKE_INSTALL_PREFIX=/mypath/examples_install_multi \\ -DVMC_WITH_Geant3=ON \\ -DVMC_WITH_Geant4=ON \\ -DVMC_WITH_Multi=ON \\ -DGeant3_DIR=/mypath/geant3_install/lib[64]/Geant3-2.0.0 \\ -DGeant4VMC_DIR=/mypath/geant4_vmc_install/lib[64]/Geant4VMC-3.0.0 \\ -DPythia6_LIB_DIR=/my_path_to_pythia6_library \\ /mypath/geant4_vmc/examples or no specific MC: $ cd /mypath/example_build_g3 $ cmake -DCMAKE_INSTALL_PREFIX=/mypath/examples_install \\ -DCMAKE_MODULE_PATH=/mypath/geant4_vmc_install/lib[64]/Geant4VMC-3.0.0/Modules \\ /mypath/geant4_vmc/examples Note that in the last case, you still have to define the path to CMake configuration files used in examples which are provided with both Geant4 VMC and Geant3 CMake installations. Only examples libraries are built and installed in this case.\nIf ROOT and Geant4 environment was defined using thisroot.[c]sh and geant4.[c]sh scripts, there is no need to provide the path to their installations. Otherwise, they can be provided using -DROOT_DIR and -DGeant4_DIR cmake options.\nSince ROOT 6.18, building the VMC library is optional. When using ROOT built with the vmc option enabled, then Geant4 VMC will automatically use the VMC library from ROOT, otherwise the VMC stand-alone library has to be provided using -DVMC_DIR cmake option. After the configuration has run, CMake will have generated Unix Makefiles for building examples. To run the build, simply execute make in the build directory: $ make -jN where N is the number of parallel jobs you require (e.g. if your machine has a dual core processor, you could set N to 2). If you need more output to help resolve issues or simply for information, run make as $ make -jN VERBOSE=1 Once the build has completed, you can install examples to the directory you specified earlier in CMAKE_INSTALL_PREFIX by running $ make install This will install examples libraries in lib[64] and executables in bin directory in CMAKE_INSTALL_PREFIX directory.\nBuild Options Running examples For the old instructions see:\nOlder Versions",
    "description": "The following instructions apply to the installation since the version 3.00. Since this 3.00, VMC examples are installed with CMake.\nThe VMC examples libraries require ROOT installation and the VMC core package if using ROOT built without vmc enabled. The VMC examples programs can be built against Geant3 with VMC or Geant4 VMC libraries. Only the examples with the multiple engine mode (at present only E03c) can be built with both Geant3 and Geant4 VMC libraries. The VMC_WITH_Multi CMake option has to be set, too, in this special case.",
    "tags": [],
    "title": "Installing and Running Examples",
    "uri": "/installation/examples/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Geant4 VMC",
    "content": "Physics list selection Physics Geant4 VMC does not provide a default physics list. User have to choose the physics list from the physics lists provided in Geant4 (see the Geant4 Physics List Guide or include their own physics list. The choice of the physics list is done via the option specified with creating TG4RunConfiguration object. This option is passed asthe second argument in TG4RunConfiguration constructor (see examples for more details).\nThis option can be defined as:\n\"\u003cg4-physics-list\u003e[_\u003cEM-option\u003e][+extra][+optical][+radDecay]\" where\n\u003cg4-physics-list\u003e - is a name of a Geant4 physics list; eg. FTFP_BERT, QGSP, …\nIt is also possible to select “emStandard” which builds only G4EmStandardPhysics() and G4DecayPhysics() _\u003cEM-option\u003e - is the EM physics option (none, _EMV, _EMX, _EMY, _LIV, _PEN) +extra - adds G4ExtraPhysics +optical - adds G4OpticalPhysics +radDecay - adds G4RadioactiveDecayPhysics Examples:\n\"FTFP_BERT_EMV+optical\" \"QGSP_BIC_EMY+radDecay\" The \u003cg4-physics-list\u003e_\u003cEM-option\u003e must represent a valid Geant4 physics list (except for “emStandard”). Since Geant4 9.5 it is possible to combine all EM options with all physics lists.\nSpecial processes In order to activate the support of VMC features like the VMC cuts, VMC process controls, user has to activate the special processes defined in TG4SpecialPhysicsList. The selection of special processes is passed as the third argument in TG4RunConfiguration constructor (see examples for more details):\n\"[stepLimiter][+specialCuts][+specialControls][+stackPopper]\" where\n\"stepLimiter\" - step limiter (default) \"specialCuts\" - VMC cuts \"specialControls\" - VMC controls for activation/inactivation selected processes \"stackPopper\" - stack popper physics Examples:\n\"stepLimit+specialCuts\" \"stepLimit+specialCuts+stackPopper\" Composed physics list According to the user selection, Geant4 VMC creates a TG4ComposedPhysicsList object which is a composition of a selected Geant4 physics list (or a user physics list), the extra physics list ( TG4ExtraPhysicsList - in development version only) and the TG4SpecialPhysicsList object. The inclusion of the extra physics list is optional. The composed physics list processes the Geant4 (or user) physics list in the first order, then adds the extra physics processes (if selected) and finally the special processes, registered in TG4SpecialPhysicsList, are added in the last order.\nSince version 2.13, the user physics selection is added to the TGeant4 object title so that it can be retrievable in a user application.\nInspecting particles and physics processes The instantiated particles and physics processes can be the viewed with the following Geant4 and Geant4 VMC commands.\nTo list all particles and processes:\n/particle/list /process/list /mcPhysics/dumpAllProcess To inspect a selected particle:\n/particle/select particleName /particle/process/dump /particle/property/dump /particle/property/decay/dump To print the mapping of G4 processes to VMC process codes and VMC (G3-like) process controls:\n/mcPhysics/printProcessMCMap /mcPhysics/printProcessControlMap Electromagnetic physics Users can tailor the extra physics processes provided by Geant4 via the commands defined in the /physics_lists/em/ command directory and switch on the muon or gamma nuclear interaction, synchrotron radiation, gamma or positron conversion to muon pair or positron conversion to hadrons processes, which are not which are not included by default:\n/physics_lists/em/SyncRadiation true|false /physics_lists/em/SyncRadiationAll true|false /physics_lists/em/GammaNuclear true|false /physics_lists/em/MuonNuclear true|false /physics_lists/em/GammaToMuons true|false /physics_lists/em/PositronToMuons true|false /physics_lists/em/PositronToHadrons true|false Users can also customize the parameters of the electromagnetic physics processes using the commands in the following directories (use interactive help to get more information):\n/process/eLoss/ /process/msc/ /process/em/ Since Geant4 VMC version 2.10, it is also possible to choose an extra model of energy loss, fluctuations or multiple scattering for selected tracking media and selected particles. This can be done via the following built-in commands:\n/mcPhysics/emModel/setEmModel PAI /mcPhysics/emModel/setRegions trackingMedium1 [trackingMedium2 ...] /mcPhysics/emModel/setParticles all The setRegions and setParticles commands must be followed by the list of tracking media names and particle names respectively, separated with a blank space. The setParticles command can also take as a parameter the keyword \"all\". The model will be then applied to all particles.\nAt present, the following models are supported: PAI and PAIPhoton models which are applied to ionisation process, and SpecialUrbanMsc, a special model tuned for ALICE EMCAL detector, which is applied to e- and e+ multiple scattering processes.\nHadronic physics User can activate a generation of the cross sections plots for a given projectile particle and a target element via the following commands:\n/mcCrossSection/makeHistograms [true|false] /mcCrossSection/setParticle proton /mcCrossSection/setElement Al The default energy or momentum limits and the number of bins can be customised via the commands:\n/mcCrossSection/setMinKinE 1 MeV /mcCrossSection/setMaxKinE 1 TeV /mcCrossSection/setMinMomentum 10 MeV /mcCrossSection/setMaxMomentum 10 TeV /mcCrossSection/setNofBinsE 900 /mcCrossSection/setNofBinsP 800 It is also possible to print the cross section value for a selected energy or a momentum for a selected cross section type (or all types) via the following commands:\n/mcCrossSection/setParticle anti_proton /mcCrossSection/setElement H /mcCrossSection/setMomentum 0.3 GeV /mcCrossSection/printCrossSection All How to apply Geant4 commands in a Root user session is explained at the section on Switching User Interfaces.",
    "description": "Physics list selection Physics Geant4 VMC does not provide a default physics list. User have to choose the physics list from the physics lists provided in Geant4 (see the Geant4 Physics List Guide or include their own physics list. The choice of the physics list is done via the option specified with creating TG4RunConfiguration object. This option is passed asthe second argument in TG4RunConfiguration constructor (see examples for more details).\nThis option can be defined as:",
    "tags": [],
    "title": "Physics Lists",
    "uri": "/user-guide/geant4_vmc/physics-lists/index.html"
  },
  {
    "breadcrumb": "VMC Project",
    "content": "This chapter provides the links to the VMC packages reference documentation\nVMC core Geant4 VMC Examples G4Root",
    "description": "This chapter provides the links to the VMC packages reference documentation\nVMC core Geant4 VMC Examples G4Root",
    "tags": [],
    "title": "Reference",
    "uri": "/reference/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide",
    "content": "The G4Root package is an interface allowing running a GEANT4 simulation with a ROOT geometry. In fact it is just the G4 navigation that uses directly the TGeo geometry. Though it is distributed in geant4_vmc, it can be built and used independently from VMC.\nSee more details on the G4Root Reference web page.",
    "description": "The G4Root package is an interface allowing running a GEANT4 simulation with a ROOT geometry. In fact it is just the G4 navigation that uses directly the TGeo geometry. Though it is distributed in geant4_vmc, it can be built and used independently from VMC.\nSee more details on the G4Root Reference web page.",
    "tags": [],
    "title": "G4Root",
    "uri": "/user-guide/g4root/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Geant4 VMC",
    "content": "The user VMC stack is used differently in Geant3 VMC and Geant4 VMC. Geant3 VMC pops both primary and secondary particles as they are provided by TVirtualMCStack::PopNextTrack(), while Geant4 VMC pops only primary particles using TVirtualMCStack::PopPrimaryForTracking() from the VMC stack.\nStacking of secondary particles is then handled by Geant4 kernel and the user VMC stack only monitors this stacking. By default, Geant4 VMC saves each secondary particle when it starts its tracking (at the the pre-track phase). User can customize this default behaviour and choose also not to save secondary particles at all or to save them in the step of their parent particle, immediately after their creation. This can be done using the command (see in the section on Switching User Interfaces how to apply Geant4 commands in a Root user session):\n/mcTracking/saveSecondaries selection selection = DoNotSave, SaveInPreTrack, SaveInStep The consequence of this is that, by default, the particles added to the VMC stack in other than TVirtualMCApplication::GeneratePrimaries() functions are ignored in Geant4 tracking. Users have to activate the stack popper special process (see the section on Physics list selection), if they want to add particles to the stack during tracking. The added particles are then handled as secondaries of the current track.\nThe stack classes in the VMC examples provide the same stacking mechanism for both Geant3 and Geant4 MCs and they are recommended to be used in a user application.",
    "description": "The user VMC stack is used differently in Geant3 VMC and Geant4 VMC. Geant3 VMC pops both primary and secondary particles as they are provided by TVirtualMCStack::PopNextTrack(), while Geant4 VMC pops only primary particles using TVirtualMCStack::PopPrimaryForTracking() from the VMC stack.\nStacking of secondary particles is then handled by Geant4 kernel and the user VMC stack only monitors this stacking. By default, Geant4 VMC saves each secondary particle when it starts its tracking (at the the pre-track phase). User can customize this default behaviour and choose also not to save secondary particles at all or to save them in the step of their parent particle, immediately after their creation. This can be done using the command (see in the section on Switching User Interfaces how to apply Geant4 commands in a Root user session):",
    "tags": [],
    "title": "Stacking of Particles",
    "uri": "/user-guide/geant4_vmc/stacking-of-particles/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Download",
    "content": "Pro versions Package Version Tar file Tested with vmc 2.1 vmc-2-1.tar.gz ROOT 6.32/08 geant4_vmc 6.8 geant4_vmc-6-8.tar.gz vmc 2.1, ROOT 6.36/06,\nGeant4 11.4 (with embedded CLHEP 2.4.7.2), VGM 5.4, Garfield 5.0 geant3 4.4 geant3-4-4.tar.gz vmc 2.0, ROOT 6.32/01 (alice) In general, the VMC packages can be built with the Root version which they were tested with and higher, and Geant4 VMC with the Geant4 version which it was tested with including the patches. Note that the Geant4 patches released after the Geant4 VMC tag do not appear in the table above, it is however recommended to update Geant4 with each patch release.\nOld versions Package Version Tar file Tested with geant4_vmc 6.7.p1 geant4_vmc-6-7-p1.tar.gz vmc 2.1, ROOT 6.32/08,\nGeant4 11.3[.p1] (with embedded CLHEP 2.4.7.1), VGM 5.3.1, Garfield 5.0 geant3 3.9.p1 v3-9-p1.tar.gz vmc 1.1.p1, ROOT 6.24/06 geant3 2.7.p2 v2-7-p2.tar.gz ROOT 5.34/36",
    "description": "Pro versions Package Version Tar file Tested with vmc 2.1 vmc-2-1.tar.gz ROOT 6.32/08 geant4_vmc 6.8 geant4_vmc-6-8.tar.gz vmc 2.1, ROOT 6.36/06,\nGeant4 11.4 (with embedded CLHEP 2.4.7.2), VGM 5.4, Garfield 5.0 geant3 4.4 geant3-4-4.tar.gz vmc 2.0, ROOT 6.32/01 (alice) In general, the VMC packages can be built with the Root version which they were tested with and higher, and Geant4 VMC with the Geant4 version which it was tested with including the patches. Note that the Geant4 patches released after the Geant4 VMC tag do not appear in the table above, it is however recommended to update Geant4 with each patch release.",
    "tags": [],
    "title": "Tar Files",
    "uri": "/download/tar-files/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Geant3 + VMC",
    "content": "Warning Only the Geant3.21 code itself and the implementation of the TVirtualMC interface, TGeant3, provided in geant3 are maintained by the VMC project.\nGeant3.21 The updated version of Geant3.21 that includes several bug fixes compared to the standard version in CERNLIB. In this version all Geant3 gxxxxx routines have been renamed g3xxxxx.\nThe old Makefile system was replaced with a CMake based system since version 2.0.\nSee also Geant3.21 User Guide\nTGeant3 (Geant3 VMC) The directory TGeant3 contains the classes TGeant3 and TGeant3TGeo, which implement the TVirtualMC interface.\nExamples The directory examples includes a set of FORTRAN examples. These examples are not maintained and tested in the VMC project test suites. Instead, the geant3 package is tested using the test suites defined in geant4_vmc/examples.",
    "description": "Warning Only the Geant3.21 code itself and the implementation of the TVirtualMC interface, TGeant3, provided in geant3 are maintained by the VMC project.\nGeant3.21 The updated version of Geant3.21 that includes several bug fixes compared to the standard version in CERNLIB. In this version all Geant3 gxxxxx routines have been renamed g3xxxxx.\nThe old Makefile system was replaced with a CMake based system since version 2.0.",
    "tags": [],
    "title": "Geant3 + VMC Content",
    "uri": "/user-guide/geant3+vmc/geant3+vmc-content/index.html"
  },
  {
    "breadcrumb": "VMC Project",
    "content": "This chapter lists the presentations \u0026 publication related to VMC.\nPublications List",
    "description": "This chapter lists the presentations \u0026 publication related to VMC.\nPublications List",
    "tags": [],
    "title": "Publications",
    "uri": "/publications/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Geant4 VMC",
    "content": "The way of applying cuts is different in Geant3 and Geant4. In Geant3, the cuts are defined as a limit in energy, which is applied both as an energy threshold (a secondary particle is not produced if its energy is beyond the threshold) and a tracking cut (a particle is stopped when its energy gets below the cut).\nInn Geant4, there is defined a unique cut in range which is then converted to an energy threshold per particle and material. The advantage is that you keep the same spatial resolution of your energy deposit over the whole detector. It is also possible to define cuts per regions, as in big experimental setups you may want to speed up your simulation by setting a higher cut in the support structures etc. See more details at the Geant4 User Guide for Application Developers, section Production Threshold versus Tracking Cut.\nVMC cuts The VMC provides a possibility for a user to define cuts in Geant3 way. The cuts can be defined globally or per tracking medium via the following TVirtualMC functions: gMC-\u003eSetCut(cutname, cutValue); gMC-\u003eGstpar(medId, cutName, cutValue); The user defined VMC cuts and their interpretation in Geant4 can be viewed with the following commands:\nTo print the cut values for the given cut type (cutName) and control values for the given control type (controlName) for all tracking media:\n/mcDet/printCuts cutName /mcDet/printControls controlName To print global cuts and global process controls:\n/mcPhysics/printGlobalCuts /mcPhysics/printGlobalControls To print the user limits (including the VMC cuts and controls) set for the specified volume:\n/mcPhysics/printVolumeLimits volName Geant4 cuts By default, Geant4 VMC ignores the VMC cuts and applies only the global cut in range defined in the physics list. The default global cut value in Geant4 VMC is 1*mm for all particles which cut is applied for (gamma, e-, e+, proton). User can change this default value for each particle separately or set a new value for all using the commands:\n/mcPhysics/rangeCutForGamma value /mcPhysics/rangeCutForElectron value /mcPhysics/rangeCutForPositron value /mcPhysics/rangeCuts value Applying VMC cuts in Geant4 In order to take the VMC cuts into account, the user has to activate the special cuts process by switching it on in his g4Config.C (see the section on Physics list selection. This special cuts process applies the VMC cuts as tracking cuts using G4UserLimits.\nSince Geant4 VMC version 6.5, based on Geant4 version 11.2, when the special cuts process is activated, the VMC cuts are also directly set as production cuts to G4ProductionCutsTable.\nFirst, Geant4 VMC defines regions per materials. Each region contains all volumes that have the same material. In the next step, these regions are used to create materials cuts couples in G4ProductionCutsTable and then, in the third step, the energy cut vector is constructed (by filling the VMC cuts in the order of already constructed materials cuts couples vector) and then set to G4ProductionCutsTable using its SetEnergyCutVector() function. This is performed in TG4RegionsManager2 (new in Geant4 VMC version 6.5).\nUser can select several levels of verbosity to control the process of regions definition:\n/mcVerbose/regionsManager level level = 0 no output 1 number of regions added via VMC 2 the list of all volumes and their associated regions Since Geant4 VMC version 6.3, users can print or save the regions data in a file. The default filename, regions.dat can be also changes with a command:\n/mcRegions/print [true|false] /mcRegions/save [true|false] /mcRegions/setFileName fileName The consistency of the volume material and associated regions can be also checked with the check command.\n/mcRegions/check [true|false] The old method of applying cuts via ranges can be activated in g4Config.C using TG4RunConfiguration::SetSpecialCutsOld().\nApplying VMC cuts in Geant4 via ranges (Old method) With older versions, the cut energy is first converted in range and then these range production cuts are set to the region. This conversion is performed in TG4RegionsManager using the Geant4 converter classes G4RToEConvForElectron and G4RToEConvForGamma by iterating within a given range interval up to a given precision. User can change the default precision (= the number of iterations), which is set to 5 (was 2 up the version 6.2) with the command:\n/mcRegions/setRangePrecision value The conversion of VMC cuts to the regions follows these rules:\nIf the VMC energy cut defined by user results in a range cut smaller than the default range cut value defined in user physics list, the VMC cut is ignored and the default range cut is used.\nThe range cut is first evaluated within the range 1e-03mm to 1m; when the range cut order is found, it is refined up to given precision (5 orders of magnitude by default) within 10 values of each order and the range value with the closest energy still smaller than the VMC cut is chosen.\nIt may happen that a value cannot be refined up to the given precision, then the best found value is returned.\nThe regions are defined only in case when the VMC cuts result in range cuts different from the range cuts in the default region; then the region includes all logical volumes with a given material.\nAs the range cuts do not match precisely to user defined energy cuts, the specialCuts process applies the energy cuts as tracking cuts when a particle with energy cut below threshold is generated.\nUser can select several levels of verbosity to control the process of regions definition:\n/mcVerbose/regionsManager level level = 0 no output 1 number of regions added via VMC 2 the list of all volumes, the cuts in energy and calculated cuts in range 3 all evaluated energy values By default, the computed range cut for e- is applied also to e+ and proton. This feature can be switched off by the UI commands:\n/mcRegions/applyForPositron false /mcRegions/applyForProton false In addition to the commands presented in previous sections, users can also load the regions data from the a file.\n/mcRegions/load [true|false] The check commands permorms also a check for the match between the cuts computed from ranges and the input VMC cuts. When this check is activated all cut values that differ with more than a given tolerance will be printed in the output. The default value of this tolerance (1%) can be also tuned:\n/mcRegions/check [true|false] /mcRegions/setEnergyTolerance value It is also possible to dump the regions properties for a specified volume or to activate printing properties of all regions:\n/mcRegions/dump volumeName /mcRegions/print true|false How to apply Geant4 commands in a Root user session is explained at the section on Switching User Interfaces.",
    "description": "The way of applying cuts is different in Geant3 and Geant4. In Geant3, the cuts are defined as a limit in energy, which is applied both as an energy threshold (a secondary particle is not produced if its energy is beyond the threshold) and a tracking cut (a particle is stopped when its energy gets below the cut).\nInn Geant4, there is defined a unique cut in range which is then converted to an energy threshold per particle and material. The advantage is that you keep the same spatial resolution of your energy deposit over the whole detector. It is also possible to define cuts per regions, as in big experimental setups you may want to speed up your simulation by setting a higher cut in the support structures etc. See more details at the Geant4 User Guide for Application Developers, section Production Threshold versus Tracking Cut.",
    "tags": [],
    "title": "Special Cuts and Regions",
    "uri": "/user-guide/geant4_vmc/special-cuts-and-regions/index.html"
  },
  {
    "breadcrumb": "VMC Project",
    "content": "Mailing List Bug Reports",
    "description": "Mailing List Bug Reports",
    "tags": [],
    "title": "Support",
    "uri": "/support/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Geant4 VMC",
    "content": "The default Geant4 VMC behaviour, defined by the Geant4 user mandatory classes and user action classes implemented in Geant4 VMC, can be customized by a user by providing his own class derived from TG4RunConfiguration.\nSuch customization is recommended for including a user own physics list. User has also the possibility to override detector construction and/or primary generation action classes and use an existing Geant4 geometry/primary generator definition with VMC. In other cases, though the customisation is possible and allowed by the design, it has not been tested and so it is not recommended especially for the novice users.\nUser Physics List The example of including user own physics list is provided in the VMC example E03 in Ex03RunConfiguration2 class.\nIn case, a user has registered his own physics list, he has a possibility to combine his own physics list with the TG4SpecialPhysicsList using TG4ComposedPhysics list as it is demonstrated in the VMC example E03, see Ex03RunConfiguration2, and he can then activate any special process as described above.( Another possibility, which requires more expertise, would be to register the special process physics constructor (eg. class TG4SpecialCutsPhysics) in a user own modular physics list.)\nUser Detector Construction Including of user geometry construction is also demonstrated in the example E03 in Ex03RunConfiguration1 class.\nRegions Since version 2.5, users have a possibility to define Geant4 regions by overriding the TG4VUserRegionConstruction class. Definition and including of such a user region construction class in the VMC application is demonstrated in the example E03 in Ex03RunConfiguration3 class.",
    "description": "The default Geant4 VMC behaviour, defined by the Geant4 user mandatory classes and user action classes implemented in Geant4 VMC, can be customized by a user by providing his own class derived from TG4RunConfiguration.\nSuch customization is recommended for including a user own physics list. User has also the possibility to override detector construction and/or primary generation action classes and use an existing Geant4 geometry/primary generator definition with VMC. In other cases, though the customisation is possible and allowed by the design, it has not been tested and so it is not recommended especially for the novice users.",
    "tags": [],
    "title": "User Geant4 Classes",
    "uri": "/user-guide/geant4_vmc/user-geant4-classes/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e Publications",
    "content": "VMC meeting, CERN, 03 June 2009   VMC meeting, CERN, 04 February 2009   VMC Open issues meeting, CERN, 22 September 2008   VMC Workshop, CERN, 29-30th November 2004",
    "description": "VMC meeting, CERN, 03 June 2009   VMC meeting, CERN, 04 February 2009   VMC Open issues meeting, CERN, 22 September 2008   VMC Workshop, CERN, 29-30th November 2004",
    "tags": [],
    "title": "Meetings (Old)",
    "uri": "/publications/meetings/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Geant4 VMC",
    "content": "Geant4 visualization and UI drivers can be in Geant4 VMC enabled via dedicated CMake configuration options. See more details in Installing Geant4 VMC.\nThe G3-like functions for visualization defined in TVirtualMC are overcome with the interactive visualization capabilities of both Root and Geant4 geometry modellers, that’s why user is encouraged to use these modeller directly. User can set Geant4 visualization options using Geant4 visualization commands, as it is illustrated in the VMC examples in g4vis.in macro.",
    "description": "Geant4 visualization and UI drivers can be in Geant4 VMC enabled via dedicated CMake configuration options. See more details in Installing Geant4 VMC.\nThe G3-like functions for visualization defined in TVirtualMC are overcome with the interactive visualization capabilities of both Root and Geant4 geometry modellers, that’s why user is encouraged to use these modeller directly. User can set Geant4 visualization options using Geant4 visualization commands, as it is illustrated in the VMC examples in g4vis.in macro.",
    "tags": [],
    "title": "Visualization",
    "uri": "/user-guide/geant4_vmc/visualization/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Geant4 VMC",
    "content": "The VMC interface provides a common denominator for all implemented MC’s and cannot cover all commands available in a Geant4 user session through Geant4 user interface (UI). Switching between the Root UI and the Geant4 UI gives a user the possibility of working with the native Geant4 UI. It is also possible to process a foreign command or a foreign macro in both UIs:\nFrom Root to Geant4 UI Switching UI: root [0] ((TGeant4*)gMC)-\u003eStartGeantUI(); Call Geant4 macro myMacro.in from Root: root [0] ((TGeant4*)gMC)-\u003eProcessGeantMacro(\"myMacro.in\"); Call Geant4 command from Root: root [0] ((TGeant4*)gMC)-\u003eProcessGeantCommand(\"/tracking/verbose 1\"); From Geant4 to Root UI Switching UI:\nIdle\u003e /mcControl/root Call Root macro “myMacro.C” from Geant4:\nIdle\u003e /mcControl/rootMacro myMacro Call Root command from Geant4:\nIdle\u003e /mcControl/rootCmd TBrowser b; Geant4 VMC commands Geant4 VMC implements several Geant4 UI commands associated with the objects defined in Geant4 VMC. To make their Geant4 VMC origin apparent, all these commands start with the prefix mc. Several Geant4 and Geant VMC commands are used in the g4config.in and g4vis.in macros in the VMC examples.\nYou can get an interactive help for all available commands by typing:\nIdle\u003e help or\nIdle\u003e /control/help",
    "description": "The VMC interface provides a common denominator for all implemented MC’s and cannot cover all commands available in a Geant4 user session through Geant4 user interface (UI). Switching between the Root UI and the Geant4 UI gives a user the possibility of working with the native Geant4 UI. It is also possible to process a foreign command or a foreign macro in both UIs:\nFrom Root to Geant4 UI Switching UI: root [0] ((TGeant4*)gMC)-\u003eStartGeantUI();",
    "tags": [],
    "title": "Switching User Interfaces",
    "uri": "/user-guide/geant4_vmc/switching-user-interfaces/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Geant4 VMC",
    "content": "Geant4 VMC with Multi-threading Geant4 Since version 3.00, Geant4 VMC supports running Geant4 in multi-threading (MT) mode. The VMC application will run automatically in MT mode when Geant4 VMC is built against Geant4 MT. This default behaviour can be changed via the option specified with creating TG4RunConfiguration passed as the fifth argument in TG4RunConfiguration constructor. (Note that the fourth argument, specialStacking option, cannot be omitted in this case.)\nThe VMC application which has not been migrated to MT should be run in a sequential mode, either with Geant4 VMC built against Geant4 sequential libraries or with Geant4 VMC built against Geant4 MT libraries with disabled multi-threading mode in TG4RunConfiguration. Otherwise its run will stop with an exception.\nAs the VMC classes work as a factory for creating Geant4 application objects (user initialization and user action classes, sensitive detector classes etc.), the main VMC objects: TGeant4 and MCApplication need to be created on both master and worker threads. Creating of all objects on worker threads is triggered from the Geant4 VMC classes. Users need just to implement new functions of TVirtualMCApplication which are then used to clone the application and its containing objects on workers: // required for running in MT virtual TVirtualMCApplication* CloneForWorker() const; // optional virtual void InitForWorker() const; virtual void BeginRunOnWorker(); virtual void FinishRunOnWorker(); virtual void Merge(TVirtualMCApplication* localMCApplication); Overriding of TVirtualMCApplication::CloneForWorker() is required, implementation of the other functions is optional.\nThe default number of threads, defined in Geant4, can be changed by setting the environment variable:\nexport G4FORCENUMBEROFTHREADS=4 or\nsetenv G4FORCENUMBEROFTHREADS 4 In applications which do not use G4Root navigation, it can be also changed via Geant4 UI command:\n/run/numberOfThreads 4 Migration of VMC application to Multi-threading Implement the required MCApplication function for MT: virtual TVirtualMCApplication* CloneForWorker() const; and, optionally also the other functions listed in the previous section.\nThe step 1. will also require to implement the constructors for cloning MC application, primary generator, sensitive detectors and eventually other classes instantiated in your application: MyClass(const MyClass\u0026 origin); In general, the objects which state is modified during event processing need to be created on workers while the objects which are used in read-only mode can be be shared. See the examples implementation as a guidance.\nReplace your Root manager with TMCRootManager, provided in the vmc library, which implements in a thread-safe way the functions previously provided in the VMC examples in the Ex02RootManager class.\nCarefully check thread-safety of your application code. Note that ROOT has to be initialized for multi-threading via calling TThread::Initialize(); just at start of your Root macro or your application.\nIn VMC examples, this call is executed either in g4libs.C macro or in the example main program.\nImplementation details \u0026 tips Dynamic loading of libraries requires to build Geant4 libraries with -ftls-model=global-init compilation flag (which is different from the Geant4 default, -ftls-model=initial-exec) and the tests show that it brings a performance penalty.\nThat’s why it is recommended to build the VMC application program linked with all libraries. Since Geant4 VMC 3.00 version, the main functions are provided for all VMC examples together with CMake configuration file for their build.\nBe careful to call TVirtualMCApplication standard constructor when cloning your application: TVirtualMCApplication(origin.GetName(),origin.GetTitle()), Check the existence of TMCRootManager in YourSD::Initialize() as when running in MT mode the TMCRootManager is not instantiated on master but only on workers. if ( TMCRootManager::Instance() ) Register(); The vmc package provides a locking mechanism similar to G4AutoLock, which can be used in the user application for handling the operations which are not thread-safe. (It is not demonstrated in the VMC examples, as there is no such use case where locking would be needed.) // An example of use TMCAutoLock in UserClass.cxx // Define mutex in a file scope namespace { // Mutex to lock application when performing not thread-safe operation TMCMutex unsafeOperationMutex = TMCMUTEX_INITIALIZER; } // In a function where unsafeOperation() is called { ... TMCAutoLock lm(\u0026unsafeOperationMutex); unsafeOperation(); lm.unlock(); ... }",
    "description": "Geant4 VMC with Multi-threading Geant4 Since version 3.00, Geant4 VMC supports running Geant4 in multi-threading (MT) mode. The VMC application will run automatically in MT mode when Geant4 VMC is built against Geant4 MT. This default behaviour can be changed via the option specified with creating TG4RunConfiguration passed as the fifth argument in TG4RunConfiguration constructor. (Note that the fourth argument, specialStacking option, cannot be omitted in this case.)\nThe VMC application which has not been migrated to MT should be run in a sequential mode, either with Geant4 VMC built against Geant4 sequential libraries or with Geant4 VMC built against Geant4 MT libraries with disabled multi-threading mode in TG4RunConfiguration. Otherwise its run will stop with an exception.",
    "tags": [],
    "title": "Multi-threaded Processing",
    "uri": "/user-guide/geant4_vmc/multi-threaded-processing/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Geant4 VMC",
    "content": "For many Geant4 VMC classes (like for Geant4 classes) the user can select a higher verbosity level and activate various printings which can help in understanding or debugging his application.\n/mcVerbose/all level Set the same verbose level (level \u003e= 0) to all Geant4 VMC objects. If level = 0 no printing is issued, the higher the level is more printings will be issued. /mcVerbose/geometryManager 2 Activate the debug printing from VGM geometry conversion (when geomRootToGeant4 option is selected) /mcVerbose/regionsManager 1 [2] [3] level=1: print the number of regions added via VMC level=2: print also the list of all volumes, the cuts in energy and calculated cuts in range level=3: print also all evaluated energy values /mcVerbose/composedPhysicsList 2 [3] [4] Set the same verbose level to the registed user physics lists.\nlevel=2: print the table of registered material/cuts couples (the range cuts and energy thresholds per material and particle) level=3: print also info from G4VUserPhysicsList::BuildPhysicsTable for each constructed particle level=4: print also info from G4VRangeToEnergyConverter::Convert() for each material /mcVerbose/specialPhysicsList 1 [4] level=1: print info about constructed special processes level=4: print also info from G4VRangeToEnergyConverter::Convert() for each material /mcVerbose/physicsExtDecayer 1 [2] level=1: print info about the constructed external decayer level=2: print also info about the particles which default decay was disabled by user /mcVerbose/primaryGeneratorAction 2 Print the list of all primary particles for each event. /mcVerbose/runAction 1 Print info at the start and the end of run including the time of the run. /mcVerbose/eventAction 1 [2] [3] level=1: print info at the start of event and the info about number of trajectories in the event if storing trajectories is activated level=2: print also info at the end of event including the time of the event level=3: print also info about the number of primary tracks processed and total number of tracks saved in stack in each event /mcVerbose/trackingAction 2 [3] level=2: print info at the start of each 10th primary track level=3: print also info at the start of each primary track Looping and problematic tracks In order to avoid infinite looping of tracks, Geant4 VMC defines a maximum number of steps allowed (the default value is 30000). User can customize this value by the command:\n/mcTracking/maxNofSteps value When a track reaches the maximum number of steps, Geant4 VMC activates the tracking verbose mode and let the track process a few more steps with printing the verbose info. This can help to identify the positon of the track in the geometry hierarchy. User can change this default behavior and set the desired level of verbosity:\n/mcTracking/loopVerbose level It is also possible to change the verbosity level for a selected track number using the commands:\n/mcTracking/newVerboseTrack trackID /mcTracking/newVerbose level How to apply Geant4 commands in a Root user session is explained at the section on Switching User Interfaces.",
    "description": "For many Geant4 VMC classes (like for Geant4 classes) the user can select a higher verbosity level and activate various printings which can help in understanding or debugging his application.\n/mcVerbose/all level Set the same verbose level (level \u003e= 0) to all Geant4 VMC objects. If level = 0 no printing is issued, the higher the level is more printings will be issued. /mcVerbose/geometryManager 2 Activate the debug printing from VGM geometry conversion (when geomRootToGeant4 option is selected) /mcVerbose/regionsManager 1 [2] [3] level=1: print the number of regions added via VMC level=2: print also the list of all volumes, the cuts in energy and calculated cuts in range level=3: print also all evaluated energy values /mcVerbose/composedPhysicsList 2 [3] [4] Set the same verbose level to the registed user physics lists.",
    "tags": [],
    "title": "Verbosity",
    "uri": "/user-guide/geant4_vmc/verbosity/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Geant4 VMC",
    "content": "For many Geant4 VMC classes (like for Geant4 classes) the user can select a higher verbosity level and activate various printings which can help in understanding or debugging his application. Here we list the commands useful rather for Geant4 VMC developers, for the commands useful for users see Verbosity.\n/mcVerbose/SDConstruction 2 Print the volumes IDs (implemented via G4VSensitiveDetector objects) and the maps between volumes and volume IDs. /mcVerbose/runManager 3 Print the logical volume store. /mcVerbose/trackManager 2 Print particleID info from SetTrackInformation. /mcVerbose/physicsManager 2 Print the parameter name and value from calls to Gstpar. /mcVerbose/particlesManager 2 Print the map between the names of special particles in Root and Geant4 (like geantino, opticalphoton, etc.); print also info about particles and ions defined by user. /mcVerbose/physicsProcessControlMap 1 /mcVerbose/physicsProcessMCMap 1 /mcVerbose/physicsStepLimiter 1 /mcVerbose/physicsUserParticles 1 Print info about each constructed special process; in case of map processes (physicsProcessControlMap, physicsProcessMCMap) print also whether the mapping was successful (all physics processes in the user physics list were identified in the maps).",
    "description": "For many Geant4 VMC classes (like for Geant4 classes) the user can select a higher verbosity level and activate various printings which can help in understanding or debugging his application. Here we list the commands useful rather for Geant4 VMC developers, for the commands useful for users see Verbosity.\n/mcVerbose/SDConstruction 2 Print the volumes IDs (implemented via G4VSensitiveDetector objects) and the maps between volumes and volume IDs. /mcVerbose/runManager 3 Print the logical volume store. /mcVerbose/trackManager 2 Print particleID info from SetTrackInformation. /mcVerbose/physicsManager 2 Print the parameter name and value from calls to Gstpar. /mcVerbose/particlesManager 2 Print the map between the names of special particles in Root and Geant4 (like geantino, opticalphoton, etc.); print also info about particles and ions defined by user. /mcVerbose/physicsProcessControlMap 1 /mcVerbose/physicsProcessMCMap 1 /mcVerbose/physicsStepLimiter 1 /mcVerbose/physicsUserParticles 1 Print info about each constructed special process; in case of map processes (physicsProcessControlMap, physicsProcessMCMap) print also whether the mapping was successful (all physics processes in the user physics list were identified in the maps).",
    "tags": [],
    "title": "Verbosity for Developers",
    "uri": "/user-guide/geant4_vmc/vebosity-for-developers/index.html"
  },
  {
    "breadcrumb": "VMC Project \u003e User Guide \u003e Geant4 VMC",
    "content": "Source code documentation has been generated from the source code by Doxygen.",
    "description": "Source code documentation has been generated from the source code by Doxygen.",
    "tags": [],
    "title": "Source code documentation",
    "uri": "/user-guide/geant4_vmc/source-code-documentation/index.html"
  },
  {
    "breadcrumb": "VMC Project",
    "content": "",
    "description": "",
    "tags": [],
    "title": "Categories",
    "uri": "/categories/index.html"
  },
  {
    "breadcrumb": "VMC Project",
    "content": "Copyright (C) 2019 CERN and copyright holders of VMC Project. This software is distributed under the terms of the GNU General Public License v3 (GPL Version 3), copied verbatim in the file “LICENSE”.\nCopyright holders Institutions:\nEuropean Organization for Nuclear Research (CERN), Geneva, Switzerland Institut de Physique Nucléaire dʼOrsay (IPNO), Université Paris-Sud, CNRS-IN2P3, Orsay, France Ruprecht Karls Universitaet Heidelberg (DE)*",
    "description": "Copyright (C) 2019 CERN and copyright holders of VMC Project. This software is distributed under the terms of the GNU General Public License v3 (GPL Version 3), copied verbatim in the file “LICENSE”.\nCopyright holders Institutions:\nEuropean Organization for Nuclear Research (CERN), Geneva, Switzerland Institut de Physique Nucléaire dʼOrsay (IPNO), Université Paris-Sud, CNRS-IN2P3, Orsay, France Ruprecht Karls Universitaet Heidelberg (DE)*",
    "tags": [],
    "title": "Copyright",
    "uri": "/copyright/index.html"
  },
  {
    "breadcrumb": "VMC Project",
    "content": "The concept of Virtual MonteCarlo has been developed by the ALICE Software Project . Authors: R.Brun1, F.Carminati1, I.Hrivnacova2, A.Morsch1\nThe integration with TGeo, G4Root: A. Gheata1\nThe multiple VMC engines: B. Volkel1,3\n1 European Organization for Nuclear Research (CERN), Geneva, Switzerland 2 Institut de Physique Nucléaire dʼOrsay (IPNO), Université Paris-Sud, CNRS-IN2P3, Orsay, France 3 Ruprecht Karls Universitaet Heidelberg (DE)*",
    "description": "The concept of Virtual MonteCarlo has been developed by the ALICE Software Project . Authors: R.Brun1, F.Carminati1, I.Hrivnacova2, A.Morsch1\nThe integration with TGeo, G4Root: A. Gheata1\nThe multiple VMC engines: B. Volkel1,3\n1 European Organization for Nuclear Research (CERN), Geneva, Switzerland 2 Institut de Physique Nucléaire dʼOrsay (IPNO), Université Paris-Sud, CNRS-IN2P3, Orsay, France 3 Ruprecht Karls Universitaet Heidelberg (DE)*",
    "tags": [],
    "title": "Credits",
    "uri": "/credits/index.html"
  },
  {
    "breadcrumb": "VMC Project",
    "content": "",
    "description": "",
    "tags": [],
    "title": "Tags",
    "uri": "/tags/index.html"
  },
  {
    "breadcrumb": "",
    "content": "Virtual Monte Carlo (VMC) defines an abstract layer between a detector simulation user code (MC application) and the Monte Carlo transport code (MC). In this way the user code is independent of any specific MC and can be used with different transport codes within the same simulation application.\nThe implementation of the interface is provided for two Monte Carlo transport codes, GEANT3 and Geant4. The implementation for the third Monte Carlo transport code, FLUKA, has been discontinued by the FLUKA team in 2010.\nVMC was developed by the ALICE Software Project and, after the complete removal of all dependencies from the experiment specific framework, it was included in ROOT and then gradually separated from ROOT into a stand-alone vmc-projet.\nThese new documentation pages were migrated from the ROOT documentation. If you have suggestions about how to improve this documentation, you can let us know. See Support.\nInfo Reference paper\nHřivnáčová I et al: The Virtual MonteCarlo,\nECONF C0303241:THJT006,2003; e-Print: cs.SE/0306005\nContact: root-vmc@cern.ch\nLast update: 02/02/2026",
    "description": "Virtual Monte Carlo (VMC) defines an abstract layer between a detector simulation user code (MC application) and the Monte Carlo transport code (MC). In this way the user code is independent of any specific MC and can be used with different transport codes within the same simulation application.\nThe implementation of the interface is provided for two Monte Carlo transport codes, GEANT3 and Geant4. The implementation for the third Monte Carlo transport code, FLUKA, has been discontinued by the FLUKA team in 2010.",
    "tags": [],
    "title": "VMC Project",
    "uri": "/index.html"
  }
]