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