Gamma Ray Burst Followup Prototype Script.

Introduction.

This demo is intended to show how the protocols that have been developed
in this first year of the NVO project allow us to quickly gather and
organize information from many diverse sources and to use this data
within existing analysis environments. The role of the NVO is not to
replace existing tools and systems but to enhance their capabilities.

An astronomer often wishes to know everything that's available for a
given region of the sky. This can be particularly urgent if they are
responding to some transient event requiring rapid followup, e.g., a
gamma-ray burst. The tool we are showing collects information on a
region from many sources, organizes the data, summarizes what is
available to the user, and then allows the user to copy the data or to
immediately begin analyzing data in a variety of existing
viewer/analysis tools.

Alert Simulator (grbalert.html)

The home page for the demo lets the user look at the regions around
three recent bright gamma-ray bursts, or to enter any position they
like. There is also a link to the region around the Crab nebula, showing
how

the service could be used for positions generally. If the user chooses
an existing target go to the Event Viewer description below.

Users can enter data in either sexagesimal or decimal format. RA and Dec
should be separated by a comma or by the sign of declination. Fields
within the RA and Dec are separated by spaces.

The fields in the box below the coordinates are mostly for decoration.
However, the position error sets the size of the region that will be
looked at. The others just populate fields in a database to simulate a
real event alert. Click submit to initiate a cache retrieval.

Alerter (grbalerter.pl)

This page should return immediately indicating that caching of data has
begun, or give some, hopefully useful, error message. At this point a
set of processes has begun to collect data and cache the results on the
demo machine. The caching will take a while. You may want to click on
the link to the Transient Events Log to show all of the events that are
currently available. Or you can go directly to this event/position, by

clicking the Transient Event Data Viewer. In the later case, by
refreshing the screen you'll gradually see data being collected. It
takes \~3 minutes to get everything.

Transient Events Log (grbview.pl)

This page simply lists all of the events that are in the database and
their basic parameters. Note the difference between the epoch of the
event, and registration date/time. The position and size of each region
are the main fields of interest. To look at data for a particular
event/position, just click on the event id hyperlink.

Event viewer (viewevent.pl)

This is the central page of the demo. It summarizes all of the
information that has been collected about the region. A number of images
in various wavelengths should be displayed. There may be observations by
HST, ground observations (very rarely) or high-energy data. A large
number of object catalogs will be searched and at least a few should
show up. These will be separated according to the kind of objects with a
few major catalogs treated specially. At the bottom you'll get a list of
datasets that are in principal searched but have not yet returned
anything, or which have been searched and for which no data is
available. A few services may not have been searched because the region
was thought to be too large for the service.

There are a number of points to emphasize here: All of these data have
been collected using two standard protocols, the simple image access
protocol and the cone search protocol. Over a dozen different sites
around the world have been looked at. The data has been retrieved using
a the VOTable format so. The UCD's included in the VOTables enable us to
analyze the contents of the VOTables with confidence -- we'd be much
more leery about FITS tables without some specific standard.

You might want to click on the images to see the quick look GIF image.
Or you might try to click on one of the observation or object tables to
view the data retrieved. This will call a little program that renders
the VOTable nicely. At the top of this display there is a link to the
raw VOTable itself if the user is interested in seeing what real
VOTables look like.

Once the user has a sense of all of the data that has been collected,
point out a second major element addressed in this demo is access to
multiple data viewing/analysis resources. Since the data have been
collected in a standardized way, it is easy to convert them for input to
analyzers even if they have their own customized input formats.
Currently the two viewers we support (OASIS and Aladin) use custom
formats, but within a few weeks the VOTables that we have cached can be
sent directly to them. In the interim the

VOTables are being processed by a simple script to distinct ASCII table
formats for OASIS and Aladin ingest. Transforming from VOTables to other
formats is easy using the libraries that have been built in four
different languages for the VOTable parsing. This demo uses one built in
Perl by Eric Winter.

The user can choose one or more datasets by selecting the checkbox next
to each. Then the user can start up the analysis environment desired, or
can just create an archive tar file for download. This will include both
the VOTables for tables and FITS files for images. There is a checkbox
at the top of the

page that you can use to select or deselect everything.

# Using Aladin

The purpose of the demo is not to exhibit Aladin per se, but to show how
the data has quickly gotten into the analysis environment. Here are a
few pointers for Aladin:

-   Aladin gives readable names for each of the resources you feed it.
    Each image or table is put into a separate plane. If too many
    resources are specified Aladin will give error messages about the
    excess but otherwise work fine.

-   We are querying Aladin using a GET URL. If too many resources are
    included, the URL can get too long. There doesn't appear to be a
    standard maximum length, but the code now enforces a limit of 2K for
    the URL. This can silently truncate resources, but usually you'll
    run into the Aladin stack limit first anyway!

-   The demo sometimes returns catalog data at some distance from the
    images that define Aladin's FOV. If you click on these planes you
    may get a message indicating no overlap. If you use Aladin's zoom
    feature with shift pressed to unzoom, you will eventually get out
    far enough to find these objects. Also, if there is only a single
    element in a catalog Aladin may load it and give a red flag
    indicating a problem in loading even if there was none.

