Dear simulators,
Gradually becoming old (but maybe not wise) I have read through the
various mails concerning the ROOT & GEANT discussion and together
with my own viewpoints and experience and seeing the upcoming needs
for the ALICE detector development, I gave it a good thought in front
of the fire place (it rains like hell here) with a glass of cognac
(to get inspiration). Here are some results of the first session,
which to my opinion provides the most efficient way to have on a not
too long time scale a first version available for evaluation.
As I mentioned earlier, already in a very early stage (1990) I decided
NOT to use the GEANT3 hit storage format, because ntuple output
(and PAW analysis afterwards) seemed much more powerful to me.
This turned out to be right (I now use ROOT directly to investigate
my 'old GEANT3' produced data after applying h2root), and now the
next improvement is to use the ROOT TTree output instead of ntuples.
==> So, in view of making a ROOT based detector sim. package my opinion
is that one should not put much effort in making the old GEANT3 hit
structures available.
The new package will directly use the ROOT I/O and TTree ouput
of the various detector signals seems the best to me.
Having G2ROOT available to convert GEANT3->ROOT geom structures is
a great advantage, since most of the effort in det. sim. is going
into the geom and material description.
Furthermore, in checking the performance of the new sim. package the
user has to be sure that the det. description is the same.
==> The new det. sim. package should start from the existing ROOT
geom engine.
Since new designs don't have a GEANT3 geom set-up yet, the new
package should contain some facility to produce the ROOT geom
directly from the technical drawing files.
Talking to people at several workshops (e.g. NIKHEF, Utrecht, ESTEC
and SRON) an interface to (auto)CAD would be a good thing.
Once agreed on the above, the physics processes and particle tracking has
to be implemented.
Obviously in the end this should be implemented purely in ANSI C++,
but since this will take some time the best way seems to me to interface
the existing GEANT3 'fortran coded' tracking with the ROOT geom.
Since the conversion from GEANT3->ROOT geom is known in detail (g2root)
this interfacing seems very feasable on a rather short term to me
(one could even think of internally converting ROOT->GEANT3 geom by
means of filling the GEANT3 ZEBRA banks, such that the ordinary GEANT3
tracking and physics etc... can be used).
This way, people can do GEANT3->ROOT geom as a start, then modify the
ROOT geom for new designs (using CAD if available) and still perform
tracking etc... (using the old interfaced GEANT3, which is hidden
for the user) but the gain is then that the produced output files
are ROOT TTrees, such that the ROOT/C++ based reconstruction prototypes
can be used/tested directly. In addition one has the whole ROOT machinery
available to investigate the detector geom and detector signals
interactively.
This would to my opinion be a very nice basis to start with, whereas
in the mean time more and more parts of the GEANT3 tracking etc...
can be re-written in C++, which should be transparant for the user.
==> So, in phase I one should not start to re-write the tracking and
physics of GEANT3, but 'only' interface the existing fortran based
code with the ROOT geom engine and I/O capabilities.
In view of the time pressure, a basic functionality is most important.
==> Don't spend much effort on designing sexy user interfaces etc...,
investigation of geoms and detector signals can directly use the
ROOT tools already available. All other gadgets can be invented
once people have actually used the basic structure and get an idea
of further needs.
Once such a phase I ROOT based det. sim. is available, the experience
of the users will certainly guide us (like it happened with GEANT3)
in making up our minds of how to structure a phase II version.
However, the most important item to my opinion is that we should have
a package available (like described above) while the LHC detectors
are still in the design phase. As outlined above such a package
would also stimulate the reconstruction (and maybe also DAQ) algorithms
to be developed within ROOT.
I hope these thoughts will be of any use in planning the new
detector simulation era.
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