Asymmetry in CPM RoI eta-phi maps

E-mail from Alan Watson 24 Nov 2008:

It's a consequence of a small but necessary asymmetry in the EM/Tau algorithm.

One condition is that the central 2x2 "core" of the window must be an ET maximum. However, since a narrow ET deposit (e.g. a single tower) can produce identical 2x2 ET value in multiple windows, we can't just require that the core cluster is > all (overlapping) neighbours, or else the best EM candidates would always be rejected! Hence we require that it is > neighbours along 2 sides, and >= neighbours along the opposite sides. In effect, this says "when you have 2 or more identical core clusters, take the top-right one of the group". Since neighbouring clusters may be being evaluated in different modules or crates, the chips cannot compare results, and so we need a convention which is consistent between all chips in order to resolve ambiguous situations such as this.

The fact that we always choose the right-most RoI in these circumstances is what produces the differences at the two ends. Imagine we have ET in the last unmasked tower in eta:

  eta:    -2.7  -2.5  -2.4  -2.3  -2.2
  TT ET:    |  0  |  X  |  0  |  0  |

- here we have 2 identical 2x2 clusters, one spanning -2.7 -> -2.4, and
  one spanning -2.5 -> -2.3.
- we require that core ET > neighbours to right, >= neighbours to left
  Thus the cluster spanning -2.5 -> -2.3 is selected, producing an RoI
  at eta=-2.4 (RoI coordinate = centre of RoI).
- Since the tower -2.7 -> -2.5 is masked out, the -2.7 -> -2.4 RoI can
  never be more energetic than the -2.5 -> -2.3 one, and so will never be
  accepted. Hence in practice the last RoI is the one at -2.4.

  eta:     2.2   2.3   2.4   2.5   2.7
  TT ET:    |  0  |  0  |  X  |  0  |

- again we have 2 identical 2x2 clusters, one spanning 2.3 -> 2.5, and
  one spanning 2.4 -> -2.7.
- we require that core ET > neighbours to right, >= neighbours to left.
  So again the right-most of the two is selected, but in this case
  that is the RoI spanning 2.4-2.7, which is reported as having eta=2.5.

There is no way of avoiding this while still keeping the algorithm uniform in all CPMs (if the RoI condition was that a single tower was an ET maximum it would be more uniform, but that only works with a 3x3 or 5x5 tower window, not a 4x4 tower one).

Asymmetry in JEM RoI eta-phi maps

E-mail from Alan Watson 26 Aug 2010:

We may have a continuous jet algorithm, but we apply different thresholds to "forward" jets and count them separately. So how then do we define a forward jet?

The RoI coordinate is defined by requiring that a 2x2 jet element cluster is an ET maximum (i.e. the "4x4 jet" cluster). So this leads naturally to defining a forward jet as being one where this ET max cluster includes the FCAL (the logic being that if the edge of a 6x6 or 8x8 jet overlaps the FCAL but the ET max cluster does not then we should count this as a central jet). However, because of the way the modularity of the JEMS works there are 2 possible locations at the +ive eta end which meet this criterion, but only 1 at the -ive eta end.

  -ive eta:

          -4.9             -3.2    -2.9
            -------------------------
        |                |      |
        -------------------------

  +ive eta

           2.9    3.2              4.9
            -------------------------
            |      |                |
            -------------------------

                  3.2              4.9
                   ------------------
                   |                |    // only selected if zero ET
                   ------------------    // between 2.9 - 3.2

(There is no location at the -ive eta end corresponding to the farthest forward at +ive eta, and if there were the asymmetry in the RoI algorithm would mean that it would never be selected anyway - in fact the sign of the asymmetry was chosen so that this non-existent location could never be identified as the RoI position).

There are some cases where it's useful to know which RoI was selected, but only for internal monitoring/debugging. For other users, such as L2, all that the coordinate tells you is "it's a forward jet" - they need to look at the whole FCAL plus the end of the endcap anyway, and so distinguishing in the eta coordinate wasn't actually helpful. It did however cause confusion on a fairly regular basis, so in the end we suppressed this in decoding the RoI word and just return a single "forward jet" eta coordinate at both ends. But for those cases where we do want to distinguish, the JEPRoIDecoder (in TrigT1Interfaces), which decodes the RoI word, can return a "hardware style coordinate" (crate, module, row, column) which can be used to distinguish between the two locations.