Muons, Inc.

g4beamline

g4beamline is a "Swiss Army Knife" for Geant4, optimized for simulating beamlines.

At present, g4beamline is still in beta testing. All interested users are welcome, and if you would like to participate in the beta testing, send email to Tom Roberts (look me up in the FNAL Phonebook).

The key aspect of g4beamline is that the input file defining the simulation is not significantly more complicated than the problem being simulated (by contrast, the C++ program to simulate a system in Geant4 is often several orders of magnitude more complicated than the problem). To make this possible, g4beamline does not give the user all of the power and flexibility of the underlying Geant4 toolkit; it does, however, provide enough flexibility to simulate many different systems that can be considered "beamlines" one way or another. For instance, there is a "cosmic-ray beam", and the notion of "beamline" is rather flexible. In use, one normally just lays out the beamline elements along the beam centerline, using "centerline coordinates" that rotate appropriately whenever needed (e.g. when a bending magnet is placed, or at a target to take a secondary beam off at an angle).

Note that no programming at all is required to simulate systems that use beamline elements already in g4beamline's repertoire. This includes bending magnets, quadrupoles, solenoids, materials of all types in the shape of boxes, cylinders, tubes, spheres, and polycones, RF cavities, and a few specialized elements for muon cooling. The distribution includes an executable program that runs on most modern versions of Linux (it is tested to run on RedHat 7.1 thru 9, and on Fedora Core 2). Moreover, the visualization capabilities of Geant4 are available with no further effort, including visualization using OpenInventor, OpenGL, HepRep, DAWN, VRML, and other viewers. The internal design of the program makes it relatively simple to add new commands and beamline elements to its repertoire (this does, however, require C++ programming).

A major limitation of g4beamline is that at present it does not simulate the performance of real-world detectors. It implements "virtual" detectors which sample the tracks that intersect them with the precision of a float, and measure all tracking variables (X,Y,Z,Px,Py,Pz,t,PDGid). Each virtualdetector generates an NTuple in the output file, which can be histogrammed with the appropriate program. At present, only Fermilab's HistoScope package is supported (root support is coming).

To help you decide whether or not you want to participate in the beta testing of g4beamline, here is a recent G4beamline User's Guide.

A simple example input file is example1.in, a simulation of a simple Gaussian beam going into 4 virtual detectors. As you can see, there are a handful of general definitions (the physics and beam commands), and then you just define the elements you need (box Beam, virtualdetector Det) and place them where they go (the 5 place commands). With the included HistoScope program, this is all that is needed to visualize the system, and to generate the histograms below (and, of course, many more).

*       example1.in 4/2/03 TJR
*
* Simple example g4beamline input file:
*       a 200 MeV mu+ Gaussian beam is tracked through 1-meter drift
*       spaces into four detectors

# QGSP is the "default" physics use-case for High Energy Physics
physics QGSP

# the beam is nominally headed in the +Z direction
beam gaussian particle=mu+ nEvents=1000 beamZ=0.0 \
        sigmaX=10.0 sigmaY=10.0 sigmaXp=0.100 sigmaYp=0.100 \
        meanMomentum=200.0 sigmaP=4.0 meanT=0.0 sigmaT=0.0

# BeamVis just shows where the beam comes from
box BeamVis width=100.0 height=100.0 length=0.1 material=Vacuum color=1,0,0
place BeamVis z=0

# define the detector
virtualdetector Det radius=1000.0 color=0,1,0

# place four detectors, putting their number into their names
place Det z=1000.0 rename=Det#
place Det z=2000.0 rename=Det#
place Det z=3000.0 rename=Det#
place Det z=4000.0 rename=Det#