ACD Recon update to handling gaps in the ACD

Improvements in handling gaps in the ACD

We greatly improved the way we handle gaps in the ACD with the new AcdRecon stuff.  Previously we had to rely on propagated intersections with the GEANT model, with no tolerance for near misses.  To find how close tracks came to gaps we:

1. Tried to see if a track hit any ribbons in the GEANT model, if it did we used that to calculate the gap, with the active distance defined as the ribbon active distance.  Otherwise,
2. Tried to see if a track hit any tiles in the GEANT model, if it did we used that to calculate the gap, with the active distance defined as the negative of the tile active distance.  Otherwise,
3. Used the idealized positions of the gaps in the sides. 

 Gaps are defined as the spaces between the tiles

Since the tiles are very efficient what we are really concerned with in the chance that a track missed all the tiles.  With the new pattern recognition we know all the tiles that a track comes close to.  Therefore we can use only the tiles.  This in nice because it puts everything on an equal footing.

The new algorithm work like this:

1. Once, during initialization, we caclulate the size of the gap associated with each edge of each tile in the ACD.  We express the gaps in the plane of the tile.  Because of the tilted side tiles we actually have to express the gap as a function of the length along the tile.
2. For each track we find all the tiles close to that track.
3. For each tile we loop over all the edges,  if the edge has a non-zero gap we calcualte the gap estimator.
4. For each tile we pick the edge with the highest gap estimator and make an AcdTkrGapPoca object
5. For each track we sort the AcdTkrGapPoca objects by their gap estimator values

 The size of the gap is important

Clearly, there is less chance to go in small gap that in a large gap.
Also, for tracks with large error bars, the distance to the gap expressed in sigma can be quite small.  This doesn't mean that there is a good change the track went into the gap however, as the distance to other edge of the gap is also small.  What we really care is the integral probablity the track went into the gap.

This is all handle in the piece of code below (the inputs x1, x2) are the sigma to the near and far edges of the gap.

float AcdTkrIntersectToolV2::sigmaEquivalent(float x1, float x2) {
  static const double root2 = sqrt(2);
  double erf1 = TMath::Erf(x1);
  double erf2 = TMath::Erf(x2);
  double delErf = fabs(erf1 - erf2);
  if ( delErf < 1e-9 ) {
    // Far away, just return the nearer edge
    return fabs(x1 * root2);
  } else if ( delErf > 1. ) {
    // At least 50. prob to be from inside gap,
    return 0.;
  }

  // Convert to the prob^2 that is inside the gap to sigma
  float sigmaSpan2 = -1. * log(delErf);

  // Check to see if we project inside the gap
  // (x1,x2) would be opposite signs
  if ( (x1 * x2) < 0 ) {
    return sqrt(sigmaSpan2);
  }

  // Not inside the gap, add sigmaSpan2 + x1*x1 (ie, in quadrature)
  sigmaSpan2 += (x1*x1);
  return sqrt(sigmaSpan2);
} 

 The orientation of the gap is important

Obviously, track coming in a large incident angles are less likely to squeeze through the gap.  This is why we do the calculations in the plane of the tile.  We could also add an extra term to the estimator to de-favor tracks a larger incident angles.