Linear Collider Forum

Home » Analysis and Reconstruction » Reconstruction » Neighbour-finding at large angles
Neighbour-finding at large angles [message #1311] Mon, 26 November 2007 10:36 Go to next message
Messages: 7
Registered: October 2005
Location: SLAC

One routine that's used quite a lot in calorimeter clustering is getNeighbourIDs(). For example, the nearest-neighbour clustering routine in org.lcsim.recon.cluster.nn.NearestNeighborCluster uses a snippet like:


IDDecoder decoder = hit.getIDDecoder();
CalorimeterHit c = hits.get(i);
long[] neighbors = decoder.getNeighbourIDs(dLayer, dU, dV);

For a non-projective detector the neighbour-finding 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 non-intuitive 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?

Re: Neighbour-finding at large angles [message #1312 is a reply to message #1311] Mon, 26 November 2007 12:30 Go to previous message
Messages: 47
Registered: May 2004
Location: DeKalb, IL, USA
Hi Mat,

Thanks for looking into alternatives to improve the efficiency of neighbor-finding-based clustering. The logic for non-projective (NP) neighbor-finding is based on the assumption that high-energy 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) neighbor-finding 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 neighbor-finding 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 neighbor-finding method.

What do you think?

Previous Topic:How can I get helix parameters from some track hits?
Next Topic:reconstruction particles
Goto Forum:

[ PDF ]

Current Time: Sat Feb 22 02:22:57 Pacific Standard Time 2020
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.1.
Copyright ©2001-2010 FUDforum Bulletin Board Software