Both approaches are offered in the present package. The RZ conversion is implemented as a standalone program which analyzes the RZ file to determine the G3 calls required to build it, and makes the appropriate calls to the G3->G4 conversion package. The conversion code consists of replacements for Geant3 geometry and other data structure definition routines. These serve as wrappers for the real routines; they perform the G3->G4 conversion and also call the original G3 routine (except in the case of RZ file conversion). For many Geant3 applications it is necessary that the G3 code be executed so that the geometry is actually built during the conversion process, because user code often makes reference during geometry building to data structures generated earlier via GFxxxx calls (eg. very often tracking medium structures are accessed during geometry building).
Of course, a wrapper routine must have a name different from the routine it is wrapping. Modifying the G3 libraries to rename the Gxxxxx routines would be a major hassle for the general user, so the approach taken is to change the names of the conversion routines (and therefore the routines referenced in user code to do the conversion) instead. The conversion routines are named Kxxxxx rather than Gxxxxx. A Perl script is provided to convert user routines to call Kxxxxx rather than Gxxxxx (and back again).
The conversion routines offer two approaches to on-the-fly conversion to Geant4:
In the latter approach no compile/rebuild of the G4 program is necessary at all to incorporate a new or revised G3 geometry specification; the call list interpreter will just interpret the new file. Thus the former may be preferable where the G3-converted geometry is stable, the latter where updates to the G3 geometry need to be quickly and easily available to the G4 program.
g3tog4.pl uginit.f
performs Gxxxxx->Kxxxxx conversion on uginit.f and saves an
unmodified copy in uginit.f.old. Thus an easy way to incorporate
this conversion step is to add it to the script that does Fortran
compilation for your application's build procedure.
call g3tog4(lunl,lunc,' ')
early in your program, before any Geant routines are called.
Parameters:
LUNL =0: no call list output generated
>0: call list written to unit LUNL; filename g3calls.dat
is opened internally
<0: call list written to unit -LUNL; file assumed already
open
LUNC =0: no C++ code is generated
>0: C++ code wrapper written to g3tog4code.cc. Function
void g3tog4code();
should be called to run the code. Actual g3tog4 C++
sources are written to g3tog4code_nn.cc where nn
goes from 01 to the number of files required.
<0: not supported.
OPT ' ' no options supported at present
g3calls.dat
g3tog4code.cc
g3tog4code_nn.cc
depending on the parameters you passed to subroutine g3tog4.
rztog4 rzfile.name
and generates a call list file (g3calls.dat) and C++ source code
(g3tog4code*.cc).
It is trivial to use the directly-generated C++ in G4. g4geom.cc does this and is a few lines long:
void g3tog4code();
main()
{
g3tog4code();
}
g4geom.com is the needed linker. The G3->G4 tools haven't yet been
organized with a makefile and link library, but soon will be.
The C++ code generated directly by the converter looks very much like Fortran code; it uses (for compactness) a set of C++ routines which are a direct mapping to the Geant3 routines. The real content of the Geant3 to Geant4 conversion is in the G4gxxxx.cc routines, which implement the Geant3 routines in terms of Geant4.
Here are examples of the implementation of Geant3 routines in Geant4:
The package has been tested with the geometries of BaBar, CMS, Atlas, Zeus, L3, and Opal. The only problem was with Atlas, and the problem is due to a bug in the Atlas geometry.