Re: [ROOT] TNode::IsIn(x,y,z) and TNode::DistanceToEdge(x,y,z)

From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Wed Jan 17 2001 - 14:26:46 MET


Hi René et al, 

On Tue, 16 Jan 2001 21:58:42 +0100 (MET)
Rene Brun <brun@pcbrun.cern.ch> wrote
concerning ": Re: [ROOT] TNode::IsIn(x,y,z) and TNode::DistanceToEdge(x,y,z)":
> Hi Christian,
> No, TNode/TGeometry do not provide the equivalent of the Geant3
> geometry package. I am well aware that we have many requests
> to provide a coherent geometry system.
> We are currently exploring several directions.
> In the framework of the ALICE experiment, we have developed
> the AliRoot system that includes a set of classes such as
> TGeant3 and TGeant4 that provide a full interface to the
> Geant3 and Geant4 simuation systems.

Well, the reason I ask has little (but some) to do with detector
simulation. Rather, I was more interrested in using such methods for
offline analysis. Here's an example: 

  Suppose you had the geometry of some experiment in some database
  (ROOT, MySQL, Objectivity(?)), that is in essence TShape, TNode,
  TRotMatrix, etc. objects stored some where. 

  Now, in you offline analysis, you'd read that geometry into a
  TGeometry object, and you'd have classes requesting geometry
  information from that object. 

  One thing you'd probably like to do, is to connect some detector
  hits, say in a TPC, to form tracks. Suppose these a straight lines,
  then a track is described by an origin and a direction (2x3D
  vectors). Now you'd really like to get the point where the track
  exists you detector volume. That could be done using 

    Double_t TNode::DistanceToEdge(Double_t x,  Double_t y,  Double_t z, 
  				   Double_t vx, Double_t vy, Double_t vz)

  or similar, and then go that long along the trajectory to get
  the point on surface where the track leaves the volume. 

If the geometry is largely BRIKs it's not a major problem, but if you
have other shapes, then it get much more complex, and a general
solution is prefered. 

I hope this illustrates the usefulness of such methods, even though
ROOT isn't intended to be a GEometry ANd Traking (detector simulation)
framework.

Of course, having a full geometry description of a detector in ROOT
objects (including tracking mediums), one can easily call GEANT3 (and
GEANT4?) subroutines (methods) to export that geometry to a simulation
framework, of course under the control of ROOT (as in AliROOT). This
is also why I asked wether TNodeDiv would be implemented. 

Yours, 

Christian  -----------------------------------------------------------
Holm Christensen                             Phone:  (+45) 35 35 96 91 
  Sankt Hansgade 23, 1. th.                  Office: (+45) 353  25 305 
  DK-2200 Copenhagen N                       Web:    www.nbi.dk/~cholm    
  Denmark                                    Email:       cholm@nbi.dk



This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:33 MET