Debrief from recent ASTERICS meeting
John Swinbank
swinbank at transientskp.org
Tue Dec 8 02:16:08 CET 2015
> On 7 Dec 2015, at 19:18, Rob Seaman <seaman at lpl.arizona.edu> wrote:
>
> Please let us know if there are other related document repositories or forums online. It looks like WP5, CLEOPATRA = "Connecting Locations of ESFRI Observatories and Partners in Astronomy for Timing and Real-time Alerts”, also has responsibilities overlapping TDIG/VOEvent:
>
> https://www.asterics2020.eu/cleopatra.html
Indeed, your humble chair was briefly involved in early planning for CLEOPATRA before switching continents.
[..]
>> In particular the neutrino folk have set up a network of collaborators to share streams of VO Events (AMON : http://amon.gravity.psu.edu/) LOFAR, despite earlier stated intentions, seems not be generating a stream of alerts; they can receive and respond to alerts from others, but they do this "by email”.
>
> John can comment, but perhaps his relocating to the Garden State has something to do with that.
I’m a year out of date, so please don’t regard this as definitive. However, I think there are a few issues here:
* The low frequency radio sky has proved not to be so rich in transients as predictions ~a decade ago suggested it might be: LOFAR is now detecting transients (e.g. http://adsabs.harvard.edu/abs/2015arXiv151200014S) but at a very low rate.
* The calibration and imaging challenges presented by LOFAR were always going to be substantial, but have proved to require even more time & effort than expected to get right: although the pipeline for searching the image stream is quite advanced (http://adsabs.harvard.edu/abs/2015A%26C....11...25S plug plug), actually generating the images to be searched is a slow and laborious process.
* The current LOFAR system architecture isn’t appropriate for acting automatically in response to triggers. Work has been on going for some time to mitigate that, but I’m sufficiently out of the loop that I can’t usefully comment on progress.
> On the other hand, Four Pi Sky (http://4pisky.org) seemed to be going gangbusters at Hotwired. Is there feedback on projects that are using Comet?
I don’t make any effort to track statistics. 4 Pi Sky is certainly the most actively engaged of the users; I’d be curious to hear from others using it in anger.
>> These facilities are generally assuming that they are sharing events with other projects with whom they have MOAs, rather than public broadcasting, but some are considering a kind of mixed economy. There was some discussion about whether or not they needed brokers, whether streams could have auth/auth attached rather than just being hidden by obscurity.
>
> The word “broker” means different things to different people. Most basically it just means a node that either turns metadata into events and passes them on, or receives VOEvent messages and provides the metadata to a client application via some API, or perhaps receives event packets from multiple sources (an aggregator) or sends them to multiple destinations (fan-out) or throttles the stream(s) via some criteria (a filter).
>
> So yes, they need a broker to publish and a broker to subscribe and those brokers may also implement better security than simple obscurity.
This is a good summary. I’d be happy to speak to the interested parties — either directly or through this mailing list — about the extent to which Comet or other available tooling can meet their needs.
>> ==Radio alerts and response==
>> We encouraged the LOFAR rep attending (Roberto Pizzo) to begin some experiments in VOEvent creation/consumption. We stressed that even some simple experiments will help, because we need feedback if VOEVent and VTP don't suit them in some way; reporting experience with brokers such as COMET would also be useful.
>
> Again, please make sure that they understand that VOEvent and VTP are distinct issues.
I know Roberto well — I’ll drop him a line and see if there’s anything I can do to help out.
Cheers,
John
More information about the voevent
mailing list