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.

Figure: 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.

2 Interactive JavaScript elements

For design reasons, and also in order to keep all input options easily accessible, the project submission form uses JavaScript and Dynamic HTML in combination together 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.

JavaScript is also used for an immediate verification of the values entered 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.

Figure: 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 the webbrowser using JavaScript code, the majority of input fields can only be 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 software¹. 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.