In the past few days, a discussion about Root or/and Geant has been initiated by Pasha Murat , Alexander Zvyagin and Nick van Eijndhoven. I would like to add some comments to this discussion. Let's start with some Geant history =================================== When I created the Geant3 package (17 years ago!), we were using a Vax780 as the development machine in the OPAL experiment. This machine had 1 Megabyte of RAM and quite representative of the typical computing environment at this time. It was essential to design a geometry package minimizing the expansion of the geometry data structures in memory without penalizing too much the execution time. I designed the JVOLUM structure with recursivity and we could describe the full OPAL detector with about 100 Kbytes in memory. This data structure has been successfully used by many experiments including the LHC detectors. Only minor modifications were made in this long period of time. When we started the Root project in 1995, I implemented the TNode class taking into account the experience with JVOLUM and also the fact that today computers have more than 1 Megabyte of memory. I thought that one could relax a little bit on the memory requirements if in exchange one could gain time in the tracking phase. To summarize the problem with JVOLUM: A typical detector geometry has up to 12, 15 levels in the hierarchy. When going up or down in the hierarchy, the Geant3 geometry package has to recompute the product of the rotation matrices and the sum of the translation vectors. This process is responsible for at least 50 per cent of the tracking time in most detectors. In addition, the volume parameters have to be recomputed to take into account the current matrix. This also consumes a substantial fraction of the tracking time. The Root TNode class ==================== The Root TNode class eliminates in principle this overhead at the expense of more memory because all detector copies are stored in memory with their final parameters. Using the g2root converter, I have checked that a typical TNode structure consumes between 1 and 30 Megabytes for large detectors. Obviously 30 Megs may seem a lot today, but we are designing a new system and in a few years this will prove to be the right direction. Problem with TNode ================== Well (!!). As mentionned by Pasha, TNode can only be used now in Root to show a 3-D detector view. Not very useful ! TNode was intended to have companion classes for the tracking. I did not develop these classes essentially for political reasons. At the time (95), the Geant4 project claimed that by end of 96, they will have a package 3 times faster than Geant3 and with an equivalent functionality (if not better) (see DRDC minutes of October 95). As I was suspecting, this estimation was a bit optimistic and most of us are still waiting for a package faster and simpler to use than Geant3. What I should have implemented ============================== I had the intention to rewrite the kernel of the Geant3 tracking system to take advantage of the new TNode functionality, still retaining the geometry algorithms (not the code) and the Physics algorithms implemented in Fortran. The Geant3 geometry package is trivial to redesign in C++ taking advantage of OO techniques. Double precision was also essential in this rewrite. In my mind, keeping the algorithms was important. It took us many years of experience with real detectors to understand many problems (precision, boundary crossing, approximations in step sizes in case of mag field, multiple scattering, energy loss,etc). These geometry/tracking classes in Root could have been very useful to move Fortran users to C++. It was important in my mind to provide a new API, keeping solid algorithms, rewriting layers known to be problematic. A smooth transition could have taken place. What could be done? =================== When we announced the GH2ROOT code generator in January, the idea was to help users with hundred of Gibabytes of Geant3 files willing to move to C++. GH2ROOT solves in an elegant way the problem of the HITS classes. The classes generated can be used not only to convert Geant3 Zebra (or like) files to a Root Tree (with all the advantages of PAW ntuples as mentionned by Nick), but also in the context of a non-Geant3 based MonteCarlo. The classes generated are based on the structure we proposed in the context of ATLFast++ (The fast Atlas MonteCarlo). These classes could also be used in the context of Geant4 when this product will be available. 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. 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. Sorry, if I have been a bit long in this article. I am interested by reactions on the various scenarios. Political obstacles can always be resolved. A public and open discussion is essential in this area. Rene Brun
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:30 MET