Re: TGeoManager node identifier questions

Hi Clark,

1. What do you call node ID ? The node copy number (or even pointer) are unique within a parent volume, not in the whole geometry (!!). Look at p.315 of the Users Guide related to "the volume hierarchy". Of course that if you have 2 copies of the same volume B placed in a container volume A they will be different (e.g. nodes B_1 and B_2), but if A itself is replicated in some other container, than A_1/B_1 pointing to a "B" object will not be the same object as A_2/B_1...

1-bis. If for ID you use: TGeoManager::GetCurrentNodeId() - don't do it anymore (or not like that): this is quasi-unique but only for a session. It is used for internal TGeoManager purposes and with TFluka interface in correlation with a special caching option: TGeoManager::CloseGeometry("di").
Using this will insure :

• unique node ID numbers reproductible between sessions (file or not) BUT NOT if your geometry will change in a future version (!!!)
• TGeoManager::CdNode(nodeID) will make the geometry state point to the node with the selected ID - This will add 2*Nnodes bytes in memory for ID caching (where Nnodes are the total number of different physical nodes) - so your geometry better be small... 2. I don't know why you need to store in your hit object a pointer to the TGeo node - you could store there a pointer to your detector element with maybe some additional indexes if these elements are replicated. It is a more general problem in doing that since the geometry is never "unfolded" in memory to store all different geometry elements as different objects (for calorimeters you can never do that - imagine 1e9 nodes...)

So, if your geometry is simple enough and WILL NOT change (!) you can stick with 1-bis (that I don't advice anyway), if not you should try to find an alternative solution... I can help you with more advice if you give me a bit more details on the usage of these ID's for your specific needs.

Regards,
Andrei

Clark McGrew wrote:
> Hello All,
>
> I'm using TGeoManager to handle the T2K near detector geometries, and
> I'm trying to chase down a problem being reported by collaboration
> members with the use of TGeoNode identifiers in our code.
>
> My questions:
>
> 1) Is it a safe assumption that a particular value of a node ID will
> always refer to the same TGeoNode in a geometry, even when the geometry
> has been written and re-read? [The geometry *shouldn't* be changing]
>
> 2) If it's not a save assumption that a node ID will uniquely specify a
> particular TGeoNode, what is the correct way to specify a particular
> volume?
>
> In my current code, I'm using the TGeoNode id's as an identifier for the
> volume element corresponding to a hit so that the class is generically
>
> class Hit {
> int fNodeId;
> float fTime;
> float fCharge;
> };
>
> The geometry for a specific set of events is then saved in the file with
> a tree of events. During analysis, the geometry is first read from an
> input file, and then re-saved in an output file. [This a temporary
> situation. Eventually I expect to save the geometries separately].
>
> I've been getting reports from collaboration members, that the TGeoNode
> associated with a node id is changing between files and as a result hits
> are being assigned to the wrong geometry element. I personally haven't
> been able to reproduce the problem, and before I spend a lot of time
> debugging my code, I would like to check ROOT's intended behavior.
>
> Thanks,
> Clark
Received on Mon Feb 26 2007 - 09:24:31 CET