Some thoughts about Clusters

TkrCluster/TkrClusterCol

These classes need some overhaul. (Johann as already started on this).

• At present, TkrClusterCol is not just a typedef of an ObjectVector of clusters^†, as are the other Cols, but contains arrays of index information of clusters by plane.
• Various non-standard access methods, which are driven by index, to access cluster info from clusterCol. These should be eliminated, or at least superseded.
• The objects in the vector are indices into the array of clusters, not pointers or smart refs/pointers.
• But we need to access clusters in other ways, by tower, for example, or by distance from a certain point, or by being in a ToT range, etc, or some combination of the above. So these index arrays are incomplete, besides being a structural anomaly.
• So, eliminate the arrays, make TkrClusterCol  a typedef of an ObjectVector of pointers, and generate the other info as needed, either locally or in the TDS.
  • Provide access to vector, iterators of the Col, and of course, all necessary access to individual clusters.
  • Who generates the other info? Probably a helper class or classes, which can be expanded as necessary. Or just local use of RelTable? Or local brute force looping over the clusters?

 

^† Note: ObjectVector<object> is really a vector of pointers to those objects. (Is this correct?)

 

What info to store with the cluster:

• Use VolumeIdentifier instead of  tower, layer, view
• First, last strip as before
• Position
• Flag, used in patrec (might want to know if cluster ends up on a track, does flag do this?)
• ToT info (see below)
   
• Some new info about bad strips:
  • Number of bad strips in cluster
  • Bad strips on edge/inside of cluster (bool)
  • Cluster is/isn’t at edge of ladder (bool)
  • etc.
     
• Remove m_id ("id" of cluster)

 

What about bad clusters?

Bad clusters are clusters made up entirely of bad strips.  These are made and discarded during cluster generation as a by-product of adding bad strips to hit strips to enlarge or merge clusters.

 

But we actually need these so that at pat-rec time we can check if there are bad clusters when we hit a plane where we expect a cluster but don’t find one. The idea would be to look for bad clusters within some number of sigma of the expected cluster, and possibly make sure that it satisfies any requirements on the width, etc.

 

• Store as a separate clusterCol associated with TkrBadStripsSvc
  • All methods of clusterCol will be available.
• Generate by calling TkrMakeClusters once whenever calibration is updated.
  • Requires modifying TkrMakeClusters
    • Call with no real digis
    • Store bad digis

 

Beginnings of a ToT analysis...

leading to an idea on how/where to store the ToT info

 

For some analyses, the raw ToT is sufficient… for example, Bill wants to know whether the cluster came with a saturated ToT.

 

The most info that can be stored for a cluster is the “mips” for each strip in the cluster, that is the ToT converted according to the calibration for each strip. This seems like overkill.

 

Because the strip with the maximum gain will most likely drive the ToT, the mip value for this strip is the most interesting…

• But in a multi-strip cluster, the edge strips are likely to have a lower energy deposit, because on average the particle will traverse only ½ of the strip. So maybe they should be excluded.
• And in the case of two-strip clusters, there’s no way of telling how the energy deposit splits between the two strips. So maybe the correct thing to do is to plot the mips as a function of the energy deposit split, and take the average.
  • But if you know the angle of the track, you can do better, since then you have a prediction of how many strips should be hit… for example, there are magic angles for which it’s pretty certain that the particle traversed all of the edge strips. So in the two-strip example, we average over only part of the mips distribution.
• btw, the mips value that you get from a multi-strip cluster is higher than you would expect, because it’s the highest of the strips, so the more strips in a cluster, the more the value will deviate from the expected mean. (This should be checked with MC.)

 

So the right time to do the conversion to mips is at patrec time, when the track angles are known. Then, we can apply subtleties like those above. Furthermore, at that point we have the path length of the track (actually quite a few subtleties here!), so we can convert to real mips:

 

            Real mips = “mips”/(track length in strip)

 

Also, obviously, this shouldn’t be done in AnalysisNtuple!

 

Topology of the ToT response

 

Another consideration is the number of clusters in the range covered by the ToT. 

• If there is only one, then we know that we’re analyzing the correct strip.
• If there are two, and the other one is a single strip, and it’s “far” from the strip in question, it’s likely to be a noise hit.
  • That means that its ToT will be very low, and can be ignored. (We should check to see how well this works in practice.)
• If there is a very wide cluster in the range, it is probably a delta, and could very likely have the high ToT. (Again, this should be checked!)
• What about the case of a two-track photon?  The hits are likely to be in the same range, they are close together, etc.  One hint would be if one of the tracks ends before the other.  If there is an abrupt change in the ToT after this point, we can assume that the previous ToT values belonged to the track which ended.
  • This analysis can only be done after the event configuration is understood.
  • For showers this will most likely be all muddled, because we get multiple track stubs and we can’t really tell what the “real” tracks are.

 

This tells me that we may want to analyze each hit on a track as if the ToT belonged to it, and then apply any extra information after pat-rec or fitting is completed. This means that the processed ToT info should be stored with the hit on track.

 

So what ToT info do we store with the cluster, and where do we store it?

Some of this could be in the cluster, or in another structure with a pointer to it in the cluster. The latter would allow us to develop the ToT info without changing the structure of the cluster itself. Some pieces of info are more properties of the range (example, number of clusters in range), and might be better stored in another type of structure altogether.

• Raw ToT
• Info characterizing the range, including the following (These can be calculated later, but it’s probably inconvenient to do so):
  • ToT range (0/1) (bool, all these can be stored with those above as bits in a word)
  • Strip is alone in range (bool)
  • One other cluster in range, single strip, far away  = noise? (bool)
  • One other cluster in range
  • Distance of closest other hit
  • More than one other cluster in range (bool)
  • “Wide” cluster in range (bool) or maybe width of widest other cluster in range
  • etc.
• “mip” of strip with the highest gain, for use when the cluster doesn’t fall on a track. Examples:
  • Noise studies: looking at isolated single-strip hits to count frequency, measure ToT spectrum, etc.
  • Looking for real particles among the hits not assigned to tracks
    • This might be useful for hit-counting in energy measurements
    • Although these will likely be in the same range as the real hit, muddying the analysis

 

ToT conversion formulae (for reference, so I don't lose them!)

 

To convert from energy deposit to Tot:

• Convert energy deposit to mips
• Convert mips to fC
  • fC = mips*mipsTofC(strip)
• Convert fC to ToT:
  • ToT = max ( threshold(strip) + gain(strip)*fC + quadratic(strip)*fC**2, 0)

 

To convert from ToT to mips

• To invert the quadratic formula
• Abs(quad/gain)>10-6: fC =
     (-gain + sqrt(gain – 4(quad)(threshold-ToT)))/(2*quad)
  else:  fC = -thresh/gain(1 +  (quad/gain)(thresh/gain))
• What to do about the muon calib, which gives the ToT for a muon in that channel? Should probably scale the fC, not the ToT