Re: gGeoManager->GetCurrentNodeId()

From: Mark Messier <messier_at_indiana.edu>
Date: Mon, 23 Jul 2007 14:13:15 -0400


Hi Andrei,

Thanks for this (quick!) clarification. Its very useful to know the limitations of the unique ID's. I've already started implementing the second suggestion you make and its encouraging to know that there's not some better way out there.

Cheers,
Mark


Mark Messier                                         messier_at_indiana.edu
Department of Physics            http://www.physics.indiana.edu/~messier
Indiana University                                 Phone: (812) 855-0236
Bloomington, IN 47405                                Fax: (812) 855-0440



On Jul 23, 2007, at 2:08 PM, Andrei Gheata wrote:

> Hi Mark,
>
> As you have noticed, the method will not give you really unique
> id's - in normal case it is used as a backup method to check if the
> current tracking location have changed or not. There are few ways
> to do what you want. First is to call CloseGeometry("di") that will
> enable really unique node id's. You should be aware that this needs
> to allocate space in memory as 2*Nnodes words where Nnodes is the
> total number of nodes reported by CloseGeometry(). In this case you
> can get the unique id using GetCurrentNodeId() but also make a
> given id current: gGeoManager->CdNode(id) to get its matrix or
> whatever. I wouldn't do this however for calorimeters...
> The second method is to account at transportation time the current
> node and copy number (e.g. pad # or read out channel) and parents
> in the current branch (gGeoManager->GetParent(i)) (e.g. layer/
> sector/module). The information can be retrieved fast this way, no
> need to store unique numbers for each channel in different modules...
>
> Best,
> Andrei
>
> Mark Messier wrote:
>> Hi All,
>> I'm working with a geometry and need to assign unique read out
>> channel numbers to the lowest level nodes in my geometry. I
>> thought I could use the "gGeoManager->GetCurrentNodeId()" to map
>> each detector cell uniquely to an integer, but when I do that, I
>> discover that my geometry has duplicate ID numbers (that is,
>> TGeoNodes located along different paths that return the same ID
>> number). Perhaps I am misinterpreting what is meant my the NodeId's?
>> Looking at the code that assigns NodeId's it seems to me that
>> duplicate ID's are expected:
>> Int_t TGeoNodeCache::GetNodeId() const
>> {
>> // Get unique node id.
>> Long_t id=0;
>> for (Int_t level=0;level<fLevel+1; level++)
>> id += (Long_t)fNodeBranch[level];
>> return (Int_t)id;
>> }
>> This sum which defines id's has an obvious degeneracy when
>> fNodeBranch[0,1] = 1,2 and fNodeBranch[0,1] = 2,1. That's
>> oversimplified, of course, since the fNodeBranch[]'s are pointers,
>> but other such degeneracies must exist.
>> Any tips on how to efficiently map a geometry path to a single ID
>> number?
>> Thanks,
>> Mark
>> =====================================================================
>> ===
>> Mark Messier
>> messier_at_indiana.edu
>> Department of Physics http://www.physics.indiana.edu/
>> ~messier
>> Indiana University Phone: (812)
>> 855-0236
>> Bloomington, IN 47405 Fax: (812)
>> 855-0440
Received on Mon Jul 23 2007 - 20:13:24 CEST

This archive was generated by hypermail 2.2.0 : Tue Jul 24 2007 - 23:50:02 CEST