The interface for other transiens projects using the VLBA for rapid follow-up
This page describes some throughts about what kind of interface the VLBA should provide for the user community wanting to use rapid response. It is based on our experience (of a few days of thinking and implementing, and 0 tests yet) about the most easily implemented requirements for the observatory and the user community combined.
The requirements for the interface are as follows:
- The VLBA schedule (key file) should be created by the PI's software. VLBA ops shouldn't be responsible for generating the key file. Reasoning: there are too many different types of observation one would want to do depending on external (e.g. properties of the transient) and internal (e.g. status of the VLBA) factors. Even with the GRB follow-up experiment, we generate 2 different types of schedule depending on the number of antennas available. It's unreasonable to get the observatory to maintain such complex constraints.
- The key file(s) must be run through the version of SCHED running on the AOC computers at Socorro. Reasoning: SCHED changes fairly regularly and in step with a large number of VLBA systems. Getting PIs to maintain their own version of SCHED is too difficult and dangerous.
- The SCHED output and any other metadata should be distributed to the VLBA controllers within 10 seconds or so.
- The system should be flexible to the way the VLBA is operated. Reasoning: VLBA operations is changing rapidly. Building too-rigid systems will be harder to maintain. E.g. the GRB project creates 3 schedules per event, starting at t+0mins, t+10mins and t+20mins, to let the operator decide which to schedule depening on when they see the alert.
- It should be possible for the PI's software to obtain a (best guess) estimate of the status of the VLBA before generating a schedule. E.g. which antennas are available. Reasoning: the number of available antennas is a useful parameter in choosing 1. Whether to submit a trigger and 2. The composition of the schedule. E.g. in the GRB project, we create a different schedule based on the number of antennas for which the source is above the horizon. We currently have no status of the actual antenna availability.
Options for submitting schedules
- Email - PI maintains a daemon running in the AOC in Socorro. When the transient occurs, the daemon receives a message (by some means) creates the schedules, runs SCHED and sends an email to the operators. E.g. This is how the GRB project works. The daemon runs on login.aoc.nrao.edu and the messages come from the GCN via TCP socket.
- Web Service Daemon- PI Maintains a program offsite, VLBA operations matintains a web server running a web service (it could be as simple as an HTTP POST). When transient occurs, the PI's program creates the schedules and submits them via the web service, with some meta data. The web service runs SCHED on the supplied schedules, and notifies the VLBA operators.
- VOEvent Daemon - VLBA creates daemon that listens to a range of VO events. PI specifies which events to listen to and the constraints under which a particular event should trigger VLBA observations. VOEvent Daemon creates schedules based on PI-specified rules, runs SCHED and alerts operators. E.g. I know this option John Conway is persuing this option at the EVN- They have python scripts that take in rules files generated by PI's and sort and rank them etc. I think (but am not sure) that it's VOEvent based.
Pros and Cons
- Simple to implement
- Responsability of PI to maintain all of software (i.e. no requirement on NRAO to maintain anything)
- All other software (e.g. SMTP server, SCHED) is maintained by NRAO anyway
| - Evaluating, queing and tracking observations is a manual process, and burden on VLBA operations. Can probably handle a maximum of 1 event/few days
| Web Service
- Keeps more orderly track of which observations have been submitted
- Minimises number of user-contributed pieces of software running inside NRAO, mitigating e.g. security issues
- More complex to implement than Email
- Rigidly defines the interfaces. E.g. at what level do you specify 3 schedules with different start times? - In all likelihood, the interface will have to change as each new transient project will have different requirements
- Adds another piece of software for VLBA operations to maintain
|| - Probably most attractive to the user community (no software required by users) - just specify types of objects and constraints (e.g. luminosity)
- Very complex to implement (but is EVN version available for evaluating?)