Observations on observation

Message boards : Nebula : Observations on observation
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile David Anderson
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar

Send message
Joined: 13 Feb 99
Posts: 173
Credit: 502,653
RAC: 0
Message 2051372 - Posted: 8 Jun 2020, 2:22:43 UTC
Last modified: 8 Jun 2020, 2:25:45 UTC


Review: the ALFA receiver used by SETI@home has a cluster of seven small "beams" that sometimes move across the sky and sometimes "stare" for a while at a point on the celestial sphere. Over the 15+ years of recording data, these beams have looked at most of the sky visible from Arecibo. Some places have been observed once for a few seconds; others have been observed hundreds of times, for many hours total.

The question of how long we've observed a given spot of sky comes into play in several parts of Nebula. For example, the score of a multiplet (a candidate ET signal) includes a "time factor" that in essence measures: in the times we could have detected something here, how often did we actually detect something?

The notion of observation time seems straightforward, but it's not. When we examine it carefully, it turns out we've been doing things in a somewhat sloppy way. Eric and I have been figuring out how to clean this up.

There are two inherent approximations in how we do things. First, the idea that a beam "sees" a sky disc is inaccurate. The sensitivity of a beam is a distribution, roughly Gaussian shaped but with "side lobes" that extend far from the beam's center. In fact, for sufficiently powerful signals, a beam "sees" the entire visible sky.

In SETI@home we assume that ET signals will be fairly low power. So we assume - somewhat arbitrarily - that the source of a signal seen by a particular beam at time T is within an angle of H of the center of the beam at time T, where H is the half-power diameter of the beam sensitivity. We call this the "feasible disc" for the beam at time T. Dan pointed out that - if we had infinite time and computing resources - we could do separate back-end analyses for different ranges of ET signal power.

Second, our notion of "spot of sky" is approximate. We account observation time in terms of pixels. The resolution - the size of the pixels - is chosen to be somewhat finer than the half-power beam size. A beam's feasible disc could include only part of a pixel.

OK - back to observation. In fact, let's go back to the beginning: the data. Our data from Arecibo includes pointing information: the sky coordinates (RA and dec) of each beam center as a function of time. The time resolution of this info is fairly coarse: early data has "pointing records" about every 5 seconds, in later data it's every second.

The "workunits" analyzed by the SETI@home client consist of 107 seconds of data from a particular beam, together with the pointing information for the beam during that period. The client does FFTs of various durations and generates "detections". Each detection is assigned a sky position: the estimated position of the beam center at the midpoint of the FFT. This is computed by linearly interpolating between pointing records.

Reminder: if a detection is actually from a celestial signal, its sky position is not the location of that source; it's the location of the beam center at the time of the detection.

We find multiplets on a per-pixel basis. For each pixel, we collect the detections whose angle from the center of the pixel is less than H. This "detection disc" will typically include detections from the 8 adjacent pixels.

With that background, let's get back to our original goal: to calculate, for a given pixel, the set of time intervals during which the SETI@home client could feasibly have generated detections that lie in that pixel - or more accurately, that lie in that pixel's detection disc.

Here's what we were doing until now: for each beam, we stepped through its pointing records. For each pointing, we formed the group of pixels with centers within H of the pointing (usually a block of 9 pixels) and counted the time interval from that pointing to the next as an observation of each of these pixels.

This gave us a set of time intervals for each (pixel, beam) pair. For a given pixel we took the union of these intervals, and considered that as the time we observed that pixel.

A problem became apparent: the detection disc of some pixels contained detections whose times were outside (usually by just a little) the observing time of that pixel.

As a quick fix for this, I increased the radius used in the observing-time calculation from H to 1.5H. Each pointing interval was then being credited to block of up to 25 pixels.

It turned out there were two problems with this. First, detection discs still had detections outside the pixel's observing time. Second, we were granting time too liberally: a pixel's observing time now included intervals during which detections in its disc are not feasible.

The problem - we eventually figured out - is that during periods of telescope movement, consecutive pointing records can skip over pixels. This happens more when the time resolution is 5 seconds, but it can also happen with 1-second resolution when the beam is moving quickly. Because the SETI@home client interpolates between pointings as described above, it can generate detections whose positions are not when the pixel of any pointing, or even in the discs of H or 1.5H around any pointing.

With me so far? Now we come to the solution: be more precise in granting observing time to pixels. Let's say that consecutive pointings are in pixels P1 and P2, and that these pixels are non-adjacent: maybe they're 4 or 5 pixels apart. Instead of crediting the time interval to a block of pixels around P1 (or P2, or both) we should credit it (or rather parts of it) to the line of pixels between P1 and P2. This reflects what the SETI@home client does, in interpolating the position of detections.

