G4Beamline

Introduction

G4Beamline is a layer of code on top of geant4. It provides a way to create a geant geometry from relatively simple scripts instead of fairly complex geant c++ API code. It is provided by Tom Roberts at Muons Inc. It can be discussed in the google group and downloaded here. We update and install it occasionally, as needed. We move the binaries into a fake UPS product.

Building Version 3.08

Author: Kevin Lynch

We're going to build this package using UPS products in /cvmfs/mu2e.opensciencegrid.org/artexternals. This is not the intended use of the source package distributed by Tom, so we're going to have to do some preparation ahead of time. Described here is a build on an SLF7.9 machine, configured as one of the Mu2e grid interactive login nodes.

Prereqs

Although not true in earlier versions, G4Beamline 3.08 builds against external versions of Root and Geant4 (with Qt viewer support) and can utilize externally installed Geant4 datasets with appropriate modifications.

UPS products

• mu2einit
• setup root -q e26:prof:p3913 v6_26_06
  • Gives a compatible Root and sets up gcc 12
• setup cmake v3_24_1
• setup geant4 v4_11_0_p03 -q e26:prof:qt
  • Transitively configures data sets and Qt support

Later on mu2ebuild01, we also needed:

• setup fftw v3_3_10
• export FFTW_DIR=$FFTW_FQ_DIR
• export GSL_DIR=$GSL_FQ_DIR

Code patches

Two code patches are needed:

• G4beamline by default insists on downloading and organizing the Geant4 data sets in its own directory. This is dumb. Edit g4bl/Geant4Data.hh, and change the default argument to Geant4Data::setup() from true to false. This allows G4beamline and Geant4 to find the data files using the environment variables set up by the individual Geant4 data file UPS products. This default is dumb.
• There's a head scratching correctness bug in g4bl/BLEvaluator.hh: new is used to allocate space, while free is used to deallocate. At line 114 (in BLEvaluator::evaluate() replace free(in); with delete[] in;

There are numerous gcc 12 linter warnings, but I don't think they effect the operation of the code.

Build step

Now we build according to the instructions in the BUILD.txt file. Don't bother trying to use the standard cmake options ... the cmake configuration in the code distribution seems to override most of them to force the build to do things exactly one way. Don't fight it; let's just fix it after the build is done. The source unpacks into a directory named G4beamline-3.08-source. Create a parallel G4beamline-3.08-build directory. Then:

cd G4beamline-3.08-build
cmake ../G4beamline-3.08-source
cmake --build . -j 4 --config Release --target install

Prepare to wait ... the compilation runs pretty quickly, but the "install" step is ridiculous and takes forever. Install copies all the .so files in the dependency graph into a lib directory. None of which you need, because they're already in the appropriate source paths. Finally, the entire set of build artifacts and copied libraries are shoved into a tar file named G4beamline-3.08.tar.gz.

The only directories we need in that tar file are

• bin
• doc
• examples
• README.txt
• share
• test
• validation

Delete everything else, and retar.

Running and testing

Install this final binary distribution. Add the bin directory to the path, and set the G4BL_DIR environment variable; sourcing bin/g4bl-setup.sh does both of these steps. The command

g4bltest

runs many unit tests