Federico Carminati writes:
> 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.
Recent discussion on the subject summarized well the status and
current problems with general purpose MC code in "post-GEANT3" period.
It is quite clear now that in the next generation of MC code at least 2 of 4
major components (I'd consider (G)UI and I/O model separately) should be
redesigned:
- geometry engine has to be reimplemented on a different algorithmic basis
and in double precision (which implies changing the run-time data model);
- outdated (today!) G3 user interface needs to be replaced
- it is less clear what (if anything) needs to be done with physics
engine, which from the algorithmic point of view is well separated from
2 other components.
However there always exists a problem of the first step. A complete redesign
of a package with the functionality of GEANT3 is a challenging task with
a time scale of more than 1 year. One of the potential dangers one could see
is that during the first development cycle (time necessary to deliver
version 1.0) there will be no interaction between the users and developers.
Having no alternative, physicists would continue using the existing package
(G3) waiting for the developers to provide something with the functionality
at least not less than that of Geant3, which is based on more than 15
years of HEP experience, which first of all means 15 years of fixing the bugs
and polishing the user interface (with both being iterative processes in their
nature).
> 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.
It seems therefore to be quite important to make a first step which would allow
to produce output on a reasonably short time scale. In this case physicists
could immediately start using the new product and provide the feedback.
One of the possibilities is to start from designing a C++ interface to
geometry engine, which would be compatible
with Geant3, during the transition period would allow its use in the
reconstruction code written by Tevatron/RHIC/LHC collaborations (and of
course by all the others)
and at the same time would make it possible to redesign the internals of
geometry engine in a way hidden from the users. In this way developers and
users would make this step almost synchronously.
ROOT I/O engine and user interface seem to provide an adequate starting point
for MC project of the next decade.
Physics engine deserves special discussion. However one could think of it as
of being the next step. Initially one could use the existing simulation of physics
processes as they are coded in Geant3 by interfacing them to the new geometry
framework: QED didn't change over the last years and one woudn't expect
hadronic processes to be simulated better because of the change of programming
language. What is important is that one could start from implementing the
interfaces to the new engines, which is a relatively small part of
work and could be done fast. After this is done there is quite a room for
work on the internals of the engines, which may take significantly more time
than redesigning the interfaces. However during this period of time physicists
could already use all the benefits provided by the new interfaces.
This evolutionary way of development could be very efficient in practice.
Regards, Pasha.