Next: 3 THE OBSERVING PROCESS
Up: Service observing management at the APEX telescope
Previous: 1 INTRODUCTION
2 PROJECT SUBMISSION
Observing time with APEX is granted by the time allocation committee (TAC) of the
corresponding partner institute, which is either the Max-Planck-Institut für
Radioastronomy, Onsala Space Observatory, the European Southern Observatory, or
the Chilean astronomical community. When a PI is informed about the allocation of
observing time for his/her project, he/she is asked to submit all relevant information
concerning the project through our project submission facility, which is
accessible on the APEX web pages after entering a valid user/password combination.
1 The PHP/HTML web form
The project submission form is a standard web page written in HTML and PHP, and is
accessible by any web browser (see Fig. 1).
Its usage therefore does not require any additional
software to be installed on the PI's computer.
The submission form contains three sections which have to be filled out by the
PI. The first section contains general project information: Proposal number, APEX
partner organization, PI name and email, etc. Besides these, also the information
about target sources should be submitted in this section, either by filling out
the provided fields, or by uploading an already prepared source catalog.
In addition, the selection of the receivers to be used for this project is part of
this first section.
The second section should provide receiver-dependant information, and can be filled
out for each receiver independently. The information which is to be provided here
contains observing modes, switch modes, pointing sources, or mosaic setup, and also
backend setup and spectral lines for heterodyne receivers. While the provided input
fields are sufficient for the majority of projects, there are always more
complicated observing programs that require different setups or observing modes
depending on the source or spectral line. Several comment fields are provided to
enable the submission of these projects as well.
A third section is provided to submit additional observing instructions, or for
general project information.
For design reasons, and also in order to keep all input options easily accessible,
with CSS style sheets. This allows to display only the necessary form elements.
Only one receiver is displayed at a time, but the user can switch easily between
the receivers. As visualized in Fig. 2, the form changes dynamically
depending on the user input, hereby hiding the input fields which are not
necessary for the current submission.
Two sections of the project submission web form used at APEX. In the upper section of
the form (left) the PI has to enter general information, while in one of the central section
(right) the form asks for receiver specific information.
by the PI in some input fields. Thus unreasonable input is detected before
the form content is submitted to the server, hereby saving network capacities
and server computing power.
Dynamic HTML in the project submission form. The upper part shows the target source section
for the online submission of 3 sources, while the lower part shows exactly the same part
of the form
for the upload of an already prepared source catalog.
3 Form readout and translation with Perl
The core of the submission process builds a Perl script submit_setup.pl,
which by now has grown to more than 6.000 lines of code. Still, under normal
conditions, a submission is processed within a few seconds.
The script reads the form, using standard Perl commands and modules, and performs
a series of tasks, which are described below.
- Input verification.
In contrast to the verification of individual input fields, which can be done in
verified after combination with other fields. An example is the proposal number, for
which the syntax differs depending on the APEX partner. If the user input has syntax
errors, or leads to impossible setup configurations or observing procedures, the
submission is rejected by the system. In this case, an error message will be sent
to the web browser, which allows the PI to correct the input.
- Input backup.
Before the script processes the input data, the content of all form fields is saved in
a simple text file, which is accessible by the APEX staff and is consulted in case the
input leads to ambiguous output files. This feature is mainly used for debugging.
- Source catalog.
The submission facility allows to enter the target source information in the form itself,
or to prepare a source catalog offline and to upload it. In both cases the input is
checked for syntax errors, and a properly formatted APEX source catalog is created.
- Line catalog.
The creation of a line catalog uses the information supplied in the line section
of every selected heterodyne receiver, or the information from all uploaded line catalogs.
This task is not necessary if only standard lines (i.e. those contained in the system
line catalogs) are to be observed, or for bolometer projects.
- Project summary.
This summary is written in HTML format and therefore readable with every webbrowser.
Since it is the main source of information for the observer, it is also linked from
the TWiki project page (see below and Section 4.1). It contains information
that includes the used receivers, backends, observing
modes, sources, and other details which are verified upon the start of the observations.
- Setup and observing macros.
For each receiver, the program creates a pair of macros. As the names imply, they contain the
information about system setup and observation commands, respectively. The location of
some setup details (e.g. the source to be loaded) depends on the type of the project
(heterodyne or bolometer).
- TWiki page.
Creation of a text file that contains the raw text of the TWiki project page
(see Section 4.1).
- PHP database input file.
Creation of a PHP script which is used to enter the project details into the
APEX observing database (see Section 4.2).
- Notification email.
The script prepares an email message which contains all created files, and sends it to the project PI,
the APEX astronomers, and the project scientist of the coresponding APEX partner.
- Submission acknowledgements.
As a last step, a reception acknowledgment is displayed by the webbrowser of the user,
indicating the success of the submission.
4 Associated programs
The Perl script submit_setup.pl calls additional programs for special
tasks. These tasks are not embedded in the Perl code. One reason is that these
task can be easily activated or de-activated for tests during phases of
development or improvement.
The first of these tasks is the creation of a project page on the APEX
TWiki. This is a collaboration platform for APEX staff and partners, using
the TWiki software1. This task is performed by a TCL script named
createProjectPage. TCL was chosen for this task because it allowed the re-use of
already existing software components working within the APEX TWiki.
The second task is the creation of a project account in the APEX Observing database,
and to fill the database fields with information about the project.
For this purpose the Perl program submit_setup.pl writes a PHP script,
which naturally interfaces with the observing database.
Michael Dumke, 19 May 2009. Article © SPIE