-   RGB images are often nice when several images with similar
    resolution are available (e.g., DSS of various colors and FIRST, or
    NVSS and WENSS data).

-   Aladin doesn't always choose the best colors for its overlays. It
    sometimes tries to plot white-on-white. Note that the color of the
    grid in the stack is the same as the color used in the plot. You can
    change these.

-   If you want to back out of Aladin, you may find yourself trapped.
    The initial Aladin page does a relocate to a second page, so just
    going back one page may just restart Aladin and sometimes seems to
    clog the browser. Make sure to jump back two pages.

-   Arnold has run into problems with the applet gradually shrinking. I
    haven't seen this (it sounds kind of spooky), but seems to be
    restricted to Netscape on Solaris machines.

For further information about Aladin look at http:/java/aladin.pdf (or
.ps if you prefer PostScript).

# Using OASIS

The purpose of the demo is not to exhibit OASIS per se, but to show how
the data has quickly gotten into the analysis environment. Here are a
few pointers for OASIS:

-   OASIS requires the Java 1.2 (or greater) plugin to be installed. If
    not then it will run the installation script which generally runs
    nicely, but Bruce has warned me that Solaris machines run into some
    bumps here. This needs to be done only once per machine.

-   OASIS will ask for certain privileges to run. You can specify how
    long you'd like the applet to have these privileges. I generally
    grant them on a per session basis, i.e., you'll get the message once
    per browser session.

-   When OASIS starts up, it displays the last image read buried
    underneath the catalogs you've sent to the session. You'll need to
    move the catalog windows out of the way to get to the image.
    Generally OASIS creates a lot of windows. Keeping track of them can
    be a problem. Unless you're familiar with OASIS I'd suggest sending
    no more than 4 or 5 resources until you're more comfortable with it.

-   By default OASIS displays all catalog overlays using the same
    symbol. You can either turn all but one off, or you can edit the
    catalog overlays and change the symbol and color.

-   The filenames used by OASIS to describe resources are local names
    and aren't very helpful. This may be fixed before the AAS.

For further information about OASIS look at
<http://irsa.ipac.caltech.edu/applications/Oasis>

FAQ (let me know what the real one's are. These are what came up at the
team meeting.)

*What does this do that SkyView\|NED\|OASIS\|Aladin\|... doesn't do
already?*

We already have many services that link to multiple archives or
catalogs. However currently these use heterogeneous and rather fragile
protocols. This demo illustrates what can be built quickly using
standard protocols. This demo also works to connect the datasets and
analysis environments in a new fashion. While one can 'dial-out' of,
say, OASIS to get some of these same datasets it would be tedious to do
so for all these varied resources. Nor does OASIS give me a simple
summary of the datasets that are (and are not available). This demo
shows how we can gather all of the data together so the user can quickly
understand what datat they have to work with. Then the user gets to
choose among several different analysis environments. This kind of
overview and flexibility of analysis is unprecedented.

*Can I use this for non-transient events?*

Sure. We're planning to develop this kind of service as a replacement to
Astrobrowse.

*Is this a throwaway demo?*

A lot of the underlying code is simple and will be replaced by more
sophisticated approaches. However we are using this effort not only as
an NVO prototype, but as the beginnings of an interface to help support
the GRB followups for the SWIFT mission.

*Couldn't you do this without the NVO?*

Sure, but it would have been vastly more work and much more fragile. It
would be a bear to maintain.

Adding in new services is trivial in the current environment. With the
NVO protocols something like this is not only possible, it's inevitable.

*How does the demo choose the services used?*

Well that's one area where we'd have like to use the NVO registry
services, but they aren't ready yet. Basically there are simple files
describing the cone search and simple image access services to call. For
each service there's a limit to the size of the region that a query will
be sent out for. E.g., we don't want to

query the GSC2 for regions greater than a fraction or a square degree or
so. Otherwise the files pretty much just have URL to be queried. For
catalogs of observations, we do characterize the size of the field

of view, so that we can look for observations that might overlap, not
just observations whose center is very close to the requested position.
In the future we hope that the service will look at registries of
available services and choose automatically.

Here are a couple of examples of lines from the control files used to
control the interface:

http://chart.stsci.edu/gscvo/DSS.jsp?FORMAT=image/fits\|stsci.sia\|0.5\|FITS\|GIF\|fits\|gif

dss\\s.\*red \| 0.5 \| dss_red.fits \| DSS (Red) \| Optical \| ST ScI

This is an example of how we call an SIA service. The first line
indicates the URL for the service, and

indicates how we translate from the FITS data to quicklook images. The
second line is used to parse the results of the SIA call, and find
images of interest. If they are found, it gives a name to store them as,
the label to use, and a category and provenance.

http://adil.ncsa.uiuc.edu/cgi-bin/vocone?survey=f\|0.3\|20\|adil.obs\|Ground\|NCSA(BIMA
Array)

This line indicates that the ADIL resource is to be queried at a given
location. The resource will not be queried for regions larger than 20
degrees, but 0.3 degrees will be added to the size requested to get data
that might overlap the region of interest. The category of the data is
'Ground' (under Observations) and the provenance is 'NCSA (BIMA Array)'.

The same files are used in the cache initiation and the Event resource
view.