Woops!  I slipped a digit.  My first sentence should say:

... yes, there may be as many
as 100,000 alerts per night, hence more than 10^9 events for the
lifetime of the survey. 

- Kirk

----- Original Message -----
From: Kirk D Borne <[EMAIL PROTECTED]>
Date: Thursday, August 17, 2006 7:05 pm
Subject: Re: [LSST-data] Re: cpu for queries

> To reiterate other people's comments:  yes, there may be as many
> as 10,000 alerts per night, hence more than 10^8 events for the
> lifetime of the survey.   It makes sense that one alert
> corresponds to one object.  But one object may have many
> alerts (e.g., a new supernova may be "alerted" for ~100 nights
> in a row; or an asteroid may be "alerted" every time it is in
> the FOV).
> 
> It is imperative to have the objectid in the alert table.
> One can then join on the object table to get the corresponding
> object information.  But I don't see that the converse is 
> equally useful --> i.e., having the alertid (for *each* alert)
> in the object table.  However, I do like Ani's suggestion of 
> having the most recent alert's alertid in the object table.
> 
> - Kirk
> 
> ----- Original Message -----
> From: Ani Thakar <[EMAIL PROTECTED]>
> Date: Thursday, August 17, 2006 1:03 pm
> Subject: Re: [LSST-data] Re: cpu for queries
> 
> > 
> > i agree with maria that there doesnt need to be a separate table 
> > to map 
> > objectid<->alertid, but it may be useful/convenient to keep the 
> > first or 
> > last alertid for each object in the object table, so for example 
> > users 
> > can query on whether an object has ever had an alert or the last 
> > alert 
> > for an object.  if this is not a useful science question then 
> > alertid 
> > doesnt need to be in the object table, only objectid in the 
> alert 
> > table.
> >     ani
> > 
> > On Thu, 17 Aug 2006, Tim Axelrod wrote:
> > 
> > > Jacek,
> > > 
> > > I will look it up later (I am on a telecon), but my memory is 
> > that the 
> > > alert rate is about 100,000 per night, not 10!
> > > 
> > > An alert should apply only to a single object.
> > > 
> > > Tim
> > > 
> > > Jacek Becla wrote:
> > > 
> > > > Maria,
> > > >
> > > >> Can an alert correspond to more than one object?
> > > >>
> > > >> Probably not. Then you don't need a new table only and 
> > objectID in 
> > > >> the Alert table
> > > >
> > > >
> > > > That would work if the answer is 'no', especially given
> > > > that the Alert table will be compact. (Can someone remind
> > > > me how many alerts we expect per night? Assuming 10,
> > > > the Alert table will be growing 3,000 rows/year,
> > > > that is nothing.)
> > > > We should then keep the bit in the Object table
> > > > indicating whether there was an alert for given Object
> > > > (as Tim suggested)
> > > >
> > > > thanks,
> > > > Jacek
> > 
> > -- 
> > Aniruddha R. Thakar, Research Scientist
> > Center for Astrophysical Sciences, JHU, Bloomberg 375
> > 3701 San Martin Drive, Baltimore MD 21218-2695
> > 410-516-4850, Fax: 410-516-5096  
> > [EMAIL PROTECTED], http://www.sdss.jhu.edu/~thakar
> > -----------------------------------------------------------------
> --
> > ----
> > When I was a boy I was told that anybody could become President; 
> > I'm 
> > beginning to believe it. [Clarence Darrow]
> > 
> > _______________________________________________
> > LSST-data mailing list
> > [email protected]
> > http://www.lsstmail.org/mailman/listinfo/lsst-data
> > 
> 
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data

Reply via email to