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