Ideas on the Root/Geant discussion

From: Pasha Murat (murat@cdfsga.fnal.gov)
Date: Wed Feb 25 1998 - 22:56:12 MET


	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