- we need a working MC code today;
- we'd like to have a smooth transition path from the present simulation
framework, written in FORTRAN, to the future one, which presumably will
be implemented in C++;
As of today the only working for users MC code, which provides a general
algorithm of geometry description is Geant3 (G3).
So we don't have much choice:
- if we need a general MC code working today in C++ environment, we have to
interface this environment to G3.
Here I'd like to note that scenario 1 outlined by Rene is nothing
but the first step of scenario 2:
>
> Scenario 1
> ==========
> This could be quickly implemented. A set of wrapper classes (as proposed
> by Pasha) internaly call the existing Geant3 geometry and tracking
> package.
> The Hits classes as generated by GH2ROOT can be immediatly used.
> This solution does not require any changes in the existing Geant3
> framework.
>
> Scenario 2
> ==========
> Same as 1, but a bit more ambitious. The TNode companion classes for
> geometry and tracking are implemented in the Root framework as described
> above.
> The Geant3 geometry and tracking control routines must be reimplemented
> to take advantage of the improved TNode structure. I expect an
> improvement
> in tracking time with this solution. Physics algorithms are the standard
> Geant3 algorithms in Fortran. The low level Geant3 algorithms are used
> but reimplemented in C++ and double precision.
> The user sees only a C++ interface and the I/O (including for event
> generators) is taken care by the existing Root machinery.
>
So one could make the first step (keeping in mind scenario 2, however)
and after that Joe User could immediately
write his reconstruction code based on C++ geometry classes (TNode, TShape,
TBRIK etc) without being explicitly binded to G3. If at some point
an underlying tracing engine will change, this change could be made in a
transparent way.
Just to give an example:
---------------------------
we at CDF have done some preliminary studies of one of the early versions
of G4 source codes and got an impression that it would be pretty easy for
us to change the C++ geometry interface from the one
we are using now (to G3) to another one (to G4). However, having considered
all the circumstances, we've chosen G3 as the baseline MC for nearest
future.
I don't have a clear understanding of the time scale of G4 project,
however even one of the most enthusiastic with respect to this project
collaborations - BABAR - has developed non-G4 geometry model which
is being used in the reconstruction code...
I believe that scenario 2 could be implemented relatively fast.
Even trying to be pessimistic, I'd say that one year seems to be a
quite reasonable time scale for a software project, which has so
well-defined scope and starting point as this one.
Of course, there is some mechanical work involved, however there
is a lot of people who know G3 and could provide certain amount of help.
If a factor of 2 in performance could be reached on this way, this is
definitely a step to be done. In terms of performance this would be
something pretty close to the present expectations of G4 performance.
After this is done, we (physicists) have the tool we need and developers
have enough time to decide which path - #3 or #4 in Rene's notations -
has to be taken:
>
> Scenario 3
> ==========
> This is the scenario alternative to Geant4. We are aware of at least
> one public domain CAD system (in C) with a very elegant detector
> description
> and efficient "tracking like" system. A C++ geometry interface is easy
> to implement. Sophisticated CAD-like graphics (with cut views) is
> already
> implemented in this system (must be interfaced).
> The Physics package could be based on the latest incarnation of the
> FLUKA
> package. FLUKA has been used by many experiments to make background
> calculations and "solid" physics estimations. The problem with FLUKA
> is the poor geometry package. Ideas have already been discussed how
> to interface the CAD package with FLUKA. The global interface would be
> provided for Root (I/O, interactivity, GUI).
>
> Scenario 4
> ==========
> This scenario assumes that Geant4 will be a success for the geometry
> and the physics. However, we see a growing number of people concerned
> by the fact that the "official" solution for I/O is based on
> Objectivity.
> Root could be used as the I/O and User Interface engine for Geant4.
>
Concluding, I just want to repeat: Joe User needs a working code today
and if such a code is available he appreciates it, takes it and starts
using it. He is thankful to the authors, he works with them and
it doesn't matter too much for him whether the code he is using is
called G4, G3-prime or G5...
Regards, Pasha.