Hello, 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.
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:30 MET