Home » Analysis and Reconstruction » Reconstruction » Neighbourfinding at large angles
Neighbourfinding at large angles [message #1311] 
Mon, 26 November 2007 10:36 
mcharles Messages: 7 Registered: October 2005 Location: SLAC 



Hello,
One routine that's used quite a lot in calorimeter clustering is getNeighbourIDs(). For example, the nearestneighbour clustering routine in org.lcsim.recon.cluster.nn.NearestNeighborCluster uses a snippet like:
Quote:  IDDecoder decoder = hit.getIDDecoder();
CalorimeterHit c = hits.get(i);
decoder.setID(c.getCellID());
long[] neighbors = decoder.getNeighbourIDs(dLayer, dU, dV);

For a nonprojective detector the neighbourfinding across layers is tricky. Guilherme implemented these routines in org.lcsim.geometry.segmentation a while back and the code works pretty nicely. There's one case where I'm not quite sure what the right thing to do is, though. (Maybe Guilherme has thought this through already and can explain it?)
Right now, finding neighbours in layer m given a hit in layer n in the barrel looks roughly like this:
1) Find theta, phi of original hit in layer n
2) Get the radius r_m of layer m
3) Compute the point in 3D with (r_m, theta, phi), i.e. project from layer n to layer m.
4) Find the hit containing that point.
5) Find that hit's grid neighbours in layer m.
I was looking at a case of a shower in the HCAL with cos(theta)>>0 and was initially confused when I saw hits that were not flagged as neighbours despite being close (e.g. 3D separation 30mm) even though there were neighbours with larger 3D separations (e.g. 40mm). But after thinking about step 3 a bit more, I realized this was working as intended: the hits were spatially close but not so close in (theta, phi).
I'm not actually sure what the ideal thing to do here is. The projective approach is simple and works well in a lot of cases (most primaries _are_ more or less projective), and the places where it's nonintuitive are usually when clustering very tightly (e.g. 1,1,1). On the other hand, secondaries lose a lot of the initial direction, so projective clustering isn't really the best for them  I can see this biting from time to time.
Any thoughts?
Mat.



Re: Neighbourfinding at large angles [message #1312 is a reply to message #1311] 
Mon, 26 November 2007 12:30 
lima Messages: 47 Registered: May 2004 Location: DeKalb, IL, USA 



Hi Mat,
Thanks for looking into alternatives to improve the efficiency of neighborfindingbased clustering. The logic for nonprojective (NP) neighborfinding is based on the assumption that highenergy clusters point to the origin, which as you pointed out, is not true for some cases (like loopers). Note that this behavior mimics the original (projective) neighborfinding implementation.
A possible extension which could be useful would be a new method allowing the user to provide (theta,phi) for reference, rather than assuming the origin as reference. This is easy to implement for NP geometries, as most of the infrastructure is already there. However, an equivalent method (with same interface) should also be made available for the projective segmentations as well  Tony/Norman may want to comment on that.
Moreover, the clustering algorithm will have to provide the theta,phi reference as input to neighborfinding method, and this requires new clusterers (preferable) or changes to the existing clusterers.
Other alternatives could, for instance, be based on the cluster energy and/or position and/or shape + direction w.r.t. the origin. Then the neighborhood window could be expanded, say from (1,1,1) to (1,3,3) or more. Again, this should be managed by the clustering algorithm, not the neighborfinding method.
What do you think?
Guilherme



Goto Forum:
[ ]
Current Time: Sat Feb 22 02:22:57 Pacific Standard Time 2020
