While thinking about eliminating redundant multiplets across pixels (see the last blog entry) I realized that the way we find multiplets is "pixel-centric": it's more sensitive to ET signals whose sky position is near the center of a pixel. Details are below. Bottom line: I couldn't think of an easy way to address this, and it may not be worth addressing.

Introduction

The Arecibo beam has a half-power width (diameter) W of .05 deg.

The "reported position" P(S) of a signal S is the center of the beam at the time of S. Let Q(S) denote the "true position" of S (assuming that S is of celestial origin).

Nebula assumes that for most signals, angle(P(S), Q(S)) < W. In other words, the true position is usually in the disc centered at the reported position, with twice the diameter of the half-power disc. This is true for signals whose power is close to the noise floor.

This assumption means that signals S1 and S2 may have the same true position if and only if angle(P(S1), P(S2)) < 2W.

Nebula's multiplet-finding algorithm work on pixel-by-pixel basis. For each pixel we form a "signal disc" with radius W centered at the pixel center. This has the desirable property that if S1 and S2 are in the signal disc, angle(P(S1), P(S2)) < 2W, so S1 and S2 may have the same true position. Hence, for any multiplet we form from the signal disc, it's possible that all its signals have the same true position.

Because of this, the multiplet-finding algorithm doesn't need to take position into account when selecting signals to add to a multiplet; it doesn't give preference to closely-spaced signals. Position is a factor in multiplet scoring (variance in position reduces the score) but not in multiplet formation.

The problem with current scheme

The current scheme can't find some potential multiplets, because they're not contained in any signal disc.

Suppose the true position of an ET signal is the center of a pixel. Then, for any signal S that's the result of the ET signal, the reported position of S will lie in the pixel's signal disc. If the multiplet-finding algorithm works like it's supposed to, we'll group most or all of these signals into a multiplet.

However, suppose the true position is not at the center of a pixel; for example, suppose that it's at the corner of a pixel. The disc of radius W centered at this point will overlap 4 signal discs, but it won't be contained in any of them. The signals resulting from the ET signal may not be contained
in any of the 4 discs, so we won't find the best possible multiplet; at best we'll find 4 lower-scoring multiplets.

Possible solutions

In theory, we could do multiplet-finding separately for every signal S: form the signal disc of radius W centered at S, and look for multiplets in that. This isn't feasible; it would involve 10 billion signal discs instead of 16 million.

We could continue to use signal discs centered at pixel centers, but increase the radius enough to include everything within W of the pixel. This radius would be W plus the maximum half-diagonal of a pixel, which is about .025 degrees. There are two problems with this:

• It would slow things down by a factor of about 2 (the ratio of the bigger disc to the smaller disc area). Also, we'd be pulling signals from ~20 pixels instead of 9.
  
• The bigger discs could have signals farther apart than W, and which therefore don't have the same true position. We don't want multiplets with such signals. So we'd need an additional stop in multiplet-finding to prune signals that are too far apart. We could do this but I'm not sure how to combine it with the other forms of pruning we already do.
  

Or we could use some completely new approach, perhaps not involving pixels at all. Maybe do some kind of clustering based on both position and frequency. I like this general idea, but it would be a very large change; it will have to wait for Nebula 2.0.

Or we could keep doing what we're doing. Maybe the reduction in sensitivity away from pixel centers is minor. We can estimate this reduction using birdies. For now, this approach wins.

Ramifications for birdie position

When I wrote the code to generate birdies, I didn't realize that the multiplet-finding algorithm favored pixel centers. To generate a birdie position, I picked a random pixel and added a small RA and dec offset to the pixel center. The resulting position was biased toward pixel centers, causing erroneous sensitivity results.

I changed this to make birdie position uniformly random. To do this, I pick a random pixel, then compute an RA/dec rectangle that's large enough so that it always contains the pixel. Then I generate uniformly random points in that rectangle until I find one that's in the pixel.

I'd always assumed the pixel was the unitary unit, but now it seems WUs are compared according to their position within a pixel.
Is this perhaps an argument to have a smaller pixel size and then not worry about within-pixel differences?

---

Maybe a pixel should be broken down to a 100th or 1000th grid just to get more accuracy into the equation.

Cheers.