Re: ROOT & GEANT

From: Nick van Eijndhoven (Nick@fys.ruu.nl)
Date: Tue Feb 24 1998 - 10:03:49 MET


*** Pasha Murat wrote :
> 
> 
> 
> 	hello rooters,
> 
> I believe that the issue of how one could simultaneously use the best available 
> tools from CERNLIB (first of all - GEANT3) and to interface them to C++ environment
> (which, for example, could be ROOT-based) is a pretty important one and there 
> already was some initial discussion on this subject initiated by Alexander Zvyagin.
> 
> here are some thoughts on this subject.
> 
> Let's assume that GEANT3 simulation code for the detector is available (which 
> is true for many detectors). Starting from this point one could move in several 
> directions.
> 
> 1. one could use G2ROOT and convert the detector geometry into ROOT TGeometry.
>    Then one could write a reconstruction code which would use this TGeometry. 
>    Then you run GEANT3 in standalone mode, use GH2ROOT to convert its output 
>    into ROOT structures and uses the results of conversion as an input for the 
>    reconstruction (which in this case could be written in C++ only).
> 
> 	What, however, about changing the geometry? - I'm talking about
> 	the detectors which design has not been finalized yet... On this 
>         way one has to change the description in G3, regenerate ROOT tree,
>         figure out how these changes impact the reconstruction code etc...
> 
> 2. To solve this problem Alexander Zvyagin suggested to make one more step 
>    and to feed the generated TGeometry back into GEANT3, so the geometry
>    could be maintained on C++ side in his case.
> 
>    I personally don't think that this is the right thing to do.
> 
>    - first of all, G3 geometry description is a bit more efficient than today's
>      ROOT description in terms of performance. G3 internally maintains a 
>      volume-to-shape hash table: 
>      CALL GSVOLU defines a shape (which, however, could be dimensioned), 
>      then CALL GSPOS defines a positioned shape (volume), 
>      which could have different dimensions. In case there are thousands of 
>      volume copies defined in the system (we have this at CDF) this hash table 
>      could provide a significant speedup of tracking.
>    - convertion from G3 into ROOT removes this hash table, copy number 
>      is being converted into ASCII and appended to 
>      the name of ROOT Tnode thing which is fine if all you need is to draw
>      the detector.
>      However when one wants to feed this structure back
>      into G3, one has to parse all the names and figure which volumes actually 
>      are  the copies of each other or to deal with a huge number of single-copy 
>      volumes.
>    - so I'd expect that G3-ROOT-G3 conversion of geometry will result in the
>      degradation of code performance;
>    - moreover, I see a lot of work here which has to be done and no real 
>      reason to do it.
> 
> 3. We at CDF have taken a very different approach. We also decided to use a 
>    mixed-language 
>    environment with detector geometry described by a set of C++ classes 
>    derived from some generic geometry class. This generic class interfaces
>    us to G3: its constructors(init methods) call GSPOS/GSVOLU. This allowed us 
>    to avoid explicit conversion of G3 geometry structure into C++, we 
>    just used what was already available and wrappered it in C++ jacket.
> 
> 4. As a result, the reconstruction code written in C++ could run directly on the
>    simulation output without knowing explicitly that the hits have been 
>    generated with G3 - one could use fast parametrized MC as well. One doesn't
>    need any convertion tools. When a new 
>    better than G3 MC code will be available, we could easily switch to it without
>    changing the overall structure of the offline code. On the other hand we can
>    all the advantages of generic geometry description provided by G3 already now.
>    
> 5  We are not using G3 tools to generate hits: GUSTEP passes all the necessary
>    information to C++ code, which directly stores hits in C++ structures using
>    whatever container classes are chosen (ROOT collections, STL containers, ...)
>    By doing this we saved ourselves from writing one more convertor...
>    Remember: available manpower (especially with knowledge of C++) is 
>    limited in HEP these days!
> 
> 5. To use ROOT visualization tools one could derive this generic class from 
>    TNode,  and to organize nodes into TGeometry, which in this case would be
>    maintained in parallel to G3 geometry structure, we didn't do it yet though.
>    G3 graphics still seems to be suitable for many practical applications.
> 
> 6. In conclusion (and we live in this mixed-language environment for 
>    already about 1.5 years) this way still seems to be the most efficient 
>    one to get G3 working in C++ environment, which in this case could be 
>    based on ROOT.
> 						Regards, Pasha.
> 
> 
Dear Pasha,
Having worked with GEANT3 for many years I already saw problems coming up
when I designed the WA93, WA98 and ALICE detector simulation packages.
Already for WA93 (in 1990 !) I decided NOT to use the GEANT3 hit structures
etc... but pass all hit info from the various sub-detectors via common
blocks into column wise ntuple output.
This means that (using H2ROOT) I can directly do all my reconstruction
within C++/ROOT right away without any modifications.
This has been already highly successfull and resulted in the fact that 
the ALICE reconstruction prototypes could be tested already on WA93 and WA98
real data !!!
The only problem for the ALICE simulation was that the new people 
responsible for HBOOK/PAW just refused to remove the stupid limit of
50000 columns for the cwn's, so that I had to work around it introducing
some 'funny' event structure.
Obviously now the time has come to also replace the GEANT3 machinery
into a C++/ROOT environment, which then for once and for all could also
remove the stupid limitation mentioned above, such that we can build
event structures as we plan to do in reality for ALICE.
The G2ROOT already nicely takes care of converting the GEOM of the detector,
which means that 'only' the physics processes and tracking are left to
be either interfaced or re-written within ROOT.
I guess that interfacing (a la minuit and some event generators, which 
has been done already) is the most easy way to get a working package
rather soon. Once that is available one could gradually start to re-write
the fortran into a new C++/ROOT based structure.
Unfortunately I am not enough C++ experienced to be a great help here,
however I have been heavily involved in the creation of the GEANT3
hadronic shower package (GEANH), so if some people would take up this effort
I volunteer to help wherever I can and will also volunteer to test the
physics and tracking in C++/ROOT by comparing the results with my
GEANT3 results of WA93, WA98 and ALICE.
To my opinion creating all sorts of conversion programs etc... is just
a temporary fix up and in the end will turn out to be just a loss of time.

                                                    Cheers,
                                                     Nick.

*----------------------------------------------------------------------*
 Dr. Nick van Eijndhoven                Department of Subatomic Physics
 email : nick@fys.ruu.nl                Utrecht University / NIKHEF
 tel. +31-30-2532331 (direct)           P.O. Box 80.000
 tel. +31-30-2531492 (secr.)            NL-3508 TA Utrecht
 fax. +31-30-2518689                    The Netherlands
 WWW : http://www.fys.ruu.nl/~nick      Office : Ornstein lab. 172
 ----------------------------------------------------------------------
 tel. +41-22-7679751 (direct)           CERN PPE Division / ALICE exp.
 tel. +41-22-7675857 (secr.)            CH-1211 Geneva 23
 fax. +41-22-7679480                    Switzerland
 CERN beep : 13+7294                    Office : B 160 1-012
*----------------------------------------------------------------------*



This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:30 MET