Install-G4-v4-10 » History » Version 3

« Previous - Version 3/4 (diff) - Next » - Current version
Paul Lebrun, 08/01/2016 11:42 AM


Introduction: goals and scope of this upgrade.

Installation and building under Geant4 v4.10. This will corresponds to a version of g4lbnf (the exec will no longer be called g4lbne, g4lbnf), tagged v3r4.pxxx. A Geant4 upgrade is highly recommended: it has numerous bug fixes (such the one G4cons, when we check overlaps, new Physics library that are more accurate, it allows to run multiple threads, thereby allow for one job to run multiple event loop, etc..) We took the opportunity to:

  • Remove code that was obsolete (no longer executer no matter what the G4UI data cards are).
  • Avoid the use of local variable that are "shadowing" other variables, as they prompts the current version of c++ compiler to issue warnings. It makes the code more readable, any ways.
  • V4.10.x requires the writer of the G4 user code to refer to the CLHEP name space for units. While we could get inserted a "use namespace CLHEP" statetenment, along with the ad-hoc include, we (well me P.Lebrun..) prefer to explicitly enter the namespace in-line. This is because I like to keep short variable names such "m", for variables on the stack, very local, such indices in a loop. So, the code now reads as:
       const double in = 2.54*CLHEP::cm;

    All previously defined options are supported, to the exception of the old MARS Absorber. We are suing by default the Sculpted Absorber. (A bit more work is still needed to construct what's behind this absorber, a few really minor geometry overlaps related to the alcove, irrelevant for neutrino spectrum generation, and, also, refurbishing and check the "simple absorber", made of homogeneous steel.

Building the g4lbnf executable.

Meanwhile, as mentioned above, we are using a C++ compiler (currently v4.9. a bit more picky, hopefully, giving us a more reliable application. As the GNUMakefile from geant4 package are declared deprecated, we also opted for upgrading the build system: we are now using cmake. In addition, the corresponding CMakeList.txt supports the "building out-of-source" So, here is the recipe, step by step.

Get the source code.

See above, the git clone business. This has not changed. you'll find find a subdirectory .../g4lbne (or, ".../myWhatever" should you chose a non-default such directory name for source install directory in git clone command), after you git-clone.

Find a place to build...

Any "work" directory will do. Preferably, not the subdirectory ".../g4lbne", or the directory where the git clone will install the source. So, pick a directory name ("build", for instance), and

% mkdir build
% cd build 

Setting things up: execute the fermilab setups.

In the directory .../g4lbne/setups/ , you find various setups.  For those who are building on dunegpm0x machines, there is  a, suitable for building the code and start running.  Some customization is required for those running on other machines, or, at Fermilab, if other Fermilab products are used while running G4blnf, or ancillary programs. So, for now...
% source .../g4lbne/setups/

where "..." must be replace by a valid path, as usual.

Preparing to compile and link.

In the "build" directory,

% cmake .../g4lbne

where the "..." is the path for the directory where the sources are installed. In that directory, cmake will find the CMakeLists.txt that contains all the instructions that are needed to build the UNIX Makefile.

cmake will spit out the following info


<lbnegpvm03> cmake ../g4lbne
-- The C compiler identification is GNU 4.9.2
-- The CXX compiler identification is GNU 4.9.2
-- Check for working C compiler: /grid/fermiapp/products/larsoft/gcc/v4_9_2/Linux64bit+2.6-2.12/bin/gcc
-- Check for working C compiler: /grid/fermiapp/products/larsoft/gcc/v4_9_2/Linux64bit+2.6-2.12/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /grid/fermiapp/products/larsoft/gcc/v4_9_2/Linux64bit+2.6-2.12/bin/g++
-- Check for working CXX compiler: /grid/fermiapp/products/larsoft/gcc/v4_9_2/Linux64bit+2.6-2.12/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found ROOT: /grid/fermiapp/products/larsoft/root/v5_34_30/Linux64bit+2.6-2.12-e7-nu-prof/bin/root-config  
-- Configuring done
-- Generating done
-- Build files have been written to: /lbne/app/users/lebrun/work2/devNov16/build

Compiling and linking

Just type:

% make all 

And you done! You should find in the "build" directory:

%ls -l

And you'll get:

total 9172
-rw-rw-r-- 1 lebrun lbne   18221 Nov 18 13:11 CMakeCache.txt
drwxrwxr-x 6 lebrun lbne    2048 Nov 18 13:14 CMakeFiles
-rw-rw-r-- 1 lebrun lbne   40207 Nov 18 13:11 Makefile
-rw-rw-r-- 1 lebrun lbne    2253 Nov 18 13:11 cmake_install.cmake
-rwxrwxr-x 1 lebrun lbne 9320035 Nov 18 13:14 g4lbnf

g4lbnf is the executable you want to run..

Running, locally

Currently, the our CMakelists.txt has no provision for installation of the executable g4lbnf. This is fine to run locally, or under the Intensity Frontier FermiGrid. Not under the OpenGrid.
Make g4lbne a "ups re-locatable" product should be considered, but it is a bit beyond the scope of this upgrade.

So, just do

./g4lbnf .../g4lbne/macros/myPreferedMacros.mac 

Running on FermiGrid, using the Intensity Frontier products

We need to update the ProductionScripts. Since I am using my own, and I suspect most of us are using a customize version of what Laura wrote, that might be up to you!. Yet, I hope Laura will update the "standard" one, and we'll go from there..