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