How to do this? Prior to doing observation accounting, I added a step in which we "fill in the gaps" in the pointing data. For each beam, we go through its pointings in time order. For each consecutive pair of pointings X1 and X2, we interpolate their midpoint Y: namely, the halfway point assuming that motion in RA and dec is linear (the SETI@home client makes this assumption).

If the position of Y is in the same pixel as either X1 or X2, we move on to the next pair of pointings. Otherwise we add Y to the pointing history, and then recursively look at the midpoints of (X1, Y) and (Y, X2), possibly adding them as well.

After this interpolation process, there are no gaps in the pointing history: consecutive pointings are in adjacent pixels (not obvious but true). I changed the radius back to H, so as to not grant observation time to spurious pixels. And we're doing a more accurate job of accounting: if there's a 5-second gap between pointings, and the beam moves across 5 pixels, we're granting 1 second to each pixel along the line, rather than 5 seconds to the start pixel and its neighbors.

Also, I must say I'm proud of the above interpolation algorithm. As far as I recall it's the only direct use of recursion in Nebula (although, of course, the Healpix and R-Tree libraries do recursion galore).

I'm currently doing a Nebula pipeline run with these changes; it should be done and copied over in a couple of day.
ID: 2051372 · Report as offensive     Reply Quote
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 2051439 - Posted: 8 Jun 2020, 23:19:40 UTC - in response to Message 2051372.  


There are two inherent approximations in how we do things. First, the idea that a beam "sees" a sky disc is inaccurate. The sensitivity of a beam is a distribution, roughly Gaussian shaped but with "side lobes" that extend far from the beam's center. In fact, for sufficiently powerful signals, a beam "sees" the entire visible sky.

Not about Nebula stage but more regarding S@h client stage of processing: how this fact could affect on Gaussian types of detections? Should those side-lobes distort shape of this type of detection?
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 2051439 · Report as offensive     Reply Quote
Profile sunmines
Avatar

Send message
Joined: 12 Feb 02
Posts: 3
Credit: 605,435
RAC: 1
United States
Message 2051744 - Posted: 13 Jun 2020, 15:06:43 UTC - in response to Message 2051372.  

Thanks for the hard work.
ID: 2051744 · Report as offensive     Reply Quote
Profile ML1
Volunteer moderator
Volunteer tester

Send message
Joined: 25 Nov 01
Posts: 20147
Credit: 7,508,002
RAC: 20
United Kingdom
Message 2051749 - Posted: 13 Jun 2020, 15:46:30 UTC - in response to Message 2051439.  


There are two inherent approximations in how we do things. First, the idea that a beam "sees" a sky disc is inaccurate. The sensitivity of a beam is a distribution, roughly Gaussian shaped but with "side lobes" that extend far from the beam's center. In fact, for sufficiently powerful signals, a beam "sees" the entire visible sky.

Not about Nebula stage but more regarding S@h client stage of processing: how this fact could affect on Gaussian types of detections? Should those side-lobes distort shape of this type of detection?

Is this catching up with the change of receivers seen/enjoyed at Arecibo and also the further different receivers now seen at the telescopes/dishes that have been added into the mix, all since data collection first started over twenty years ago?...

Very good that Dr A and the team finally have some good research time to now be able to dive deeper into the detail!


Keep searchin'!
Martin
See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)
ID: 2051749 · Report as offensive     Reply Quote
Profile Jon Golding
Avatar

Send message
Joined: 20 Apr 00
Posts: 105
Credit: 841,861
RAC: 0
United Kingdom
Message 2051756 - Posted: 13 Jun 2020, 18:35:37 UTC - in response to Message 2051372.  

Is this new approach specific to Arecibo data, or is it sufficiently generic to work with data from other radio telescopes too (Green Bank and Parkes)?
ID: 2051756 · Report as offensive     Reply Quote
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 2052399 - Posted: 20 Jun 2020, 17:22:49 UTC - in response to Message 2051756.  

Is this new approach specific to Arecibo data, or is it sufficiently generic to work with data from other radio telescopes too (Green Bank and Parkes)?


In point interpolation part it's quite general. All data from receiver that point moving along the sky at time of recording will require it.
Regarding particular form of hardware function of receiver - it's particular to receiver but all of them have some imperfections (regarding simple circle) - the degree of influence on collected data is different though.
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 2052399 · Report as offensive     Reply Quote
Kirill
Volunteer tester

Send message
Joined: 20 May 10
Posts: 2
Credit: 24,032
RAC: 0
Russia
Message 2053231 - Posted: 6 Jul 2020, 10:42:55 UTC

I have error 403 at https://setiathome.berkeley.edu/nebula/index.php
ID: 2053231 · Report as offensive     Reply Quote

Message boards : Nebula : Observations on observation


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.