For background, you should at least skim-read the paper Transient Astronomy with ACP Scheduler (PDF). For background, you should at least skim-read the paper Transient Astronomy with ACP Scheduler (PDF).
The receiving and observing request process can be customized in virtually limitless ways without new software updates from DC-3 Dreams. This allows you to adapt to changes in (and additions to) the events that are being sent over the VOEvent network as the net evolves. As delivered, the components that handle these processes can handle GRB alerts from the Swift and INTEGRAL satellites as well as Catalina Sky Survey transients. By customizing the event filter and RTML observing plan templates you can add capabilities and adjust the standard ones to suit your needs. If you haven't read the Introduction page for the VOEvent receiver, you should do so now.
Customizing the pre-patcher and filter requires not only knowledge of XML programming, but also familiarity with the schema and structure of VOEvent messages. It is beyond the scope of this document to provide this information. Information on XML programming is available from many places. The best place to start for learning about VOEvent messages is the IVOA document Sky Event Reporting Metadata (VOEvent).
For reference, here is a block diagram of the VOEvent Receiver showing the flow of incoming VOEvents and how they result in observing requests being submitted to the scheduler.
The three darker colored blocks represent the places where the receiver can be customized. In addition, test message generation can be customized, giving you a way to test your customizations. The next sections introduce each area of customization.
The pre-patcher is used to clean up illegal VOEvent RTML before it is submitted to the schema-conforming parser. The VOEvent receiver contains internal logic to correct for XML conformance problems known to exist at the time of the release of Scheduler 3.0. If additional problems are encountered, they must be cleaned up in the pre-patcher.
A pre-patcher script is supplied with the standard Scheduler release, however it does not do any patching. Instead, it simply saves copies of all incoming VOEvent messages on your local disk. This can be invaluable for troubleshooting and monitoring the VOEvent network.
For more information see Customizing the Pre-Patcher.
The point of entry into the scheduling system is the event filter. This is where incoming events (VOEvent XML messages) are tested for "interest", that is, whether you want them to result in observations being taken at your observatory. The filter can be a Windows Script as is the standard one supplied with Scheduler, or a full-up executable developed in any language you wish. The only requirement is that the program or script have access to its command line and to be able to read from "standard in" and write to "standard out". The filter program or script is configurable in the VOEvent Receiver's settings window.
If the filter decides that an incoming event is one that is interesting, it returns some information that the rest of the process uses to build the observing request submitted to the scheduler's database. One important aspect is the 3-letter code that represents an event type. This is what you use in the receiver's settings to control which event types will be turned into observations. You can add your own event type codes and corresponding observing templates.
Customizing the event filter requires programming skills. There is no way a point-and-click system could address the limitless future event types and content.
For more information, see Customizing the Event Filter.
One of the items returned by the event filter is the name of a template to use in constructing an observing request for following up the event. The scheduler's observing request input format is RTML, so the template is an RTML document. This specifies the images, filters, constraints, timing, etc. of the request. All of Scheduler's features are accessible through RTML, so you have total flexibility in designing an observing strategy for a particular type of event.
The event filter can generate a one-time template using the information in the VOEvent message. Thus, you can design the code in the filter to (for example) look at the magnitude of the event's object and adjust the number of images, filters, exposure times, binning, even timing of observations (create a time series). You can also specify the constraints that must be met for observing based on the info in the VOEvent. So you don't have to use an existing template, though this is easier if your observation needs are routine.
For more information, see Customizing Observing Strategies.
With the Generate Test Event menu on the receivers' window, you can cause VOEvents to be fed into the system as though they were received from the network. This is incredibly useful, especially when developing a custom event filter or custom observing template. Create a test event message that matches the one you're interested in and repeatedly send it into the system, causing the filter and observing template mechanisms to operate. Debug the filter, tweak the observing template, and keep going until you have exactly what you want.
The Generate Test Event menu has entries for the three standard event types (Swift GRB, INTEGRAL GRB, and Catalina transient), plus two "user" entries which you can use for your own custom event types. As shipped, the User 1 entry is linked to a very simple event and observing template that you can use to test your system/s functionality.
For more information, see Customizing Test Event Generation.