Re: Level of a TGeoNode/TGeoVolume

Hi Andrei,

On Wed, 2005-11-30 at 15:22 +0100, Andrei Gheata wrote:
> Hi Christian,
>
> I do not really see the point for such a complex query in your case.
> Indeed, a "geometry iterator" may do the job, but such a search by name
> may be always error prone.

Of course.

> Generally one knows a priory the depth of any
> node in his geometry since he has to build it.

Not if you have alternative geometries and you're reading the geometry from file or the like. Take ALICE as an example. Suppose you have alternative geometry definitions for some sub-detector - say the FMD. You then run some job to produce the full geometry of ALICE, an write it to a file. Later you read in that geometry from the file, to do further simulation, digitisation, reconstruction, or the like. You apply some alignment corrections to that geometry. The FMD simulation, digitisation, reconstruction, etc. code would then have to employ some way of finding out where exactly (how deep) the senstive volumes are to do the job. Now, it would be good if the FMD code could query the geometry manager just how deep a given node (volume) is.

Another good thing to have, would be to be able to figure out the full path of a node, so that one can declare that path to be a physical volume. I've attached a modified script that does this too.

> I agree that there might
> be cases when the depth may not be constant (e.g. positioning the same
> volume in containers at different depths), but if this is the case the
> iterator will not necessary give you the right answer...

Why not? Can you really have nodes that does not have unique names? And if so, one could check for that by looping over the full geometry, and flag it as an error. Note, that the function `CheckNodes' can in principle start the search anywhere.

> The argument
> with complicated volume made by composition does not stand since there
> you do not use volumes, but shapes so you can provide a different
> identifier (name).

This was just an example, not meant as an argument. Suppose you have the two geometry tree's

        0	ALIC                 	ALIC
        	  |		     	  |
             +----+--- ....	          +----+--- ....
             |			          |
        1   FMD 		         FMD
             |			          |
             +-------+		          +-------+
             |       |		          |       |
        2   RNG     RNG 	         RNG     RNG 
             |       ...	          |       ...
             |       		          |
             +----------+	          |
             |          |	          |
        3   HRNG       HRNG	         SECT
             |           ...	          |
             |			          |
        4   MODU                         STRI 
             |
        5   SECT
             |
        6   STRI

In the left case, I need to get the 4th-level parent of STRI to know which RNG I'm in, while in the right case, I need to know the 2nd-level parent to know which RNG I'm in.

> Anyway, if the relative depth that you need is really a variable that
> you can identify only run time, any sort of iterators like this will
> give you a severe penalty in simulation time, so you better think of
> something else.

Of course you shouldn't search the hierarchy each and every time - that would be plain stupid. As the geometry will not change after it's closed, one can easily cache the values of the various levels in the user code, and use that cached value in the stepping.

Yours,

-- 
 ___  |  Christian Holm Christensen 
  |_| |  -------------------------------------------------------------
    | |  Address: Sankt Hansgade 23, 1. th.  Phone:  (+45) 35 35 96 91
     _|           DK-2200 Copenhagen N       Cell:   (+45) 24 61 85 91
    _|            Denmark                    Office: (+45) 353  25 404
 ____|   Email:   cholm_at_nbi.dk               Web:    www.nbi.dk/~cholm
 | |






text/x-c++src attachment: FindDepth.C__charset_ISO-8859-15