Re: Geometry classes

From: Rene Brun (Rene.Brun@cern.ch)
Date: Mon Jun 15 1998 - 15:48:26 MEST


Rutger van der Eijk wrote:
> 
> Hi all,
> 
> I am trying to use the ROOT Geometry classes to define the geometry of
> a testbeam setup. I want to use this for an event display, and eventually
> by deriving my own classes as a simple database for by detector setup.
> 
> Looking at the available classes it seems to be that the set of classes is
> not completely developed yet, i.e. some classes are not complete, and I
> would wish/like additions. Is there any activity at the moment on these
> classes, or do you advise me to use another mechanism to implement my
> detector geometry?
> 
> What I would need/like/miss:
> 
> 1) For some(/most) of the TShapes I'm not able to 'Get..()' the defining
> variables (i.e. like rMin/rMax etc.. of TTUBE). I would like to be able to
> do this, if I would use them as a sort of detector-database. The members
> are all protected, so I could derive from them. But I don't think this
> should be the right way.
> 

Hi Rudger,
I will add the getters for the geometry shapes in the coming version.

> 2) The 'first' contructor of TRotMatrix (i.e.
> 
> TRotMatrix(Text_t *name, Text_t *title, Double_t theta, Double_t phi,
> Double_t psi);
> 
> is not implemented.

True. You should get a message.

> 
> 3) TELTU seems to be implemented as a normal cylinder, not as a cylinder
> with elliptical cross section.

Several shapes are not functional (TSPHE, TELTU in particular).
Valery Fine is currently working on TSPHE.

> 
> 4) In my setup I have several types of detection elements/cells, which all
> have the shape of a 'cylinder' of a certain lenght and a varying shape of
> the cross section (i.e. cylinder, elliptical, honeycomb etc...) So I would
> like to have a shape with 'arbitrary' cross section (defined by an array
> of n points in 2d) and lenght l along the (z)-axis. As far as I know, I
> can't use any of the available TShapes to make such shapes. This could
> also be solved by the following...
> 
> 5) Geant (on which the classes are based) has the mechanism to combine
> volumes with simple boolean operations (GEOM020). It would be great to
> have a mechanism like this for the TShapes. We could begin by defining
> something as a TCompositeShape. Ofcourse I could implement this partly by
> defining a TNode which combines a few TNodes with the shapes I would like
> to combine. But in this way I only have the possibillity to 'add' ('union'
> in Geant) shapes, not to substract them! => not possible to make all
> shapes...
> 

No boolean operations are supported in this version. You must add
shapes to your node to simulate teh functionality.

> This are just some points which came to my mind the last few days working
> with the classes. I would like to stress that I am already quite impressed
> by the simple way I can define 'simple' geometries. I think my basic
> question is if there is anybody working/developping these classes at the
> moment, or if we can expect anything in the near (!) future.

We are not developping the geometry package at this point.
The Root geometry system was essentially developed to visualize
geometries coming from Geant3 and to provide very basic support
for event display. No tracking functionality is supported.
We obviously have many ideas of what could and should be implemented.
We are delaying the implementation waiting to see if geometry systems
such as the one developed for Geant4 offer some real and efficient
functionality. Some other candidates could also be considered.

Rene Brun



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