Let me present here kind of "Joe User's" considerations on what the optimal (from Joe's point of view) development path of the MC package he needs. I'd start from formulating some more or less obvious requirements which greatly simplify the logic of the next steps: - we need a working MC code today; - we'd like to have a smooth transition path from the present simulation framework, written in FORTRAN, to the future one, which presumably will be implemented in C++; As of today the only working for users MC code, which provides a general algorithm of geometry description is Geant3 (G3). So we don't have much choice: - if we need a general MC code working today in C++ environment, we have to interface this environment to G3. Here I'd like to note that scenario 1 outlined by Rene is nothing but the first step of scenario 2: > > 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. > So one could make the first step (keeping in mind scenario 2, however) and after that Joe User could immediately write his reconstruction code based on C++ geometry classes (TNode, TShape, TBRIK etc) without being explicitly binded to G3. If at some point an underlying tracing engine will change, this change could be made in a transparent way. Just to give an example: --------------------------- we at CDF have done some preliminary studies of one of the early versions of G4 source codes and got an impression that it would be pretty easy for us to change the C++ geometry interface from the one we are using now (to G3) to another one (to G4). However, having considered all the circumstances, we've chosen G3 as the baseline MC for nearest future. I don't have a clear understanding of the time scale of G4 project, however even one of the most enthusiastic with respect to this project collaborations - BABAR - has developed non-G4 geometry model which is being used in the reconstruction code... I believe that scenario 2 could be implemented relatively fast. Even trying to be pessimistic, I'd say that one year seems to be a quite reasonable time scale for a software project, which has so well-defined scope and starting point as this one. Of course, there is some mechanical work involved, however there is a lot of people who know G3 and could provide certain amount of help. If a factor of 2 in performance could be reached on this way, this is definitely a step to be done. In terms of performance this would be something pretty close to the present expectations of G4 performance. After this is done, we (physicists) have the tool we need and developers have enough time to decide which path - #3 or #4 in Rene's notations - has to be taken: > > 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. > Concluding, I just want to repeat: Joe User needs a working code today and if such a code is available he appreciates it, takes it and starts using it. He is thankful to the authors, he works with them and it doesn't matter too much for him whether the code he is using is called G4, G3-prime or G5... Regards, Pasha.
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:30 MET