Re: ROOT & GEANT (fwd)
Federico Carminati (Federico.Carminati@cern.ch)
Wed, 4 Mar 1998 10:59:06 +0100 (MET)
Hello RooTers,
My two pennies worth of opinion on the matter. It is clear that a gap
exists in the availability of simulation programs for HEP.
The large effort which is being invested in GEANT4 holds the promise
of an all-things-to-all-men solution, but cannot reasonably be expected to
be in full production before some time, which is by the way hard to
estimate because, to my knowledge, only very few people have used the code
up to now.
GEANT3 has not be maintained actively since its last release, sometime
in 1994. Since then a number of shortcomings have been pointed out, and,
again to my knowledge, not all of them have been corrected. Apart from
this, the improvement of the leading simulation codes is continuous, and
if GEANT 3 has ever been one of the best tools of CERNLIB, this may be
less true now. It may still be "good enough" for many applications, but
this depends on the application, and has to be judged case by case.
The moral of the above is that it is not possible NOW to pick up and
use a general purpose simulation program from CERN which is both
thoroughly field-tested and maintained, hence the search for alternative
solutions, of which the original mail was one example.
As I see it, a simulation program is composed by three main elements:
the geometry engine, the physics engine and the GUI/IO part. A never
accomplished dream is to have the same geometry engine for reconstruction
and simulation.
Unfortunately for the moment the only geometry engine available is the
GEANT3 one. The Root structure can hold geometrical structures, but does
not have the algorithms necessary for performing transport. Adding them is
a non-trivial task, which involves a deep knowledge of geometrical
modelling.
The GEANT4 geometry could be an adequate engine in this context, but
this alternative has to be checked with the GEANT4 team. The GEANT3 engine
is flawed by the internal use of ZEBRA, which was in fact an advantage, in
my view, when ZEBRA was the standard memory manager, but makes it now a
"strange animal". Just "wrapping" it would not help solving the connected
precision problem. While all computations are done in double precision,
rotation matrixes and volume parameters are stored in single precision in
ZEBRA banks, and this gives a precision of 10 microns in 10 meters in the
best of cases, which may or may not be enough depending on the size of
your setup. Double precision parameters can be stored in Zebra banks, but
much should be changed in the present GEANT3 code.
Recasting the algorithms of GEANT3 in C++ using the Root structure
may be a viable solution. This would not give a modern geometrical
modeller, but may well be an acceptable and backward compatible (via
G2ROOT) option. Again the problem is not the recasting of the distance
algorithms, which are relatively simple, but the walking up and down of
the tree, where most of the optimisation lies. Also the connection between
geometry and tracking is not as modular as it should be in GEANT3, and the
whole operation may involve many changes in the GEANT3 code itself.
Undoubtedly this would solve all the problems of geometry maintenance
and of relation between reconstruction and simulation geometrical
description, and it will be an "evolutive solution". I do not agree with
the remarks on the performance contained in the original message. The way
geometry was stored in GEANT3 came from the needs and limitations of the
machines available 20 years ago. Modern programs tend to avoid recursive
descriptions a la GEANT3 and "lay out" in memory the geometrical structure
as much as possible, to avoid lengthy re-computations of the volume
parameters. The ROOT geometry description has evolved in this direction
and it may form the basis for a more efficient geometrical modeller. I
frankly cannot evaluate the work investment needed for this approach.
A more far-fetched solution would be to take a modern geometrical
model program and adapt it to our needs. There is a lot of folklore on the
notion that available CAD programs are not suitable for HEP transport and
very little experience on it. Some of these program are even available on
a free basis and I have done few tests with them. Here the problem of the
interface with the material and cross sections may be important.
As far as the rest is concerned, I could not agree more with the
remarks of the mail on the necessity to live in a multi-lingual
environment for some time to come, and I consider the experience reported
in the mail as extremely valuable.
Regards, Fed