Re: SETI like tass project

[Chris Albertson <chrisalbertson90278@yahoo.com>]

Even a 1000 point FFT is fast to compute compared to the
time to transmit the 1000 points in both directions.

Search problems typically take CPU time.  Here is one:
Let's say you have a few thousand observation records of the
form (ra, dec, mag) and they are all very close in ra,dec.
you want to know if you are seeing one object or N unresolved
objects.  Maybe they are at the limit and resolve some nights
and not others or maybe in one color but not in the other
color.  Doing this right could be a very large search space.

What you'd do is have all the observations in a database and
the SETI-Like clients would querry the database for a few
square minutes of data, work on the data.  The client would
divide up all the observations into stacks for object "A",
"B", "C" and "A+B blended", "C+B blend" and so on using total
flux and color index.  It's not an easy problem and you need
to keep re-computing as you add more observations.

A realated problem we found with the Mk III was that the database
tends to fill up with "noise" stuff that was detected once and
never again.  Someone or some system need to contiouly look for
objects seen only once in areas of the sky that were imaged
multiple times.  This isn't a SETI problem in of itself because
the DBMS can turn this up directly but someone has to figure out
if these "seen once" events are real.  We know that they are
common but a very few may be real.


--- Doug Welch <welch@physics.mcmaster.ca> wrote:
> 
> I fully agree with Dirk's assessment. A time-series analysis
> for many hundreds or thousands of points per object to high
> frequencies can be quite CPU-consuming. Obviously, the sampling
> needs to be appropriate to the task.
> 
> Cheers,
> Doug
> 
> On Tue, 29 Jan 2002, Dirk Terrell wrote:
> 
> > On Tue, 29 Jan 2002 16:02:52 -0600, Tom Droege wrote:
> > 
> > >Let's discuss how we might do this.
> > 
> > I have a bit of experience in this area. I do the OS/2 port of the
> S@H
> > client and I have written a distributed computing client/server
> project
> > called SwiftPC that does solar system dynamics calculations.
> > 
> > The TASS data situation is probably quite a bit different from S@H
> or
> > SwiftPC in that the CPU need per megabyte of data is much lower.
> That
> > is, we are probably bandwidth limited rather than CPU limited with
> this
> > problem. The time required to download data will be larger than the
> > processing time. That's not the kind of problem that lends itself
> to
> > distributed computing. The way to tackle this problem is, as you
> > suggest, to have a few machines chew through it. In the long run, I
> > think you want to process the data as they are taken, eliminating
> the
> > need to do a huge amount all at once. Now, where it might get
> > interesting is if you have a bunch of (date,magnitude) pairs for
> huge
> > numbers of objects and you want to do a variability analysis. That
> > might be more appropriate for a distributed computing project.
> > 
> > Dirk
> > 
> > 
> > 
> 
> ==============================================================
>  Douglas L Welch     | Office/voicemail (905) 525-9140 x23186  
>  Physics & Astronomy | FAX              (905) 546-1252 
>  McMaster University | 
>  Hamilton, Ontario   | 
>  Canada L8S 4M1      | E-mail       welch@physics.mcmaster.ca
> ==============================================================
> 
> 


=====
Chris Albertson 
  Home:   310-376-1029  chrisalbertson90278@yahoo.com
  Cell:   310-990-7550
  Office: 310-336-5189  Christopher.J.Albertson@aero.org

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com