enveloping, batching, signing

Rob Seaman seaman at noao.edu
Mon Feb 4 11:33:39 PST 2008


On Feb 4, 2008, at 12:12 PM, Kirk Borne wrote:

> 1)  The science requirements document for LSST requires that all
> events be identified and published to the world (VOEventNet) within
> 60 seconds of the end of each pair of exposures.

Right.  As Kirk goes on to say, however, this is only a limited  
definition of an "event".

> So, the events will *not* be saved up as a "night's worth of events".

I have to believe that there will also be various daily digests  
published by various community brokers.

> 2)  The Pan-STARRS project will find nearly all asteroids in advance
> of LSST, by several years.

Um - surely the two projects will sample differing cuts through phase  
space.  If LSST goes even a little bit deeper, the dim end of the  
distribution function could dominate.  The assumption is also that Pan- 
STARRS will solve all orbits.  If not, the recovery of previously  
observed objects will be a large part of the load.

> Therefore, LSST will "know" about these
> asteroids and their orbits (likely tracks & positions within the  
> images).
> In these cases, since these are known objects, they are not *events"
> in the usual "telegram alert" sense.

Overthrowing the "usual telegram alert" paradigm is precisely what  
VOEvent is about.

> Hence, LSST will *not* be sending
> alerts to the VOEventNet for known objects (asteroids, variable stars,
> quasars, blazars, ...).

The idea is to permit subscriptions tailored to the needs of different  
investigators.  It may well be that we will determine scientifically  
key use cases involving rapidly refreshing light curves/orbital  
glimpses of known variable/moving objects.  VOEvent would be an  
appropriate way to convey this information.

> So, I think that things will not be quite as extreme as you might  
> imagine
> coming out of the LSST pipeline ... e.g., maybe "only" 10-100 VOEvent
> messages every 60 seconds, and perhaps significantly less.

We should scale our infrastructure for the extreme cases, not  
anticipated typical values.  In any event, sharing the workload from  
the point of discovery will minimize the latency no matter the diurnal  
publication rates.  Technologies, including signing, should be  
designed to scale with the number of events independently of whether  
they are batched.

- Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20080204/c262f8d9/attachment-0001.html>


More information about the voevent mailing list