Doc. 9.5, Ver. 1.0 | March 2022

ALMA Observing Tool User Manual
Andy Biggs, Rein H. Warmels

ALMA, an international astronomy facility, is a partnership of ESO (representing its member states), NSF (USA)and NINS (Japan), together with NRC (Canada), MOST and ASIAA (Taiwan), and KASI (Republic of Korea), in
cooperation with the Republic of Chile. The Joint ALMA Observatory is operated by ESO, AUI/NRAO and NAOJ.

For further information or to comment on thisdocument, please contact your regional Helpdesk through the ALMA User
Portal at www.almascience.org. Helpdesk tickets will be directed to the appropriate ALMA Regional Centre at ESO,NAOJ or NRAO.

Version

Date

Editors

0.5, Ver. 1.0
0.5, Ver. 1.1
1.5, Ver. 1.0
1.5, Ver. 1.1
1.5, Ver. 1.2
1.5, Ver. 1.3
2.5, Ver. 1.0
3.5, Ver. 1.0
4.5, Ver. 1.0
4.5, Ver. 2.0
5.5, Ver. 1.0
5.5, Ver. 2.0
6.5, Ver. 1.0
7.5, Ver. 1.0
7.5, Ver. 2.0
8.5, Ver. 1.0
8.5, Ver. 1.1
8.5, Ver. 1.2
9.5, Ver. 1.0

March 2011
August 2011
May 2012
October 2012
February 2013
February 2013
October 2013
March 2015
March 2016
May 2016
March 2017
June 2017
March 2018
February 2019
June 2019
January 2020
March 2020
March 2021
March 2022

Rein Warmels
Rein Warmels
Rein Warmels
Andy Biggs
Andy Biggs
Andy Biggs
Andy Biggs
Andy Biggs
Andy Biggs
Andy Biggs
Andy Biggs
Andy Biggs
Andy Biggs
Andy Biggs
Andy Biggs
Andy Biggs
Andy Biggs
Andy Biggs
Andy Biggs

The ALMA OT Team, and the many Testers.
In publications, please refer to this document as:
ALMA Observing Tool User Manual, ALMA Doc. 9.5, Version 1.0

Contents
1 Introduction
1.1 How to Use this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 User Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Release Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Credits and Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5
5
6
6
6

2 Install and Run the Observing Tool
2.1 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3 Disk Space and Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.4 Mac Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Using the OT Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Mac Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Linux Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Windows Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Tarball Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Starting the OT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Connecting Through a Proxy Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7
7
7
8
8
8
8
8
8
9
9
9
10
10

3 Basic Concepts
3.1 Phase-1 Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 DDT Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 ACA Supplemental Call Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Stand-alone ACA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Phase-2 Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 Science Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7 Observing Unit Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8 Scheduling Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9 Project Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10 Project Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11 AOT files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.12 Project Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11
11
11
12
12
12
12
13
13
14
14
15
15

4 Overview of the Observing Tool
4.1 Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 The OT Main Graphical Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 GUI Parameter Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 GUI Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 Menu and Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.4 The OT Panes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.4.1 The Project Structure Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.4.2 The Editors Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17
17
17
17
18
19
19
19
20

1

4.2.4.3 The Feedback Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.4.4 The Overview Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OT Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21
21
21

5 Phase 1 – Observing Proposal
5.1 Open a Phase-1 Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 The Proposal Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Adding Investigators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2 Reviewer Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3 Scientific Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.4 Management Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.5 Duplicate Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Adding Phase-1 Science Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2 Field Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2.1 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2.2 Source clustering/Psuedo-Science Goals . . . . . . . . . . . . . . . . . . . . . . .
5.3.2.3 Resolving source information . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2.4 Expected Source Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2.5 Field definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2.6 Solar total-power observing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2.7 Import/Export of Source Information . . . . . . . . . . . . . . . . . . . . . . . .
5.3.3 Spectral Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.3.1 Spectral Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.3.2 Recovering image sidebands at Bands 9 and 10 (90-Degree Walsh Switching) . .
5.3.3.3 Polarization Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.3.4 Spectral-window placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.3.5 Spectral Line – one spectral window per baseband . . . . . . . . . . . . . . . . .
5.3.3.6 Spectral Line – more than one spectral window per baseband . . . . . . . . . . .
5.3.3.7 Spectral Line – VLBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.3.8 Representative Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.3.9 Single Continuum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.3.10 Spectral Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.3.11 Multiple velocities and tuning solutions . . . . . . . . . . . . . . . . . . . . . . .
5.3.3.12 Rest Frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.4 Calibration Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.4.1 User-defined calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.4.2 Astrometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.5 Control and Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.5.1 Imaging considerations: arrays and configurations . . . . . . . . . . . . . . . . .
5.3.5.2 Sensitivity considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.5.3 Time Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.5.4 Differential Gain Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.5.5 Solar and VLBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.5.6 Overriding the OT’s time estimate . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.5.7 Simultaneous observing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.5.8 Time-constrained observing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.6 Technical Justification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Summary Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Proposal Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6 Proposal Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23
23
24
24
25
25
25
26
26
26
26
26
27
27
28
28
29
29
30
30
30
31
31
32
32
33
33
34
34
35
35
36
36
36
36
37
38
38
40
40
41
41
41
41
42
43
43

4.3

2

6 Phase 2 – Observing Program
6.1 Generation from Science Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 Phase-2 Science Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2 Scheduling Block Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Observing Program Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Observing Unit Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.2 Scheduling Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.3 Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.4 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.4.1 Field Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.4.2 Instrument Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.4.3 Observing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.5 Observing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45
45
45
45
46
46
46
46
48
48
49
51
52

7 Tools
7.1 The ALMA Template Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Sensitivity Calculator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Spectral Line Picker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4 Archive Search Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5 Calibrator Selection Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6 LO Configuration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55
55
55
56
58
58
59

8 The Visual Spatial Editor
8.1 Overview of the Graphical Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Creating a Field Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.1 Single Pointings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.2 Rectangular Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.3 Offset Versus Absolute Coordinates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61
61
62
63
63
64

9 The Visual Spectral Editor
9.1 Overview of the Graphical Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 Viewing a Spectral Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.1 Science Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.2 Scheduling Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65
65
66
66
67

A Create an External Ephemeris
A.1 NASA resources for HORIZONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Instructions and Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Example Ephemeris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69
69
69
70

B Acronym List

75

3

This page was intentionally left almost blank4

Chapter 1

Introduction
The OT User Manual describes the ALMA Observing Tool (OT) that is used to prepare observing proposals(Phase 1) and to schedule approved observations (Phase 2) for the Atacama Large Millimeter/submillimeter
Array (ALMA). The OT is a Java-based application consisting of a set of user interfaces that are needed toprepare an ALMA observing project. This consists of a valid observing proposal and/or an observing program
containing one or more Scheduling Blocks that are executed at the telescope.

1.1

How to Use this ManualFirstly, it is important to explain what this manual is not.
• It is not a step-by-step guide to creating an ALMA proposal and/or observing program. Especially for
inexperienced users, such a step-by-step guide to proposal creation is available in the form of the OT Quick
Start Guide, which can be obtained either through the OT’s internal help system or through the ALMA
Science Portal. Observing programs are not intended to be created by normal users and therefore a Phase-2
counterpart to this does not exist.
• This manual is also not designed to describe everything that can be possibly be done with the OT, andin particular does not give an explanation of what each and every entry field in the OT does. If this is
desired, then the OT Reference Manual should be consulted.
• Detailed technical information about ALMA is also not provided although, particularly with regard to thetuning and correlator setups, the basics are covered. The ALMA Technical Handbook is highly recommended for those users who want to know, well, everything.
• Finally, this manual does not cover advanced use by the ALMA commissioning teams performing “Extension
and Optimization of Capabilities” (EOC) in Chile. Starting the OT in its CSVALMA mode makes available
more capabilities than are provided to normal users so that these can be tested. There are also fewer
validation checks. Once a mode has been tested by EOC it is then usually transfered to the main OT for
use by PIs.
Instead, this manual attempts to give an overview of what is possible with the OT by a typical science user,
without going in to the kinds of detail covered in the resources mentioned above. Therefore, Phase-1 proposals
are described in terms of their main components, their purpose and what kind of information should be entered.
Where detail is given, it generally covers aspects of the OT that are not obvious. A list of acronyms (Appendix B)
may prove useful.
Users who are completely unfamiliar with the OT are recommended to read the following chapters: Chapter 2
provides information about how to install, configure and run the Observing Tool, Chapter 3 describes the main
components of an observing proposal and program, and Chapter 4 provides a general overview of the OT.
5In order to create a Phase-1 proposal, all the essential information is covered in Chapter 5 – this describes
the process in some detail and should be read by all users. Complementary to this is Chapter 7 which describes
various OT tools and Chapters 8 and 9 that give detailed information on how to use the visual spatial andspectral editors.
Phase-2 programs are covered in Chapter 6 where this essentially means Scheduling Blocks. It is not envisaged
that PIs will ever be involved with editing the contents of SBs, let alone create them manually, and this chapter
therefore remains only or practical interest to observatory staff.

1.2

User Support

In each of the three partner regions, an ALMA Regional Centre (ARC) has been established. Each ARC provides
scientific user support in the core areas of proposal preparation (Phase 1), observation program preparation(Phase 2) and data analysis to users in their respective communities. The ARCs will also host copies of the
ALMA Archive and will deliver data packages to users. Hence, the ARCs are the ALMA interfaces to the user.
More detailed information about the ARCs and how the interaction with the user communities is organised
can be obtained from their Web sites. The following three URLs point to the European, North American, andEast Asian ARC sites:
Europe: http://www.eso.org/sci/facilities/alma
North America: https://science.nrao.edu/facilities/alma
East Asia: https://researchers.alma-telescope.jp/e/ea-arc/
Before and after the observations you will have regular interaction with your ARC. The degree of interaction
will vary and depend on your experience and the complexity of the project undertaken. For simple projects,
experienced users may only need to submit their Phase-1 and Phase-2 programs without any need for further
support and they will receive their data package from the ARCs. Inexperienced users and more complex programs
may require active ARC support during all phases of the observing program.
In the event you encounter a problem or need support when using the ALMA Observing Tool you can contact
the ALMA User Support Service at your ALMA Regional Centre (ARC) or use the ALMA Helpdesk. All ofthese can be reached via the ALMA Science Portal:
http://www.almascience.org

1.3

Release Information

This version of the manual is intended to be used with the OT that will be used to submit normal (non-DDT)
proposals for Cycle 9.

1.4

Credits and Acknowledgements

The ALMA OT is a software product of the ALMA Observation Preparation Software Team and is developedon the basis of the ALMA Science Software Requirements (SSR) and the ALMA High Level Analysis (HLA)
documents, produced by the respective groups. The OT software group acknowledges the valuable inputs ofthese groups during the development phases of the OT. Testers from the external community are also thanked
for their valiant efforts over the years.

6Chapter 2

Install and Run the Observing Tool
The ALMA OT is written in Java and can be installed in two different ways, using an installer and with a
traditional tarball distribution. We recommend using the former as it’s simpler and also gives the user the
option to increase the amount of heap space (memory) made available to the OT – this can be very helpful whenprocessing large proposals.
If problems are encountered during installation and/or operation of the OT, users are recommended to
examine the Science Portal, especially the OT Troubleshooting and Known Issues pages, for solutions. The
Helpdesk1 may also contain useful information via its Knowledgebase system. If a solution to a problem cannot
be found, a user should then open a Helpdesk ticket.

2.1

System Requirements

2.1.1

Java

There have been great changes to Java in the last few years. Java 11 is the current “long term support” version
and ALMA now uses this when building its Java-based software tools. Unfortunately, Java 11 doesn’t include
the previously standard installation method (Web Start) and so this is no longer available. A new installer
based on InstallAnywhere has been developed that should continue to offer a more user-friendly and automatic
installation to that offered by the “tarball” approach.
As the new installer contains a Java distribution, it is no longer be necessary to have Java 11 installed onyour machine. However, a tarball download without Java will also be made available and, if so, the situationis unchanged from before i.e. a fully functioning Java Runtime Environment (JRE) must be installed and onlyJava 11 will work correctly.
If a version of Java has been installed by the user, its version number can be checked by typing java -version
on the command line, the output of which should look something like this:java version "1.8.0_271"
Java(TM) SE Runtime Environment (build 1.8.0_271-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode)
The number that follows the underscore refers to the update of the Java version that has been installed. Whenreporting a problem with the OT, the full version number including the update should be reported.
It may be possible to work with two different user-installed versions of Java (i.e. 8 and 11) and switching
between these.
1 https://help.almascience.org/

72.1.2

Supported Platforms

The OT should run on any machine so long as a version of Java is available. This is because the JRE includes aJava Virtual Machine (JVM) which actually executes the platform-dependent OT code. Regular testing of the
OT has found that it works using all common Linux distributions, Mac OS X and Windows. When reportingbugs, the platform on which the OT is installed should be included.

2.1.3

Disk Space and Memory

The basic OT release (tarball) takes up about 100 MB of disk space, but is significantly larger (∼200 MB) if
Java is included. If the new installer is downloaded the required space is closer to 300 MB.
The default memory allocation for the OT is 4 GB, but this can be changed using the OT Installer. Thislarge amount of memory means that only 64-bit versions of Java can be used with the OT.

2.1.4

Mac Issues

Macs contain a security application called “Gatekeeper” that can cause problems when installing the OT, especially on machines running Mac OS versions more recent than and including Catalina. Here we include some
information that might prove helpful, when working with both the installer and the tarball.
For example, starting the OT Installer will probably bring up a dialogue box saying that the application
cannot be opened due to it or Java being from an unidentified developer. In order to overcome this one must
open the “Security & Privacy” section of “System Preferences” and enable the installer there (“Allow Anyway”).
This might need to be done even if the dialogue box does not mention the reason for the failure to run the
installer. It is also probably necessary that the settings allow applications to run from “identified developers”.
More information can be found at the following url:
https://support.apple.com/en-us/HT202491

2.2

Using the OT Installer

With the demise of Web Start, a replacement has been developed in the form of a multi-platform installer
built using InstallAnywhere. This type of install method will be familiar to most users – the install package isdownloaded and when opened takes the user through a multi-step process which results in the creation of an
executable file with which the OT can be started.

2.2.1

Mac Installation

The OT Installer for Mac OS is available as a zip archive which is most conveniently extracted by double-clicking
on the file in a Finder window – one of these can be opened from the directory where the archive is located bytyping open . on the command line. The actual installer is called “almaot” (a command line ls will show that
this is a directory called “almaot.app”) and can also be opened by double-clicking. Note potential problems given
in Section 2.1.4.
Once the installer has been started it will bring up a succession of dialogue boxes which will guide you throughthe very simple install procedure – see Figure 2.1. In most cases one will just need to click “Next” several times.
The default install location is the Applications directory with a shortcut created on the Desktop – double-clicking
this will start the OT.

2.2.2

Linux Installation

For Linux distributions, the install procedure is very similar to that described above for Macs, but the download
has the extension “.bin” instead of “.app”. This is an executable file (you may have to change the permissions to8

Figure 2.1: The first page of the installation process.
make it executable) which will do exactly the same as the Mac installer once started.
The default install location is the user’s home directory and no shortcut is currently being created on the
Desktop.

2.2.3

Windows Installation

The Windows installation differs little from the above, although this time the file extension is “.exe”. Once thisis opened, it is quite possible that the operating system might warn about an unrecognised app and refuse to
run the installer. Our experience is so far confined to “Defender SmartScreen”, for which the simple workaroundis to click on “More info” and then choose to run the app anyway.
The installer will place the OT executable into a sensible default location and create a shortcut in the Start
menu. This can in turn be “pinned” to the Start menu for yet easier access.

2.3

Tarball Installation

2.3.1

Installation

The installer described above is basically a more convenient method of installing the tarball version and isrecommended. However, the tarball is a tried and tested install option and provides a backup in case of problems.
To install the OT using the tarball distribution please the follow the steps given below.
1. Download the OT tarball via the Science Portal and store the tarball in the directory of your choice. Notethat the tarball is available in .zip and in .tgz format. Choose the one that is most convenient for you.
2. Unpack the tarball in the installation directory you have chosen in Step 1.
3. Read the README.txt available in the installation directory and follow the post-installation setup instructions contained therein for your platform.
The post-installation setup for Linux and Mac OS is as follows:9

> cd ALMAOT-C9/setup> ./Setup-Linux.sh> cd ..
The setup is very similar for Windows except that the file that must be run will be named Setup-Windows, or
Setup-Windows.cmd. It may also be possible to download tarball versions which include a JRE – the installation
steps will be identical, but the file name of the download will be different.
Similar issues may affect tarball installation on a Mac as apply to the OT Installer (Section 2.1.4) e.g. theselection of “Allow Anyway” in “Security & Privacy”. After this, running the setup script again should work
correctly.

2.3.2

Starting the OT

For both Linux and MacOS, the OT can be started using the script that is in the directory in which you unpacked
the tarball distribution. For Linux the script is started as follows> ./ALMA-OT.sh &with a slight difference for Macs:> ./ALMA-OT.app &Note, that you can also add the OT installation directory to your path and run the ALMA-OT.sh script fromanywhere. If you’re on MS Windows, double-click ALMA-OT (might read ALMA-OT.cmd).
Performing the above will issue a number of messages in your terminal window and finally start the OT. The
script will also create a .almaot folder in your home directory, containing the user’s preferences and a log file(ot.log). The latter contains useful debugging information. A separate version is created each time the OT isstarted and each can be identified by the name which includes a timestamp.

2.4

Connecting Through a Proxy Server

If you are using the OT at a location where the internet is accessed through a proxy server, the OT will attempt
to automatically discover your existing proxy server settings.
If your system does not support automatic discovery of proxy server settings, then these will have to be
configured manually, either for the OT only, or for your Java installation. The former is only possible with thetarball version and you will be guided through the necessary steps during the setup stage.
The Java proxy settings are set via the Java Control Panel. The executable for this lives in the bin/ directoryof the Java installation and, if this in your path, can be started by typing ControlPanel (or jcontrol) at thecommand line. On a Mac it can also be launched from System Preferences. Once launched, the steps necessary
to set up a proxy can be followed: http://www.java.com/en/download/help/proxy_setup.xml.

10Chapter 3

Basic Concepts
The OT introduces a number of concepts that will generally be unfamiliar to users who are new to ALMA,
perhaps the most significant of which is the Science Goal. This and other features that are essential to the waythat proposing for and observing with ALMA works are now introduced, before being explained in more detailin subsequent chapters.

3.1

Phase-1 Proposals

The very first item to work on for obtaining ALMA observing time is the creation of an observing proposalthat successfully passes scientific and technical evaluation. The emphasis of the information provided is on thescientific requirements as opposed to the technical details of the telescope’s operation. The proposal should besubmitted during the proposal submission period which is announced via the Call for Proposals once a year.
Key components of a Phase-1 proposal are Science Goals, each of which, broadly speaking, encompasses
one task the user wishes to perform e.g. an observation of a number of sources at a particular frequency at aparticular resolution. Each Science Goal contains a number of pages, each of which covers a different aspect ofthe proposed observations, including the source list and the spectral setup.

3.2

DDT Proposals

The OT also allows the possibility of submitting proposals for Director’s Discretionary Time (DDT). Unlike
normal proposals these can be submitted at any time, but the user must ensure that the OT version usedcorresponds to the cycle that is currently being observed. For example, during the Call for Proposals for Cycle N,
Cycle N-1 is currently being observed and thus the Cycle N-1 OT must be used to submit a DDT proposal.
Within a particular cycle, DDT proposals can be submitted from the beginning of the actual observations forthat cycle which is usually at the beginning of October.
DDT proposals look different to normal proposals in that the colour bars at the top of each panel in the OT
GUI have a different colour (red by default). The OT also tries to include at various places (the GUI’s titlebar,
various submission dialogue boxes, etc.) that a DDT proposal is currently being viewed/worked on. Proposal
codes use letters for the subcycle field i.e. the first DDT proposal of Cycle 7 had the code 2019.A.00001.S.
It is now possible to open a normal proposal as a DDT proposal (and vice versa) via the options containedin the File menu.
11

3.3

ACA Supplemental Call Proposals

A Supplemental Call for Proposals for stand-alone ACA projects was first issued during Cycle 6, but this washandled without any changes to the OT. From Cycle 7, however, the OT released as part of the submissionof Phase-2 Science Goals (usually released at the end of July) will also be configured such that a dedicated
ACA Supplemental Call proposal can be created which enforces specific restrictions e.g. only stand-alone ACA
observations can be requested, no Large Programs, etc. As with the normal Call for Proposals, there will
be a submission time window defined on the server and only during this will it be possible to submit ACA
Supplemental Call proposals.
ACA Supplemental Call proposals are distinguishable from the other types in that the editor panels arehighlighted with a different colour (approximately cyan by default) and the proposal submission code uses thenumber ’2’ as the subcycle i.e. the first ACA Supplemental Call proposal of Cycle 7 had the code 2019.2.00001.S.

3.4

Stand-alone ACA

In its early cycles, it was only possible to obtain time on the ACA as part of observations conducted on the
12-m Array i.e. the shorter baselines of the ACA were required to image the largest angular scales in the source.
However, this restriction was dropped in Cycle 4 and since then it has been possible to request time for the ACA
only. This is referred to as the Stand-alone ACA (SACA) and allows a user to request time on the 7-m Array,
together with the TP Array if required. It is not possible to request only the TP Array in the OT.
Most observing modes available on the 12-m Array time can also be requested with the SACA.

3.5

Phase-2 Programs

After the successful submission of a Phase-1 proposal and having obtained observing time, the complete set oftechnical details of the observations need to be defined. This information is contained within Scheduling Blocks
and the creation of these is the heart of the Phase-2 process.
The OT provides two methods for creating Scheduling Blocks: they can either be created by allowing the
OT to automatically generate them from a Phase-2 Science Goal (essentially identical to a Phase-1 Science
Goal), or this can be done manually. The latter is not for the faint-hearted and is usually only carried out byobservatory staff. Successful proposals will have had their Phase-1 Science Goals automatically copied to their
Phase-2 counterparts and batch generation of SBs by observatory staff is the standard way of producing the SBs
in this case i.e. PIs do not create SBs themselves.

3.6

Science Goals

Science Goals are integral to the definition of a Phase-1 proposal as they describe the observations that are tobe performed. In order to make applying for time as easy as possible, Science Goals have been designed suchthat it is unnecessary to have a deep understanding of the technical details of an instrument as complicated as
ALMA, or of interferometry. Therefore, a Science Goal takes as input the scientific aims of an observation i.e.
the sources and transitions that are to be observed and the required sensitivity and angular resolution. How
these goals are to be achieved in practice should not necessarily concern a user and the OT will ensure throughits validation process that only proposals that are technically feasible can be submitted.
As already said, Science Goals come in two varieties, Phase-1 and Phase-2. Both look, and to all intents andpurposes are, identical. The main difference is that, if the SBs used to perform the observations are automaticallygenerated, this is done using the Phase-2 versions only. For expert users, Phase-2 Science Goals aren’t necessary
to produce SBs, but their use is highly recommended. Even if the required SB cannot be created with all details
correct, it should be possible to generate an SB from a Science Goal and then edit it.
12

3.7

Observing Unit Sets

Depending on the user inputs in a Science Goal, multiple Scheduling Blocks might result e.g. both the 12-m
Array and the ACA might be required and these cannot be observed with the same SB. SBs are contained withinfolders called Observing Unit Sets (usually abbreviated to ObsUnitSet or OUS) which can in turn be contained
within other ObsUnitSets. In principle, an arbitrarily complicated nested OUS/SB structure could be created,
but ALMA uses a fixed number of OUS for all observations.
The OUS levels in a project are shown in Figure 3.1 and comprise the following (from bottom to top):• Member OUS (MOUS) – this level, and only this level, can contain SBs. Currently, only one SB per MOUS
is allowed, although this restriction is lifted for commissioning projects. Once an SB within a MOUS has
been fully observed, the OUS will trigger the data reduction of the resulting ASDMs.
• Group OUS (GOUS) – this OUS contains one or more Member ObsUnitSets. If there is more than one
MOUS, usually when both ALMA and the ACA are required, this indicates that these should be combined
during subsequent data processing. This will be triggered by the GOUS once reduction of all the individual
Member ObsUnitSets is complete. Even if the GOUS only contains a single MOUS, it will still be present,
even though it strictly speaking isn’t necessary• Science Goal OUS – all Group OUSs for a given Science Goal are contained in the corresponding Science
Goal OUS. No pipeline processing happens at this level.

Figure 3.1: The Project Structure pane for a project involving two sources, each of which requires the 12-m
Array and the ACA. For each source, the SBs for each array live in their own Member OUS, and these arecontained within a Group OUS. The two Group OUSs are contained within their common Science Goal OUS.
The two sources are in separate Group OUSs because the data will not be combined.
As can been seen, one of the main purposes of an OUS is to define relationships between different SBs fordata processing purposes. The data processing pipeline is only triggered when all of the SBs inside an individual
OUS are marked as completed, unless other conditions apply to finish the observation.

3.8

Scheduling Blocks

Scheduling Blocks are the key executable units of a project and contain all information necessary to execute a“single” observation i.e. SBs are the quanta of the ALMA scheduling system. SBs typically last one hour, this13

relatively short time required to take advantage of rapidly changing atmospheric conditions at the ALMA site.
Therefore, SBs will often be repeated several times in order to achieve the desired sensitivity and will in general
not be executed consecutively. Each SB execution is referred to as an Execution Block (EB).
The SB contains a huge amount of information, including detailed information about e.g. the receiver andcorrelator setup that have usually been automatically generated from the scientific constraints entered in the
Science Goals. Calibration information will also have been created, usually in the form of “calibrator queries”
that prompt the telescope control system to search for a suitable calibrator at execution time based on a set of
constraints.
If an SB has been automatically generated, it is still possible to edit the various parameters if required,although this may not be possible for general users of the telescope. Manual creation is a particularly laborious
process and is intended for experienced observers and for observatory staff for developing and testing new
observing modes.

3.9

Project Submission

Phase-1 proposals and Phase-2 programs are submitted to the ALMA archive in Chile, with each submission
resulting in an email acknowledgement being sent to the PI and all other investigators. For non-DDT proposals,
multiple submissions before the deadline are possible. Once submitted, projects can be retrieved from the archive
using a search interface. Note that each submission causes a timestamp to be written into a project and if thisis older than the one attached to the archive copy, a warning will be issued. Because of this, it is often easier
to just work with the version of the proposal stored in the archive, although it is not currently possible to share
this with co-Is.
Projects from previous cycles can be used to create new proposals. For example, if an old project has been
stored on disk, it can be read into the OT and submitted as a new proposal (using the usual “Submit Project”
option in the File menu) so long as it is in the Phase-1 state i.e. the Proposal tab of the Project Structure paneis active. The Project Cycle shown in the Proposal editor will initially show the original value, but this will be
updated during submission, as will the previous proposal code if this had originally been set. When the projectis submitted, the OT will bring up a pop-up warning that a new proposal is being created, in case this is notwhat was intended.
No proposals from previous cycles that are stored in the archive should be in the Phase-1 state. Many will
have been rejected or be in a Phase-2 state, in which case SBs will almost certainly have been created. In either
case, these cannot be simply retrieved from the archive and submitted as a new proposal – instead the “Open
Project as New Proposal” option from the File menu should be used instead. This will convert the Phase-2
project into Phase 1 and remove any references to the previous cycle i.e. no project code will be set and the
Proposal Cycle will be set to the current value. All three types of Phase-1 proposal (Main Call, DDT and ACA
Supplemental Call) can be created in this way.

3.10

Project Validation

In order to ensure that the user’s specifications for an observation are indeed possible, in particular that theysatisfy the capabilities for the current cycle, the OT provides a number of validation checks. Part of the validationis performed automatically when observing parameters are entered and invalid input will be immediately coloured
red. Other warnings will also appear without any intervention by the user, particularly to do with the spectral
setup.
A complete validation is only possible by requesting this manually, most conveniently by using the icon in the
toolbar. ALMA proposals and programs can only be submitted to the ALMA archive if there are no validation
errors. Therefore, it is essential to check the validity of the input regularly. Regardless of this, a separate
validation will be performed at submission time, thus ensuring that no invalid proposals can make it into theserver.
Validation is available at Phase 1 and Phase 2, although it is only run on one of these at any one time. For
14example, SBs are generated whilst working in the Phase-2 tab of the Project Tree. Even if the Phase-1 Science
Goals are present in the other tab, any validation check will only work on the currently-selected (phase-2) tab.

3.11

AOT files

When saving a project to disk, the file that is written will have an aot extension (the prefix must contain atleast three characters!) and is usually referred to as an “AOT file”. AOT files can be emailed to other people forviewing in the OT, but once a project has been submitted, a co-I can also retrieve it from the ALMA archiveand view it in read-only mode.
There have been reports of users encountering problems with saving to disk and, upon reading the file backin, get a “ZLIB input stream” error due to the file being empty. The reason for this has never been tracked
down, mainly due to this error occurring very rarely. In response to this, the $HOME/.almaot directory contains
a subdirectory in which backups of projects are regularly made. This may allow the recovery of a corrupted
project.

3.12

Project Conversion

When importing a project from disk it is scanned to see if it is a project created with the current version of
the ALMA Project Data Model (APDM). This is a protocol that describes every piece of information contained
within an ALMA project and is usually different for different versions of the OT. If the imported project was
created using a different version of the APDM compared to that used by the OT that is trying to read it, anattempt will be made to convert it to the current version. If the upgrade is successful, the project will importsuccessfully and future saves will also conform to the new model. However, the imported project is unlikely to
successfully validate, usually because the new model requires information that was not present in the previous.
In case this was not what was desired, the OT will ask the user to confirm during a submission or whensaving to disk. It is usually not desirable to submit a project being observed during Cycle N with the OT used
to submit proposals for Cycle N+1. This is mainly an issue for ALMA staff.

15

16

Chapter 4

Overview of the Observing Tool
This chapter provides a brief overview of the layout of the OT and how it is operated. The OT is a fairly
complicated piece of software, in that it contains many different input pages, organised and accessible from anumber of different panels. For the novice user particularly, it is recommended that this chapter be read in order
to become familiar with the layout and various important functions and features.

4.1

Help

A number of different ways of receiving help during an OT session are provided. These include:• User Manual (this document) – provides comprehensive information about how to create a project, including
its main constituents, Science Goals and Scheduling Blocks.
• OT Quickstart Guide – provides a description of how create a Phase 1 proposal in 10 easy steps.
• Reference Manual – gives a brief description of every button and input field.
• Contextual Help – the “question mark” symbols scattered throughout the OT take you to the relevant
section of the Reference Manual.
• Tooltips – placing the mouse over an input field will reveal a short description of its purpose. The lengthof time that each is visible is viewable from the Preferences menu.
At the top of the OT GUI, at the right, you will find the Help button. This provides access to the User Manual,
the Reference Manual, the OT Quickstart Guide and general information about the OT. In the OT Help, theUser and Reference Manuals provide a table of contents, are fully indexed and have search a facility. Also, a listof favourites can be created.

4.2

The OT Main Graphical Interface

Once you have successfully started the ALMA OT, it should look similar to Figure 4.1. It contains three major
components: a menu bar at the top, a toolbar just below this containing the most frequently used functions,and finally a number of panes, the most important of which allow access to, and the construction of, an ALMA
project.

4.2.1

GUI Parameter Fields

The OT contains a large number of text and numerical input fields, many of which require units (e.g. angles,
temperatures, fluxes, etc.). Units for the parameters fields can be selected from a drop-down list located to the17Figure 4.1: The Observing Tool main GUI. This shows the OT as configured for use by a normal PI (i.e. without
special privileges) during the Main Call. This illustrates one of the “flat” look-and-feel themes that are now
available.
right of the input field. When changing the units with the mouse combined with holding down the Alt key, thequantity will be converted to that unit. Changing the unit without pressing the Alt key will change the unit
only. For example, if you have an angle of 1 arcmin, changing the unit to arcsec in the drop-down list without
the Alt key will result in an angle of 1 arcsec. If instead the Alt key is pressed, an angle of 60 arcsec will result.
The drop-down menu can be opened without the Alt key – this only needs to be depressed at the moment thatthe new unit is selected. Note that the appropriate key modifier is system dependent and on Linux systems it
may be necessary to use Ctrl-Alt instead.
When a text field is selected (with the cursor or by tabbing into it), then by default the text in the field will
now be selected. Typing anything will replace the value in the field. Changing this, so that new text is initiallyinserted into fields rather than replacing a field, can be done via the Preferences menu.
Another handy feature of the OT pertains to the entering of sexagesimal numbers i.e. source positions, in that
it is not necessary to use colons as separators. For example, entering 12 and hitting return will cause 12:00:00
to be automatically entered and 124050.5 will be formatted as 12:40:50.5.
The way that the OT deals with “illegal” input varies throughout the tool. It will often be the case thatwhen a bad value is entered e.g. a character where numerical input is expected, the input will be coloured red.
For a currently limited number of fields, the OT will in fact flash the entire entry field red and then reinsert thevalue that had originally been entered. Finally, validation will capture the remaining instances of where a value
doesn’t make sense.

4.2.2

GUI Features

Use of the OT relies heavily on selecting and manipulating items by means of standard GUI conventions such as
mouse-driven positioning of the cursor or mouse-button clicking to select elements. Standard operations such as
cut, copy, and paste, as well as drag-and-drop and other operations are all implemented and work basically inthe same way as on most windows-based platforms.
Cut, copy and paste can be used on practically any item within the OT, including textual fields and nodes
within the Project Structure tree. The usual modifier buttons will work i.e. on a Linux system Ctrl-C will copy18

a Science Goal and Ctrl-V will paste it. For Mac, the Cmd key should be used. Copied nodes will change colour(probably to pink) as a visual reminder that they currently reside in the copy buffer. The copy of an object willusually have the text “Copy of” prefixed to its name. Dragging and dropping is also supported and will usuallywork where it makes sense – a very useful application is copying pages from a Science Goal into another Science
Goal, replacing what was previously there. It is not possible, for example, to drop an OUS into a SB.
On a Mac, if the OT is being viewed in X11 over a remote connection, in order to see the Paste option after
copying it may be necessary to disable the option “Update Pasteboard when CLIPBOARD changes” in the X11
Preferences menu.

4.2.3

Menu and Toolbar

The menu bar gives access to a variety of OT functions and tools that are more-or-less self-explanatory. One
that all users should be aware of though is the Preferences menu that is accessed through the File menu. This
gives access to a large number of configuration options, including the ability to turn user privileges on or off.
This requires a password and will cause a number of the options within the OT, including menu and toolbar
items, to change. A recent addition is the ability to display the operations that are allowed to be performed by
the currently logged-in user.
The toolbar contains buttons for executing frequently-used OT functions and tools. Only those buttons areenabled that can be applied for the selected node in the Project tree. Unfortunately, not all of the icons arenecessarily self-explanatory although each has an associated tooltip. The validate button is a particularly usefulshortcut as this should be pressed at regular intervals.

4.2.4

The OT Panes

The area below the menu bar and toolbar is divided into a number of panes. Each of these has a couple of tabs
that determine which information is displayed and the position of these (bottom or top) can be controlled via
the Preferences menu. The panes can be collapsed and expanded by the small arrows on the boundaries of thepanes.
4.2.4.1

The Project Structure Pane

Each ALMA project consists of a number of different items, including Science Goals, ObsUnitSets and Scheduling
Blocks, that are arranged in a hierarchical tree structure which can be viewed in the Project Structure pane (alsoknown as the Project tree). Each item in the tree is known as a node and, when selected, will allow different
information to be viewed and edited in the main Editors pane. It is possible for the Project tree to become
very crowded and it is often advantageous to restrict it to only show down as far as a particular node. Nodes
are opened and closed using the “key” symbols and whole trees below a particular node can be collapsed andexpanded via the right-click menu. The Project Structure pane is shown in Figure 4.2.
The two phases of ALMA projects, Phase-1 proposals and Phase-2 programs, are viewable by clicking thetabs at the top (or bottom if you’ve changed this in the Preferences menu) of the Project tree pane. The Programtab is only clickable for approved proposals or for privileged users. When the Proposal tab is enabled, all panes
have a green (or red for DDT) header bar (the same colour is used for the Phase-1 steps in the Overview pane)
and a different colour, blue, is used for Phase 2. A separate option for privileged users allows a commissioning
project to be created, this using a purple colour.
The Project Structure pane can be split into a number of sections. The top section always contains the
project that is being worked on (either the Phase-1 or the Phase-2 tree). In the sections below, templates can beloaded, either from the ALMA Template Library, or from an existing project on disk. You can display several
projects in parallel. Note the grey background of the template sections, indicating that the content is read-only
and cannot be changed. With the OT, you can copy parts of the templates into the project that you are working
on. The project that is being worked on is visually highlighted and its title displayed in the title bar of the
Observing Tool main window.
19

Figure 4.2: The Project Structure Pane. Visible is the structure of a Phase-1 proposal with two Science Goals(top) and a project that has been loaded as a template (bottom). Note the search interface at the bottom of the
proposal’s Project Tree. The pink colour of the first Science Goal signifies that it was copied and pasted, before
being edited to create the second SG.

At the bottom of this pane there is now a search interface. This is particularly useful at Phase 2 after SBs
have been generated as a fully expanded Project Tree can be extremely long. Extensive help is available via thecontextual help button.

4.2.4.2

The Editors PaneThe Editors pane is the main interface that is used to specify a project. It actually contains three separate
editors: Spectral, Spatial and another which is usually referred to as the Forms editor. These are selectable via
the tabs although the Spectral and Spatial editors are only viewable when it is appropriate to do so e.g. whena Science Goal’s Spectral Setup or Field Setup page is active. The Forms editor is always available to receive
input and is also visible when using the Spatial or Spectral Editors. The name of the tab changes to reflect thecurrently chosen node in the Project tree.
Both the Spectral and Spatial tabs give access to graphical interfaces that are extremely useful for viewing aspectral setup, as well as for viewing and defining a field setup. It is highly recommended that these always beviewed when creating an ALMA project.
20

4.2.4.3

The Feedback Pane

The Feedback pane is intended to help the user to act on errors and warning messages that are revealed after the
project is validated. It is not possible to submit a project to the ALMA archive if there are any errors (warnings
are allowed) and so it is extremely important to validate before submission and, preferably, regularly during a
project’s creation. The Feedback pane appears automatically when the validation command is executed, even if
it has previously been hidden.
Upon validation, the feedback can be inspected in three tabs: Validation, Validation History and Log. The
former is the one that is usually used and gives a row listing of the errors and warnings found during the mostrecent validation. The location of each problem is indicated by a cross on a red background in the Project tree
and double-clicking on the row will cause the location to be displayed in the Editors pane.
4.2.4.4

The Overview PaneThe Overview pane at the bottom of the OT window outlines the steps for preparing a new Phase-1 proposal or
Phase-2 program. Clicking on the arrows will bring up a help listing which may also include clickable links toperform the necessary steps. It is recommended that this panel be minimised unless you are a novice user.

4.3

OT Configuration

The OT supports a number of layout and display configurations that can be selected by the user. The mostbasic configuration option is that you may collapse the various panes in the main GUI window and/or change
their size. Collapsing can be done via the small arrows next to the pane borders; the border themselves can be
moved using the left cursor button. These changes are automatically maintained the next time you run the tool.
Additionally, using the Preferences menu a large number of OT settings can be specified, mostly to do with
the OT’s appearance and behaviour. Particularly useful options include the time that each tooltip is displayedfor, whether a Science Goal is displayed as a summary table or a collection of all its editors, and whether the
OT should display Spatial, Spectral or Forms editors by default. Options for the OT’s appearance have recently
been made expanded via the addition of various “flat” options for the “look and feel” of the GUI.
Other features of the Preferences menu include:• Dialog behaviour – the OT displays many dialogue boxes during its operation, often to confirm if a particular
operation is really required. At the risk of making mistakes, it can be advantageous to switch some of theseoff using the Dialogs tab. This is particularly useful for people who do a lot of work with SBs.
• User credentials – if they have already been entered, e.g. to submit a project to the ALMA archive, or toenable user privileges, the username and password will be displayed here. These details are rememberedby the OT and will persist across OT sessions.
• User privileges – if a user has an account with special privileges, these must be activated using the Advanced
tab. Once this is done, the OT will prompt for the username and password each time it is started. Notethat this means it is not possible to use the OT with user privileges without a network connection!
All user preferences are stored by the OT in the $HOME/.almaot directory and will be used when starting
the OT.

21

22

Chapter 5

Phase 1 – Observing Proposal
This chapter guides you through the steps needed to produce a Phase-1 proposal that can be submitted to the
ALMA archive. To follow the descriptions, it is recommended that you have an open OT session in front of youat the time of reading.
Most proposals submitted to ALMA are submitted during the Call for Proposals for a particular cycle which
is usually issued once a year. In addition, it is possible to submit a Director’s Discretionary Time (DDT) proposal
at any time during that cycle’s observing period (usually starting in October). DDT proposals look identical tonormal proposals except for the colour used to highlight the title of each pane in the OT’s GUI (Project Structure,
Editor and Feedback). This is green for normal proposals and reddish-pink for DDT. A recent addition has been
ACA Supplemental Call proposals which use cyan as the distinguishing colour by default.

5.1

Open a Phase-1 Proposal

A proposal is often created from scratch using the File menu or toolbar, but it is also possible to read in anexisting project from disk or from the archive. Previously-submitted proposals that have been retrieved fromthe archive will be in Phase 2 and cannot be used to create a new proposal as is. However, they can be read inand converted to new (unsubmitted) Phase-1 Proposals using an option in the File menu. There is also now an
option to open a previously submitted project as a DDT or an ACA Supplemental Call proposal.
The first task is to provide some generic information about the project. Selecting the Project node in the
Project Structure tree will enable both the PI to be chosen, by querying the ALMA User Database, and a title
for the project to be entered, although both can in fact be entered in the subsequent Proposal node. Once theproject title has been entered, this will be reflected in various places in the OT: the main GUI titlebar, theProject node and the Forms tab of the Editors pane. A non-editable project code will initially be blank and only
be completed once a proposal has been submitted for the first time.
Note that privileged users will also see panels entitled Project Notes and Advanced Options. Amongst otherthings, these enable observatory staff to gain access to restricted information about a project (including theoutcome of its scientific and technical review) and to note useful information.
To continue with proposal creation, the Proposal node in the Project tree should now be selected. A numberof information fields should be visible in the Editors pane and double-clicking on the node will reveal an empty
node named Planned Observing; the Phase-1 Science Goals are kept here. Also note that on top of the Project
tree, in the blue banner, the status of the proposal is visible. For newly created proposals it will say “Unsubmitted
Proposal” whilst proposals that have already been submitted will show “Submitted Proposal”. If this message isvisible, submission of the proposal will overwrite the previous submission!
23

5.2

The Proposal Form

When the Proposal node is selected, the Proposal form is loaded in the Editor pane. The form contains roughly adozen fields for describing the proposal, including an abstract, proposal type, scientific keywords and investigator
information. Completing the information should be straightforward and the meaning of the fields, and whether
they need to filled in, self-explanatory. Note though that the proposal type can only be edited for proposals
before their first submission – after this, no further edits are possible. The available proposal types are:• Regular: these proposals request relatively modest amounts of time and are submitted by most users.
• Large: these are defined as proposals that require more than 50 hours for the 12-m Array or 150 hours forthe stand-alone ACA (measured by the 7-m time only). These projects must receive an A grade in orderto receive time and are allowed a longer Scientific Justification.
• Target Of Opportunity: for proposing the observation of an unpredictable sudden astronomical event, suchas a Gamma-ray burst. Source coordinates do not have to be entered at proposal submission time.
• Phased Array: observe an object (currently restricted to pulsars) using ALMA operating as a single dishi.e. the signal from each dish in the array is phased up and summed. The resultant signal has previously
only been used for VLBI observations, but is now available in a stand-alone mode. Passive phasing must
be used with this mode (it is assumed that the sources are too faint to be used for phasing, this certainly
being true for pulsars) and only Band 3 is available.
• VLBI: ALMA can observe as part of a VLBI array due to the installation of hardware that allows thesignals from each antenna to be summed. However, a VLBI proposal must also be submitted to the VLBI
array in question e.g. the Global mm-VLBI Array (GMVA).
Once a Science Category has been provided, a list of keywords appears, the content of which depends on which
category has been picked. At least one, and up to two, can be chosen and the Shift and Control/Command keys
can be used to select multiple entries in the usual manner.

5.2.1

Adding Investigators

Further down the page is a panel for adding the details of the Principal, Co-Principal and Co-Investigators –these must all have registered in the Science Portal before they can be added in the OT and we strongly advisethat this is done well in advance of the proposal deadline.
A project can have only one PI, but any number of Co-Is. Large Programs and VLBI proposals (not Phased
Array) can in addition have multiple co-PIs. Clicking on e.g. “Select PI...” will start-up a window which allows
you to search for and select users from the ALMA user database. Within this, users can be identified by theirname, email address or ALMA ID (username). To find matching users, select which attribute should be searchedfrom the drop-down list, enter a valid constraint into the text field and click “Find Investigators”. If the enteredconstraint is invalid, it will be highlighted in red and searching will be disabled. A valid constraint consists of:• Name: at least 3 characters (partial matches are reported)• ALMA ID: at least 3 characters (only exact matches are reported)• Email: a valid email address (only exact matches are reported)
All searches are case-insensitive and multiple queries can be performed in one go by entering search terms
separated by commas. In case only one result is returned, it will be automatically highlighted for convenienceand double-clicking any row will enter this user into the table of investigators. In the case of co-Is, highlighting
multiple entries will cause these to be entered into the table – removing them works in the same way.
One of the columns in the table shows a user’s Executive. Currently, the Executive of the PI determines
whether the time required for a project is charged to the East Asian, North American or European share of24

available observing time and is usually set at the time of registering in the Science Portal. Taiwanese investigators
though must set this in the OT as they can decide, per proposal, between charging all of the project’s time to
NA or EA, or to split it evenly between the two. Although this only has any effect for PIs, the OT still allows
a Taiwanese co-I’s Executive to be set in this way. For Large Programs, the executive share is split between the
Co-PIs.
When there are many investigators, these can be added from a previous proposal that contains all or someof the desired investigators using the “Add from Proposal...” button. The project in question must exist on thelocal disk and once selected, its investigators will be added to any that have already been selected.
As astronomers move between institutes from time to time, the affiliation details in a proposal can end up
not matching those in the User Registry. If a project is submitted by the PI when it is in a Phase-1 state (e.g.
during the Call for Proposals for non-DDT projects) the OT will update the details of any investigators if theseare different to those stored in the User Registry. This will happen either at submission time, or at the creationof a new proposal if the “Open Project as a New Proposal” option was used. If any of the investigators has
moved to a Taiwanese institute, the submission will be terminated and the PI asked to check that the executive
share is set correctly – it will default to ‘EA’.

5.2.2

Reviewer Information

A reviewer must be nominated for a subset of proposals submitted as part of the Main Call, and for all proposals
submitted in response to the Supplemental Call. This is to enable the reviewer to participate in distributed
proposal review. For the Main Call, the OT will request that reviewer information be added if the proposal
is not a Large Proposal. However, only those proposals confirmed by the JAO to request less than a certain
amount of time (currently set at 25 hours of 12-m time) will ultimately be asked to participate in the distributed
review. All Main Call proposals over the threshold will be reviewed by panels. More information can be foundin the Proposer’s Guide.
If the reviewer doesn’t have a PhD then it is possible to nominated a suitably qualified mentor who will
provide support.

5.2.3

Scientific Case

Below the list of investigators, the PDF document to support the science case must be attached. This is limited
to a maximum of four pages (six for Large Programs) and must not exceed a total size of 20 MB. Figures canbe included if desired. Once attached, the PDF file can be removed and replaced with another and can also beviewed, provided that your computer contains appropriate software.
The minimum font size for the PDF is 12 point. A check is made of the fraction of text smaller than thiswhich, if >15 per cent, will cause a validation error to be issued (this was previously just a warning). Sometimes
the amount of small text is larger than expected due to a figure having been extracted from a PDF document
e.g. using Preview on a Mac. This can lead to all the text on the page from where the figure was extracted toappear in the resultant figure, albeit invisible. If you receive the warning and think this is erroneous, then thispossibility should be investigated.
The technical justification should not be included in the PDF, this information being placed into a dedicatednode of each Science Goal.

5.2.4

Management Plan

Large Programs must include a single-page PDF describing how resources will be made available to ensure thatthe large volumes of data will be dealt with. The font-size restrictions also apply here.
25

5.2.5

Duplicate Observations

The ALMA Science Archive (ASA) is continually growing and now contains a very large number of calibrated
datasets. It is expected that every prospective ALMA user has searched the ASA to check that their proposed
observations are not duplicated by previously observed programs. If the current proposal does duplicate aprevious observation then this should be justified in the appropriate panel. A failure to do so may result in the
proposal being rejected. More information on what constitutes a duplication can be found in the Science Portal.

5.3

Adding Phase-1 Science Goals

Phase-1 Science Goals are added in a number of ways, but the most convenient is by using the toolbar icon.
Each time this is clicked, an empty Science Goal will appear underneath the Planned Observing node and by
default each will show its six sections. Note that a Science Goal can only be added if either the Proposal or
Planned Observing nodes are currently active. There is no limit to the number of SGs that can be added.
A number of summary views of the defined Science Goals are available. The first is a table that is visible
when the Planned Observing node is active – each row gives a brief description of each SG. If the top node of a
Science Goal is selected, what is displayed depends on the user’s preferences. The choices are a similar table tothat displayed in Planned Observing or a view of all six sections of a Science Goal simultaneously.

5.3.1

GeneralThe Science Goal name and a description of the Science Goal can be placed here if desired.

5.3.2

Field Setup

5.3.2.1

SourcesIn the Field Setup page, the user is asked for source parameters, the most important of which are the name,coordinates and velocity. The source names should only contain the following characters: a-z, A-Z, 0-9, -,+, _or a . (full stop). Characters other than these will be removed or replaced when the project is validated.
Apart from Galactic coordinates, the only system that should be used is ICRS. FK5 can be entered, but theobservations will be performed as if the coordinates were ICRS. This has very little impact as the difference issmall, amounting to a maximum of some tens of mas. The two components of the source proper motion, Dec.
and R.A. (cross declination), are both true angles on the sky and are used to convert the given source position
to an observable one assuming that it refers to epoch J2000.0.
The ALMA telescope control system recognises a limited number of solar system objects that can be selectedfrom a drop-down list. This same list also allows the use of an ephemeris for any object for which the coordinates
as a function of time can be provided. This is loaded as a text file from the local disk and must be in the
JPL HORIZONS format. For details on how to generate HORIZONS ephemeris files, please check Appendix A.
When using an ephemeris at Phase 1, it is recommended that only a skeletal example be attached to the Science
Goal, using a time interval of one day to cover the period over which the observations are likely to take place. An
ephemeris is also required for Solar observing and a tool is available in the Science Portal for generating these.
The velocity can be specified using the optical, radio, or relativistic convention. A number of different frames
are available and the must useful of these are barycentric, heliocentric1 , topocentric and lsrk. The velocity isused to convert the rest frequencies of the spectral windows to the observed equivalent and for barycentric andheliocentric, this is done in the same frame i.e. the “observed” velocity will remain in that frame. In the caseof lsrk though, the OT performs an additional conversion to the barycentric frame. When changing the source
velocity reference system between the available options of heliocentric, barycentric, topocentric and lsrk, the OT
is not able to convert the velocity and you will be reminded of this via a pop-up dialogue box.
1 Barycentric and heliocentric only differ by ∼12 m s−1 and the telescope control system will actually use barycentric if heliocentric
is requested.

26

The velocities must be sufficiently similar such that all the sources can be observed in a single band. In
addition, a maximum of five tunings per Scheduling Block are allowed and thus the sources must be grouped invelocity space in such a way that this limit is not exceeded. The OT will issue an error if this is the case. Thisissue is explained more in Section 5.3.3.11.
5.3.2.2

Source clustering/Psuedo-Science Goals

It was previously the case that all sources in a Science Goal had to lie within 10 degrees of each other, but that
restriction has now been dropped. Instead, the OT now includes a “hierarchical clustering” algorithm which
will automatically split the sources into 10-degree clusters. Each of these is henceforth treated as if it were aseparate Science Goal and, during development of this feature, these have indeed been referred to as PseudoScience Goals (PSG). Users who wish to observe many sources across the whole sky, but for which a single setof performance parameters (angular resolution, sensitivity) apply, will hopefully find this feature useful. For
long-baseline Science Goals, a smaller clustering length is used (1 degree) as the phase calibrators need to berelatively close to the science targets.
As each PSG is treated exactly as a normal Science Goal, the 150-source and five-tuning limits now apply to
the PSG. Array selection is also performed as for a normal SG and different arrays can potentially be selected
for each PSG given that the array properties (angular resolution and maximum recoverable scale) are source
declination-dependent. How the sources have been split into clusters will be made clear using the various
summary tools of the OT, including the time estimate dialogue box and the project time summary. Each PSG
will generate its SBs into a completely separate OUS structure.
There may be issues with slow response times due to the extra computation that the OT has to perform. In
addition, the range of angular resolutions that can be entered into the Science Goal is restricted compared towhat would be possible if the project were created as separate SGs. This is because the angular resolution range
is declination-dependent and thus differs for each cluster. In order to avoid unexpected validation errors, thedisplayed angular range limits on the Control & Performance node are therefore restricted to those values thatwill not produce a validation error for any of the clusters that currently exist. This restriction will probably only
matter if the required angular resolution might require either the smallest or largest 12-m configuration and, in
this case, it might be necessary to split the sources manually into separate SGs.
5.3.2.3

Resolving source information

Source details can be automatically filled in by “resolving” a recognized source name. The OT uses the Sesame2
web service to first query SIMBAD3 and then, if no source with that name is found, NED4 . It is not possible
to select which server is queried although the OT will state which one gave the displayed result. The enteredsource name must correspond exactly to that contained within SIMBAD or NED or else no match will be found.
The coordinate system of all sources will be set as ICRS.
Be careful with the proper motions of bright quasars. The Hipparcos mission measured non-zero values formany of these although, reassuringly, the associated uncertainties mean that the results are consistent with zero.
Nonetheless, it is the measured, non-zero, values that will be entered into the OT. Parallax can also sometimes
be negative, but again this is due to the measurement uncertainties. Where spurious, these properties should all
be set to zero.
Although an extremely useful tool, resolving source information should be used with care and the returned
details checked very carefully. For example, the origin of the coordinates will often be from an optical or infrared
telescope and may not be appropriate for the science you want to do with ALMA. The SIMBAD or NED websites
should be checked for this kind of information. The OT will present a table containing the source informationthat has been resolved, before this is entered into the Field Setup form, and warn if proper motions or a velocity
have not been found. The name contained in this table will usually be different to that searched for, but this isnothing to worry about. The actual name that was entered by the user will not be changed.
2 http://cds.u-strasbg.fr/cgi-bin/Sesame
3 http://simbad.u-strasbg.fr/simbad/
4 http://ned.ipac.caltech.edu/

27

If the OT is unable to resolve a source and the details of a source had previously been entered, it will bringup a dialogue box asking whether the name should be reset to the previous source or whether the failed searchterm should be left for editing.
The user has the ultimate responsibility to ensure that the source details are correct!
5.3.2.4

Expected Source Properties

Once the source position and velocity information has been completed, details of the source brightness, polarization (linear and/or circular) and line widths should be added. These numbers are used mostly for technicalassessment of the proposal and as such are used extensively in the information presented to the user in theTechnical Justification node (Section 5.3.6).
All the relevant values should be filled in, even if exact quantities are not known – reasonable estimatesshould be entered. Which fields should be filled in depends on the type of observation being created and the
OT will issue a validation error if, for example, a line width is not entered for a spectral line project or apolarization percentage is not given, or is below the instrumental limits, when full polarization has been selected.
For spectral-line projects, a spectral line flux is mandatory and this should always be entered relative to thecontinuum (if any). If the line is in absorption, the depth of the line relative to the continuum should be enteredas a positive flux density.
For solar observing, the source property panel looks very different. Here, all that is requested is an assesmentof whether the solar feature being observed corresponds to an “active” or a “quiet” Sun. This will be used to
select the corect debiasing mode when observing.
VLBI is another special case – more information is required than for solar, but still much less than for aregular ALMA project. An important VLBI-only feature is the ability to request that “passive phasing” be usedduring VLBI-type observing. It was initially only possible to use the science target as the phasing calibrator
and thus VLBI was restricted to relatively bright sources (>0.5 Jy). However, it is now possible to request that
another source be used for this purpose i.e. the phasing solutions found on the calibrator are used during thescan on the science target – VLBI users of the VLA will be familiar with this mode. If the appropriate checkbox
is ticked, a nearby (phase) calibrator should be defined in the Calibration Setup node and justified in the TJ
node. Note that passive phasing must be used in Phased Array mode. Spectral-line VLBI requires that thewidth of the line be entered – this is to ensure that the line fits into the spectral window which is fixed at a
specific frequency.
5.3.2.5

Field definitions

The observing patterns that are used to observe a source fall into two categories:• Rectangular area – a uniformly-spaced pointing pattern that covers the rectangle is calculated by the OT,
for both the 12- and 7-m Arrays. The TP Array will observe a larger version of the user-defined rectangle
and this is displayed in light blue in the visual editor. If one of the sources is defined using a rectangle, all
the sources in the SG must be.
• Multiple individual pointings which are to be mosaiced together – if the source extent is not easily approximated with a rectangle, then a custom mosaic can be used to cover the source more efficiently. All
the pointings must overlap and the Pipeline will produce a single image. If the ACA is required, the OT
will automatically calculate the smallest rectangle that encompasses the 12-m pointings. This will then be
tiled with 7-m Array pointings using Nyquist sampling and redundant pointings removed. The TP Array
will raster scan the rectangle.
In both cases all the pointings must overlap such that there are no gaps in the coverage i.e. one contiguous source
is being mapped. If it is desired to map multiple separated areas of emission, each must be entered as a different
source.
For rectangles, the 12- and 7-m Array pointings that are calculated by the OT are overlapped so that the final
map will have approximately the same sensitivity at each point – this is necessary as the sensitivity of a radio28√
telescope drops away from the pointing centre. The spacing parameter defaults to the Nyquist value, λ/( 3 D),
this being appropriate for the OT’s hexagonal/triangularmosaic pattern. As the antenna beam size is 1.13 λ/D,√
the actual value reported in beam units is 1/(1.13 3) i.e. 0.51. Particularly for projects that are mapping large
structures, this should not be changed, but projects that aim to cover a large area of relatively small sources canuse a larger value. The value of λ is set from the Representative Frequency (Section 5.3.3.8).
Both rectangles and individual pointings can be defined using the Visual Spatial Editor (Chapter 8) if desired.
This shows the user-defined rectangle, the 12- and 7-m antenna pointing positions, as well as a larger rectangle
that corresponds to the area that will be covered by the Total Power Array. Individual pointings can additionallybe read into the OT from an ASCII file, whilst all pointings can be written to file, including those derived by
the OT from a rectangle.
Under some circumstances it is only possible to define a single pointing, including all Band-10 observations,spectral scans and VLBI. If observing mosaics in full polarization it is recommended that Nyquist sampling or
higher is used.
5.3.2.6

Solar total-power observing

Observing the Sun with the Total Power array is significantly different to TP observations of other sources. In thelatter case the TP antennas perform a raster scan of the source, observing along successive rows with increasing
vertical offsets until a rectangular area has been covered. For the Sun though, the TP observations must use
so-called “fast” scanning in order to map this large source quickly enough such that the changing properties ofthe solar disc can be properly resolved in time.
For early cycles of solar observing it was only possible to produce TP maps of the full solar disc, even though
the interferometric data only covers a small region on the Sun’s surface. From Cycle 9 though it has been possible
to also request TP observations of this region, in addition to the full solar disc. How the TP observations arecarried out is specified in a special panel (“TP Regional Mapping”) where the user can, for example, indicate
whether they want just the full solar disc or maps of the interferometric region as well.
At the moment, in regional mode it is only possible to observe a circular area mapped using a so-called “doublecircle” pattern – for this the user only needs to define the diameter of the circle which should be somewhat larger
than the interferometric mapping area. More options will be added in the future.
5.3.2.7

Import/Export of Source Information

Positions, velocities and the “expected properties” of multiple sources can be added to a Science Goal from an
ASCII file using “Load from File...” located at the bottom of the node. This can be used to either load a set of
additional sources, or to completely replace the list of currently-defined sources. The format of the ASCII source
list (case-insensitive) is shown below; it should be possible to cut and paste this into a text editor. Alternatively,
the “Export to File...” option can be used to create a template.
Name, RA|Galactic Long (Degs), Dec|Galactic Lat (Degs), PMRA(mas/yr), PMDec(mas/yr),vel(km/s), Ref frame, Doppler type, peak cont flux(mJy), peak line flux(mJy), cont pol(%),
line pol(%), line width(km/s), cont circular pol (%), line circular pol (%)-This signals end of the header
ngc253, 00:47:33.134, -25:17:19.68, 0.0, 0.0, 258.6, lsrk, RADIO, 200, 1000, 2, 0, 1500, 0, 0
ngc1068, 02:42:40.771, -00:00:47.84, 0.0, 0.0, 1142.0, topo, OPTICAL, 1100.0, 30, 0, 0, 20, 0, 0
If the source coordinates are entered as decimal degrees, the OT will interpret these as Galactic.
In addition, the individual pointings that make up a field definition can also be imported or exported to file,
on a source-by-source basis. An example of the format is:
RA , Dec, Coordinate Type, Coordinate Units-This signals end of the header
04:31:38.4369, 18:13:57.651,Absolute,Sexagesimal29

04:31:40.5426, 18:13:57.650,Absolute,Sexagesimal
04:31:36.3312, 18:13:57.650,Absolute,Sexagesimal
The “Absolute” coordinate type can be combined with the units “Sexagesimal”, “Degrees” or “Radians”, whilst“Offset” pointings can be defined in “Arcsecs”, “Arcmin” or “Degrees”. Both the unit and coordinate type arecase-insensitive. It is not possible to read the pointings in for a rectangle.

5.3.3

Spectral Setup

The Spectral Setup page contains fields to specify spectral windows, each of which samples a sources’s spectrum
over a particular range of frequencies. These are defined either manually or with the Spectral Line Picker(Section 7.3). All setups should be inspected using the Visual Spectral Editor (Chapter 9).
As mentioned in Section 5.3.2.1, the OT will convert all rest frequencies to their observed equivalent, mostobviously using the source velocity. However, if the entered velocity is in the ’lsrk’ frame, the entered frequencies
are additionally transformed to barycentric. Ideally, the OT would peform a full conversion to topocentric(reference frame of the antenna) but this is not possible as the OT does not know when the observations willtake place. The telescope control software then makes the final ’bary’ to ’topo’ conversion. Single-continuum andspectral-scan setups are explicitly in topocentric, regardless of the frame specified in the Field Source definition.
5.3.3.1

Spectral TypeThe OT offers three kinds of spectral observation:• Spectral Line – offers maximum flexibility as almost any number of spectral windows can be defined, withuser-defined centre frequencies and correlator modes• Single Continuum – automatically defines a maximum bandwidth (7.5 GHz), low spectral resolution correlator setup. This is most useful for measuring a continuum, but can also be used for observing broadlines• Spectral Scan – automatically defines a set of multiple tunings which cover a continuous frequency range.
This is particularly useful for observations of sources with dense forests of lines, or for redshift searches.
5.3.3.2

Recovering image sidebands at Bands 9 and 10 (90-Degree Walsh Switching)

ALMA uses two types of receiver, “two-sideband” (Bands 3 to 8) and “double-sideband” (Bands 9 to 10). The
main difference is that double-sideband receivers need special processing (90-degree Walsh switching) in thecorrelator in order to recover the two sidebands of each spectral window. In Cycles 0 to 4 this wasn’t available
and one sideband (known as the “image”) was instead rejected i.e. the astronomical signal removed such that it
didn’t appear superimposed on the spectrum from the other (known therefore as the “signal”). Since Cycle 5 it
has been possible to recover both sidebands and this is selected in the OT using a checkbox for Band 9 and 10
setups.
For single-continuum observations the advantages of using this feature are clear as it doubles the effective
bandwidth, thus halving the observing time necessary to achieve a given continuum sensitivity. The image
sidebands are thus always produced in this case. Spectral scans will also usually benefit from this as the whole
point here is to cover a large bandwidth efficiently and doubling the bandwidth clearly facilitates that.
For spectral-line observations the situation is less straightforward. The reason for this is that it is not possible
to define the centre frequency of both the signal and image sidebands for each spectral window and therefore
it is difficult to create setups where a spectral window contains a spectral line in one sideband and a different
one in the other. The most obvious application of 90-degree Walsh switching is therefore combined spectralline/continuum observations where, for example, one spw might observe a spectral line in one sideband whilst
the other three spws observe the continuum. In both cases a large bandwidth makes most sense (to increase thechances of a line falling in the image sideband and to maximise the continuum sensitivity) and thus 90-degree30Walsh switching is only allowed if all spectral windows have the maximum-allowed bandwidth of 1875 MHz. It is
expected that use of the Spectral Visualizer (together with the line-overlay feature) will greatly help in creatinga 90-degree Walsh setup.
One important consequence of using 90-degree Walsh switching is that it nominally doubles the data rate.
This can be a problem for setups that use all four spws with no spectral averaging, especially if the requested
angular resolution is such that a “long-baseline” configuration, and thus short integration durations, is required.
Although 90-degree Walsh switching is applied to every spectral window and thus the image spw is always
produced, it is possible to indicate per spw that this should be discarded (not written into the ASDM) byunchecking the “Store Image” checkbox. Additionally, every spw is now by default spectrally averaged by afactor of two. This halves the data rate but, due to the fact that each spectrum is also Hanning smoothed, thespectral resolution is only degraded by ∼15 per cent. Science Goals for which the average data rate exceeds amaximum value will not validate.
Note that 90-degree Walsh switching is only available for interferometric observations and therefore it is not
currently possible to observe at Band 9 or 10 with the TP Array.

5.3.3.3

Polarization Products

All ALMA receivers detect two orthogonal senses of linearly-polarized radiation (X and Y). For maximum
sensitivity, dual-polarization observations correlate both signals, producing XX and YY for each spectral window.
For each baseband, a total of 8192 channels are available and these are divided up between the two polarization
pairs. Single polarization (XX) is rarely observed, but as this can place the full 8192 channels across a single
spectral window, it can be useful when the highest possible spectral resolution is required.
Full polarization (XX, YY, XY and YX) should only be selected if a measurement of the source linear or
circular polarization is desired. As twice as many products are being created, the spectral resolution is reduced
by a factor of two compared to dual polarization. Full polarization is now also available for the Stand-alone
ACA (single pointing only per source) but not for the TP Array or for 7-m Array observations added to a 12-m
Science Goal for purposes of imaging the largest angular scale. There is a limit on the lowest polarization thatcan be detected – 0.1 per cent in linear and 1.8 per cent in circular polarization.
Mosaics are now possible for continuum observations of linear source polarization only – circular polarization
mosaics are not allowed. Where mosaics cannot be performed there are restrictions on the maximum source
size that can be observed (different for linear and circular polarizations) and Single Continuum with the default
frequencies must be used.
For projects using the VLBI system (including the Phased Array) technical issues require that full polarization
be used.

5.3.3.4

Spectral-window placement

Before going on to discuss the various ways in which spectral windows can be defined, it is interesting to considera few aspects of spectral-window placement that can be easily overlooked.
Firstly, although one only receives data from the defined spectral window, the receivers also detect powerfrom the other sideband. For example, if a spw is defined at 637 GHz (Band 9) the default setup is to place thisin the USB with the LSB lying over a very deep atmospheric absorption line. The two sidebands are separated in
the correlator, at which point it is not possible to remove the noise contribution from the other sideband. Thus,in Bands 9 and 10 we advise that sidebands not be placed over prominent absorption features, if at all possible.
In Bands 3-8 the situation is less serious as the sidebands are separated in the receivers and thus the noisefrom the other sideband is rejected (by ≥10 dB). However, it can still be a good idea to avoid deep absorption
lines (such as the water lines in Bands 5 and 7) as this can cause problems with Tsys measurement and flux
calibration.
Another issue concerns the placement of the spws within the basebands. Each baseband is 2 GHz wide andthe edges (30-60 MHz) should usually be avoided due to various issues that lead to deterioration of the sensitivity
31and accuracy of flux calibration. For example, two narrow (∼ 60-MHz) spws placed in the same baseband andseparated by 1.9-GHz will significantly encroach into these relatively poor edge regions. This can be difficult tosee visually as the SG spectral visualiser does not show basebands, but the OT will warn if any part of a spw
lies within 30 MHz of the baseband edge.
5.3.3.5

Spectral Line – one spectral window per baseband

Spectral setups are usually created with up to four spectral windows, one per baseband. If so, each spectral
window is completely independent in terms of the bandwidth and spectral resolution (correlator mode) that it
can use. The modes come in two flavours, one with high spectral resolution (FDM) and one with much lower
resolution (TDM) that is often used for continuum measurements. There are many FDM modes and these havebandwidths ranging between 58.6 and 1875 MHz. All the TDM modes have a bandwidth of 1875 MHz andappear in bold text in the drop-down menu.
The spectral resolution is set firstly by the number of channels produced by the correlator over the bandwidth.
When processing dual polarization, the correlator produces 4096 channels for FDM and 128 for TDM, with double
this for single polarization and half for full polarization. The channel separation implied by the bandwidthand number of channels would correspond to the spectral resolution, but, as the data are by default Hanningsmoothed, the spectral resolution is actually equal to twice the channel width. Note that none of the channels
are thrown away in this process i.e. the channels in the output spectrum are not independent.
For FDM spectral windows it is possible to average groups of 2, 4, 8 or 16 channels together such that the
total number of channels is reduced by the same factor. The original spectral resolution is often higher thanrequired and averaging reduces the data rate (particularly important for long-baseline observations as these canapproach the maximum allowed) and data volume (speeding up analysis). As the spectra are also Hanningsmoothed, the spectral resolution does not degrade linearly and averaging by a factor of two only reduces theresolution by ∼15 per cent – this is the default for all FDM spws. For large numbers of channels the spectral
resolution tends towards the channel width multiplied by the spectral averaging factor. Any averaging shouldstill allow the spectral lines to be well resolved, especially if multiple observations (EBs) are required and willneed to be combined during data processing into a single spectrum.
Spectral windows are positioned by setting their central frequency, either in the rest or observed frame. The
only real restriction on where they can be placed is that the relative positions of each must be such that they all
lie within the sidebands of the receiver. The most common sideband arrangement is used by bands 3, 4, 5, 7 and
8 where there are two 4 GHz-wide sidebands separated by 8 GHz. The other bands have different arrangements,
but are easily visible on the Spectral Visual Editor (Chapter 9) where they are displayed as vertical bands.
Each time a spectral window is created or edited, the OT will automatically attempt to calculate a tuning
solution. If one can be found, the sidebands in the Spectral Visual Editor will be coloured yellow and no errors
will be reported. If errors are reported, the sidebands will be grey and the best course of action is to examine thevisual editor and see which spectral windows (blue) need to be moved in order to fit them all into the sidebands.
5.3.3.6

Spectral Line – more than one spectral window per baseband

It is possible to have more than one spectral window per baseband and this is known as multi-region mode. In
the correlator, this works by splitting a single FDM spectral window into multiple sections (regions), each ofwhich can be placed independently within the baseband. Notice that this does not change the spectral resolution– the bandwidth per channel stays the same. Although the correlator could create more, users are currently
restricted to a maximum of four spectral windows per baseband. TDM spectral windows cannot be split in thisway.
Setting this up in the OT is slightly different to that described above as one doesn’t explicitly choose a
specific correlator mode and then split that into smaller sections. Instead, one just creates the spectral windowsthat would result from following such a procedure, using the fraction parameter to change the available spectral
window bandwidths in the drop-down menu. For example, using the default fraction of unity, there are six
available FDM spectral windows. If the fraction is then changed to 1/2, the same spws are displayed, but theirbandwidths are one half of their previous value. Also, there is one less spw available as it is not possible to split
32

Table 5.1: Available spectral windows in multi-region mode (dual polarization). Each time the fraction is changed,
the number of channels and bandwidth of a particular correlator mode is halved. Each row corresponds to aparticular spectral resolution.
Fraction = 1
Bandwidth (MHz) # channels
1875
4096
937.5
4096
468.754096
234.3754096
117.1184096
58.5944096

Fraction = 1/2
Bandwidth (MHz) # channels
937.5
2048
468.752048
234.3752048
117.1182048
58.5942048
not available

Fraction = 1/4
Bandwidth (MHz) # channels
468.751024
234.3751024
117.1181024
58.5941024
not available
not available

the narrowest spw. This is illustrated in Table 5.1.
As usual, the OT will warn if anything illegal is attempted. The main things to be aware of are that the
total fraction cannot exceed 1 and that each spectral window, before spectral averaging, must have the same
spectral resolution. If required, each spectral window can subsequently be spectrally averaged, but the “native”(unaveraged) spectral resolution must be the same for each spectral window.

Figure 5.1: Example of a multi-region mode setup. A spectral window with a width of 1875 MHz has been split
into three smaller windows using the fraction parameter and each placed at a different frequency.
An example of a multi-region mode is shown in Fig. 5.1 where a 1875 MHz-wide mode has been split up into
three spectral windows. In addition to the restrictions on spectral window placement mentioned in Section 5.3.3.5,
in multi-region mode the windows must all lie within the 2-GHz baseband width. Technically speaking it is notnecessary to use the whole of the original spectral window i.e. the sum of the fractions can be less than one.
5.3.3.7

Spectral Line – VLBI

Spectral-line observing with VLBI is significantly different to the standard ALMA case. First and foremost, the
VLBI data are only taken in a single spectral window at a fixed sky frequency of 86.268 GHz, this being used
to observe the SiO ν = 1 (2 − 1) line with a rest frequency of 86.243370 GHz. None of the parameters of thisspectral window can be edited by the user. The other three basebands can be used to define additional spectral
windows that will produce ALMA-only data. Their frequencies can be freely chosen, so long as a valid tuning
solution can be found.
Another aspect of spectral-line VLBI that is non-standard is that the user must enter an observing date forthe observation using the time-constraint interface (single visit). This is needed in order for the OT to confirm
that the full width of the line will fall into the central 234 MHz of spectral window on the expected date, given
the source’s velocity relative to the telescopes. For this reason it is also necessary to define the expected line
width in Expected Source Properties. If the line cannot be observed then there will be a validation error.
5.3.3.8

Representative Frequency

A very important parameter that should be carefully set is the Representative Frequency (RF). This is done byselecting one of the spectral windows to be the Representative Window and this automatically sets the RF to
the centre frequency, as measured in the rest frame of the source. Using a rest frequency is important as
this is common to all sources, even if they have different velocities. For actual application (e.g. to calculate the33required time) the rest frequencies are converted to their sky equivalents using the source velocity. If desired,
the RF can be changed to another rest frequency within the spectral window.
This parameter is important because it is used when determining the time required to achieve the requested
sensitivity. If the spectral window frequencies correspond to relatively uniform atmospheric transmission, thisbeing especially the case in bands 3, 4 and 6, the exact choice of the RF is usually not crucial. However, where
the transmission is changing rapidly (Band 8 is particularly non-uniform) which spectral window is chosen to set
the RF can make a huge difference to how much time the OT will calculate.
The Representative Frequency should therefore usually be placed at the centre of the line that one is mostinterested in, and the requested sensitivity usually also applies to the RF. This is not the case for continuum
projects because the sensitivity is usually being measured over multiple spectral windows. Here, one should
probably select the spectral window with the poorest atmospheric transmission, but continuum measurements
are usually made at frequencies where the transmission curve is fairly flat.
The Representative Frequency also sets the antenna beamsize and therefore the spacing parameter for mosaics(Section 5.3.2.5). For this reason, with all other things being equal it can be a good idea to use the highestfrequency spectral window for setting the RF, and single continuum setups default to this. If the lowest were used,
the sampling of the spectral windows at higher frequencies (smaller beam) would be less than that requested.
5.3.3.9

Single Continuum

The Single Continuum interface automatically creates four spectral windows located such that they cover the
maximum possible bandwidth. The default centre frequencies are also placed such that the atmospheric transmission is maximised and thus the single-continuum interface is ideally suited to providing the highest-sensistivity
continuum maps of a source. For 2SB receivers (bands 3-8) two spectral windows are placed in each sideband.
For bands 9 and 10 (DSB) all four are placed in the same sideband. If necessary, the frequencies of the spectral
windows can be changed by setting a different average frequency i.e. the relative positions of the spectral windows
is fixed.
The Representative Frequency (Section 5.3.3.8) will default to being the central (sky) frequency of the lastspectral window. As with the spectral line interface, this can be changed, both by selecting a different spectral
window and by moving the frequency within this. However, it is not possible to change the other parameters of
the individual spectral windows.
As the same suggests, Single Continuum setups are intended for continuum observations and thus werepreviously only allowed using low spectral-resolution spws i.e. the TDM correlator mode. It is now possible toinstead select FDM mode – this covers the same bandwidth but has significantly higher spectral resolution. Thiscan be useful when observing a continuum that is contaminated with spectral lines which must be removed during
data processing. This significantly increases the size of a dataset and so should only be selected if absolutely
necessary. If the FDM mode has been selected, spectral averaging of the spws is possible.
For solar observations, the use of Single Continuum is currently enforced and the frequencies of the spectral
windows are fixed i.e. it is only possible to select which band one wants to observe in, not what the spw frequencies
within the band are.
5.3.3.10

Spectral ScanA spectral scan is defined by entering a start and stop frequency, in the observed/sky frame only, as well as thecorrelator mode that should be used (bandwidth ≥ 500 MHz). Using these parameters, the OT will then attempt
to cover the requested frequency range using a maximum of five tunings. The OT will display a warning message
if the requested frequency range can’t be achieved because more than five tunings are required. It is generally
not possible to cover the exact requested frequency range and the OT will usually provide more coverage thanrequested. Spectral averaging is available for the high-resolution modes, but will be the same for each spectral
window of each tuning.
The OT tries to select the most efficient way of covering the requested range and will, generally speaking, usea single sideband for a relatively narrow range and two sidebands otherwise (this will activate 90-degree Walsh34

switching at Band 9 or 10). A single sideband is always used with the 500 or 1000-MHz spws. Tunings and spws
are all slightly overlapped so as to avoid problems with edge channels. With two sidebands there is always afrequency range that is covered by more than one tuning and this unavoidably leads to non-uniform sensitivity
across the scan.
The best way of seeing how the spectral windows are placed is by using the Spectral Visual Editor. Spectral
windows corresponding to the same tuning are plotted with the same y-offset and displayed with the same colour.
Also shown is the requested frequency range for easy comparison with the actual frequency coverage.
Spectral scans are currently not allowed for use with the Total Power Array.
5.3.3.11

Multiple velocities and tuning solutions

In both Spectral Line and Single Continuum cases, it is possible to enter sources with different velocities. For
Single Continuum, this is irrelevant as the setup is defined in the sky (topocentric) frame and thus the source
velocities are ignored. For Spectral Line though, the velocities are crucial as these are used to convert the rest
frequencies to their observed equivalents. In general, this means that each source requires its own tuning andits own set of calibration observations. This greatly increases the complexity and time required to complete a
project and thus each Scheduling Block is restricted to five separate tunings.
The number of required tunings is calculated automatically by the OT in the following way:
• Firstly, a tuning solution is calculated for each of the N sources that lie within a 10 degree-wide cluster.
As described in Section 5.3.2.2, the OT can now automatically split the sources present in a SG into theseclusters.
• For each cluster, the OT then selects a source (n) and loops through all the other N − 1 sources to see
if they could be observed with n’s tuning i.e. does a line at the centre of each spectral window fit into
the spectral windows of source n? In performing this check, the OT takes the user-defined line width into
account.
• This is then repeated for every source n. This leads to, for each source, a list of other sources that arecompatible with its tuning. These are referred to as “sets”.
• Any sets that are a subset of another are discarded at this point.
• Finally, the OT tries to find the smallest subset of these sets which would enable all sources to be observed.
This part of the process is computationally intensive and the time required grows rapidly with the numberof input tunings. The OT therefore has a limit of 16 input sets. If this number is exceeded, the OT will
issue a validation error and the user will need to reduce the number of sources that have been entered.
The final number of tunings (sets) found by the algorithm is reported in the Time Estimate dialogue box(Section 5.3.5.3). As already stated, no more than five are allowed per SB and the user may have to split thesources into multiple SGs.
5.3.3.12

Rest Frequencies

During data reduction, it is desirable to know the rest frequencies of those transitions that are contained withineach spectral window so that the velocity scale can be set. Another reason is that this information can be used
to enhance the search interface of the ALMA Science Archive and the user is strongly encouraged to enter the
rest frequencies of all targetted transitions.
Many spectral windows are created by searching the Splatalogue using the Spectral Line Picker (Section 7.3)
and for these the rest frequency, Splatalogue ID and transition label (e.g. SiO v=1 6-5) are all stored. So longas the spectral window isn’t subsequently moved such that the original transition no longer falls into the spw,
this information will automatically be written to the SB. However, it is often the case that a spw will observe
multiple transitions, or that it was created manually and therefore contains no Splatalogue information. If thisis the case, the user should manually add the rest frequencies of the additional spectral lines.
35

The easiest way to do this is by overlaying the spectral lines using the version of the Spectral Line Picker
that is attached to the Visual Spectral Editor (Chapter 9). This is often a good thing to do anyway as it cangreatly aid in placing spectral windows, but the advantage here is that the rest frequencies of any overlaid linesthat lie within a spw will also be automatically written to the SB. This is the recommended way of entering rest
frequencies.
If this is not done, an alternative is provided by the Rest Frequency SLP which can be found on the Spectral
Setup page.

5.3.4

Calibration Setup

5.3.4.1

User-defined calibration

The Calibration Setup page allows a user to choose between user-defined and system-defined calibration schemes.
It is recommended that the system-defined option be chosen as the observatory will ensure that suitable calibrators are used. If user-defined calibration is chosen, the reasons why and the choice of calibrators must be
described in the Technical Justification node (Section 5.3.6).
Two system-defined calibration choices are available. With the default mode the bandpass calibrator also
serves as the amplitude calibrator and thus the observing time is reduced. The source will be a bright quasar
whose flux is regularly monitored and thus known fairly well. If higher flux accuracy is required, another modeis available whereby a separate amplitude calibration is carried out using a solar-system object.
If user-defined calibration is specified, a table appears that shows the initial list of calibrators – calibrators
can either be deleted from or added to this list. Two types of calibrator are available: fixed and dynamic. Fixedcalibrators request a specific source whilst the dynamic variant consists of criteria (position, search radius, flux
limits) that are used to choose a source from the ALMA calibrator database at the time that the SB is executed.
Dynamic queries can be tested during Phase 1, but the database is likely to change between proposal submission
and program execution.

5.3.4.2

Astrometry

ALMA’s default calibration strategy will provide some level of positional accuracy for e.g. a point source in animage. If better than the default accuracy is required, this should be indicated by selecting enhanced positional
accuracy. Although ALMA does not yet have a commissioned astrometry mode, this information will be used todetermine those projects that might benefit from a custom calibration strategy e.g. the use of additional phasecalibrators, or from observing in better than the default weather conditions.
If enhanced accuracy it selected then it is necessary to complete a special section in the Technical Justification
node.
Requesting enhanced positional accuracy is not allowed for Large Programs, VLBI or Stand-alone ACA.

5.3.5

Control and PerformanceThis page of the Science Goal allows the user to enter important scientific objectives that will determine many
aspects of how the observations will be executed. These include the desired angular resolution and the largest
angular structure that needs to be imaged – these determine which arrays and configurations need to be scheduled.
As the opacity of the atmosphere at mm/submm wavelengths is large and highly frequency-dependent, theuser requests a 1-σ rms sensitivity instead of a time. The OT will then derive a time estimate based on
expected observing conditions, although the actual observing time may be different because of different observing
conditions at the telescope (number of antennas, atmospheric conditions, etc.). Solar and VLBI observations aredifferent as the user requests a time and does not enter a desired sensitivity.
36

5.3.5.1

Imaging considerations: arrays and configurations

For the imaging goals of a project to be met, a suitable range of antenna baselines must be observed such thatthe requested angular resolution is achieved (longest baselines) and the largest angular structure in the source
reliably imaged (shortest baselines). It will often be the case that the required range of baselines cannot be
achieved with a single array configuration and that additional ones, including the ACA Total Power Array,might be needed. Which arrays are required will be decided by the OT automatically based on the user input.
To guide a user in entering parameters on the Control & Performance node, the OT displays various information regarding the configurations that are available in the advertised cycle. As it is not possible to show all
the configurations, information is only displayed for the ACA 7-m array, the most compact 12-m configuration,
as well as the most extended 12-m configuration that is available in the requested frequency band (the largest
configurations are not available at the highest frequencies). The information displayed includes the angular resolution (λ/Lmax ) and Maximum Recoverable Scale (0.6 λ/Lmin ) which have been calculated using simulations.
The displayed values are declination-dependent and assume a robustness of 0.5 during imaging (the ALMA
Pipeline default). Also shown is the beamsize of both the 12-m and 7-m antennas (1.13 λ/D) the size of which
will determine whether multiple pointings are required to image the requested area. The Representative Frequency that was entered on the Spectral Setup page is used to calculate λ. Note that the largest configurations(C-7–C-10) trigger a “long-baseline” observing mode whereby the phase-referencing cycle time is much shorter
than is usually the case. Which configurations trigger this mode varies from cycle to cycle.
A number of options are available for indicating the required angular resolution and the recommended approach is to enter a range of angular resolutions as this provides flexibility when scheduling the observations
and increases the chance of an SB being executed. Similarly, “Any”) indicates that any non-long-baseline 12-m
configuration is acceptable. It remains possible to enter a single value of the desired angular resolution. Finally,
requesting stand-alone ACA observations is possible without needing to enter an angular resolution.
Any value can be entered for the Largest Angular Scale (LAS) and this should reflect the best estimate of thelargest structure in the source that needs to be imaged. If the source is much smaller than the requested angularresolution, then entering a value of zero is acceptable, but otherwise the user should try and enter a realistic,
non-zero value. No value can be entered if the angular resolution has been set to “Any” as only a single 12-m
configuration is observed and thus it is assumed that the source is small enough that its structure can be imaged
with all of the non-long-baseline configurations. If this is not the case, then this option should not be chosen.
Once the angular resolution and LAS have been entered, the OT can calculate which configurations arenecessary. If the OT has split the sources into multiple clusters (Section 5.3.2.2) the algorithm is applied
separately to each Pseudo-Science Goal. If a single angular resolution has been entered, the algorithm can besummarised as follows:• Based on the requested angular resolution, the OT will choose the 12-m configuration whose angularresolution closest to the one requested.
• The OT then checks to see whether a second, smaller one is necessary to achieve the requested LAS. If oneof the larger 12-m configurations has been selected, it will not be possible to add another 12-m configurationand it might be necessary to reduce the requested LAS to avoid a validation error. Similarly, if the 12-m
configuration is relatively small, a second 12-m configuration will not be selected.
• If the LAS still cannot be achieved after considering 12-m configurations, it will be necessary to include
the ACA 7-m Array and perhaps the TP Array as well, also this is not always possible e.g. for Bands 9
and 10 and projects observing using single continuum.
The procedure if a range has been entered is similar except that the OT will first find multiple 12-m configurations that lie within the requested range and for each of these it will find the additional configurations/arrays
required to achieve the LAS. At this point, the OT will discard any combination of configurations that require
more than the minimum e.g. if one combination requires 2 12-m configurations to achieve the LAS and another
only 1 (because it is smaller and contains shorter baselines) then the OT will only consider the one with thesingle 12-m configuration. Similarly, if the range implies a mix of long-baseline and smaller configurations, only
the non-long-baseline ones will be considered further. All combinations that are not discarded are shown in thetime-estimate dialogue box.
37

An important consequence of the above points is that the effective angular-resolution range used to schedulethe observations may be significantly narrower than that requested, especially if an extended source is being
observed. Users should experiment with their inputs and consult the time-estimate dialogue box when selecting
a range of angular resolutions.
ALMA has for some years now offered a fixed set of 10 12-m configurations which are used in the OT toreflect the likely angular resolutions and LAS values that can be achieved. While not all have been available foreach observing mode (e.g. the largest configurations have not been allowed for use with the highest-frequency
bands) each of the 10 configurations was always visited at least once during a cycle. That has now changed and
it is no longer the case that every cycle will include a vist to every 12-m configuration. This will be reflected in
the angular resolutions and LAS values shown in the table at the top of the Control & Performance page andtherefore the range of angular resolutions that can be requested.
5.3.5.2

Sensitivity considerations

The time required to achieve the requested sensitivity depends crucially on the spectral setup, particularly the
Representative Frequency (this sets, amongst other things, the atmospheric opacity) and the spectral resolution.
If the sensitivity is requested in kelvins, the angular resolution will also have an effect. The Representative
Frequency should have been chosen to reflect the most important spectral feature that is to be imaged, althoughin parts of the spectrum where the opacity is well behaved, which spectral window is chosen will actually makevery little difference to the time estimate.
How the entered sensitivity is interpreted also depends on whether a rectangular field definition has been
selected. If so, the sensitivity entered should be that required in the final mosaiced map, not that corresponding
to a single pointing. As the pointings in a mosaic usually significantly overlap, the combined sensitivity is higher
and thus requires less time per pointing. For Nyquist sampling, and assuming a Gaussian beam shape, thesensitivity of a mosaic is 68 per cent better than that of a single pointing and the time required per pointing
is reduced by a factor 2.8. The OT will calculate this factor for the selected spacing and use it when estimating
the time for the project. In contrast, the sensitivity entered for a custom mosaic is always for a single pointing.
It is also necessary to define the bandwidth over which the sensitivity should be calculated. This will dependon the scientific goals, but usually refers to the full usable bandwidth for continuum observations, or to somefraction of the line width otherwise. The OT provides a number of shortcuts for completing this parameter and“AggregateBandwidth” (the sum of the non-overlapping bandwidth of all spectral windows) and “RepresentativeWindowResolution” (the resolution of the representative spectral window, including Hanning smoothing andany spectral averaging) are the defaults for Single Continuum and Spectral Line setups, respectively. Finally, auser-defined value is possible, this usually being set to a width in velocity units.
At this point, enough information has been entered for a time estimate to be calculated.
5.3.5.3

Time Estimation

When a Science Goal time estimate is requested, a dialogue box is displayed (Figure 5.2) that attempts toindicate how the total time, including calibration and overheads, was arrived at. On-source times are derived
using the ALMA Sensitivity Calculator (described in detail in the ALMA Technical Handbook) and, in the same
way as the array characteristics, assume that imaging will be done using a robustness parameter of 0.5. If the
OT has split the sources into multiple clusters (Section 5.3.2.2) the time-estimate dialogue box is tabbed.
Broadly speaking, the OT time estimates are arrived at by (silently and invisibly) converting the informationin the Science Goal into the Scheduling Blocks that will be executed at the telescope. It does this by taking
the required on-source times, the default times for the various calibrations (both of which are frequency- andarray-dependent), the best estimate of the current overheads and latencies, as well as a standard time for how
much on-source time an SB will typically contain (50 minutes for a 12-m Array SB). Required integration times
that are longer than this will therefore require multiple executions of the same SB (each of which is called an
Execution Block, or EB). On the other hand, the requested sensitivity can imply a very short amount of observing
time and therefore the OT enforces a minimum amount of time that can be spent observing a single pointing(10 seconds). In addition, the total time for all sources combined cannot be less than 5 minutes (or 50 per cent38

of the calibration time, whichever is largest).
In addition to the minimum time, the time spent observing will often be a bit longer than that required basedon the requested sensitivity alone. This is because each observation of a source is broken down into so-called
subscans. A subscan is the fundamental quantum of ALMA observing, typically has a duration of 30.24 s and,once one is started, will always run to completion. Therefore, if 61 s were required to reach the sensitivity,
90.72 s would actually be observed. The time estimate tries to convey this to the user by displaying two values
for the time per pointing (Fig. 5.2). The number in brackets is the time required based on the sensitivity, whilst
the other is the time that will actually be spent observing. The OT has limited freedom to lower the subscan
duration from its default value in order to avoid cases where much more time is spent observing than necessary.
An SB will normally include a bandpass/amplitude and phase calibrator and each of these has an associatedpointing calibrator. The time spent observing a calibrator at each visit, and the time between visits (cycletime) is a function of band, the integration times being longer and the cycle times shorter at higher frequencies.
Observations that require either long baselines or high frequencies also have a “check” source included. This issimilar to a phase calibrator, but has a longer cycle time and can be used to check that the phase calibration
has worked. Full-polarization observations also include a dedicated polarization calibrator.
In deriving its time estimates, the OT assumes that each cluster of sources within a Science Goal will go
into a single SB. This is even the case if multiple tunings are defined i.e. spectral scans or sources with different
velocities. Every band is calibrated separately and therefore this is not a particularly efficient observing mode andthe OT will warn a user if more than one EB is required. Under these circumstances, it might be advantageous
to the user if they split the different tunings into separate SGs. In future cycles, a new observing mode will
be commissioned for use at the telescope and the OT will almost certainly change the way that these types ofobservation are created.
Other interesting cases include:• Polarization – this requires that a calibrator be observed over a wide range of parallactic angle. In practice,
this will done by running the SB several times consecutively such that the necessary time coverage is built
up. The OT therefore assumes a minimum time of 3 hours for a polarization Science Goal (including
calibrations and overheads). The polarization calibrator is observed at the beginning and end of the first
SB and once in subsequent executions.
• Mosaics – the OT will always ensure that an integer number of complete mosaics are scheduled per SB
execution, including custom mosaics. The subscan duration (see above) has particular significance formosaic observations as each pointing in the mosaic is observed for a single subscan. As mosaics can include
up to 150 pointings, the OT will actually reduce the subscan in order to make a complete mosaic fit into
the allowed 50 minutes per EB. More generally, the OT includes an algorithm which will try and ensurethat multiple mosaics per SB will be observed an integer number of times, this integer and the subscan
duration potentially being different for each mosaic. This is a tricky calculation to get right and observing
inefficiencies in these cases cannot be ruled out.
• Angular-resolution range with sensitivity in kelvins – due to the dependence on the square of the angularresolution, the time estimates can vary greatly between different configurations. The OT will always use
the angular resolution of the largest possible 12-m configuration for the time estimate as this will require
the most time. As the observation may actually take place using a smaller configuration, the expectedsurface-brightness sensitivity that would be provided by the smallest 12-m configuration is also reported.
• Total Power with multiple sources – as stated above, all sources in a cluster are placed into a single SB,
one for each array i.e. 12-m, 7-m and TP. However, if multiple sources are given for a SG that requires a
TP SB, it is possible that multiple TP SBs might be created. This is because it takes a minimum time
to complete one pass through each TP raster scan (mosaic) and if the size of the rasters and the numberof sources mean that a single pass through all could not be completed in the maximum-allowed on-source
time (currently 40 min) then the OT will split the sources into multiple TP SBs.
If any other configurations are required (a more compact 12-m configuration and/or the ACA 7-m and TP
Arrays) then their times are calculated as a multiple of the on-source time required for the largest configuration.
39

To this are then added the expected calibration time and overheads.5 The TP on-source time which is reported in
the time estimate will generally be larger than that implied by the multipliers (given in the Technical Handbook)due to the need to observe integer numbers of TP rasters.
As before, it is assumed that the ACA 7-m and TP Arrays will be able to observe in parallel and therefore
the multiplicative factor used for both ACA Arrays in total will actually be equal to that for the TP Array alone,as that is larger. As the compact configuration multiplier is less than 1, a minimum time for the resulting SB isenforced that is equal to the time required to perform the various calibrations.
5.3.5.4

Differential Gain Calibration

Sometimes it is not possible to use standard calibration techniques due to a lack of SNR on the phase calibrator.
This can result from the aggregate bandwidth of the spectral setup being too low or observing at high frequencies
where calibrators are fainter. Observing in large configurations can also present difficulties due to the phasestability being poor. For these reasons, some observations are now carried out using Differential Gain Calibration(DGC), a technique whereby an additional spectral setup is used that gives sufficient SNR on the phase calibrator.
As there is generally a phase difference between this spectral setup and that used for the science observations,additional observations are made of a strong source (“DGC calibrator”) in order to determine the phase difference.
There are two varieties of DGC observing:• Bandwidth Switching (BWSW) – the additional spectral setup uses the same frequencies as the science
setup, but the maximum bandwidth is used in order to produce enough SNR on the phase calibrator.
• Band-To-Band Observing (B2B) – sufficient SNR on the phase calibrator is instead achieved by using an
additional spectral setup with a maximum-bandwidth setup at a lower frequency band.
B2B has allowed ALMA to accept proposals requesting the highest frequency bands (7–10) with the largest
configurations (C-8–C-10), although not all of these are currently commissioned e.g. Band 10 with C-9 or C-10.
The need for B2B is checked by performing a search of the calibrator catalogue to see whether a phase calibrator
is present that is both bright and close enough to the science target. If yes, then in-band (normal) calibration
will be assumed. If not, the OT will assume that B2B must be used, but will now check if a suitable calibrator
is available at the lower frequency. If there still is no calibrator available, the OT will issue a validation error.
Bandwidth Switching is currently assumed by the OT for any “narrow-bandwidth” setup i.e. those where
the aggregate non-overlapping bandwidth is less than 937.5 MHz. This is somewhat crude as DGC might not
actually be required where there is a very bright calibrator near the science target. It is likely though that asimilar procedure to that used in the B2B case (calibrator search) will be used in the future.
The additional calibration time required for DGC is included in the OT’s time estimates.
5.3.5.5

Solar and VLBI

Solar and VLBI projects are special as a sensitivity cannot be entered i.e. the user must enter a time request. In
the case of VLBI, the time must correspond to the total observing time (plus calibration) and it is assumed that
VLBI observers know what they’re doing in this regard. There is also no need to enter an angular resolution as
the user has no control over this. The VLBI observations are generally hold during times of the year when the
12-m array is in a relatively small configuration as this makes it easier to phase up the antennas.
For solar, the OT is now able to deliver a more accurate time estimate based on the on-source time. Thisis therefore different to the requirement in Cycle 6 and earlier. Based on the entered on-source time, the OT
will calculate a total time estimate based on the expected observing strategy, for both interferometric and TP
SBs. An angular resolution is entered for solar, but only a subset of the configurations are available and this isband-dependent.
5 This was new in Cycle 7 – in previous cycles the 7-m and TP times were calculated by applying the multipliers to the total
observing time. This is simpler, but less accurate.

40

Neither of these project types are available during the ACA Supplemental Call and an attempt to open a
previous solar or VLBI proposal as a Supplemental Call proposal will fail.
5.3.5.6

Overriding the OT’s time estimate

There are circumstances under which the OT’s sensitivity-based time estimate might not be reliable. For example,
although the instantaneous uv-coverage of ALMA is excellent, there might be occasions on which a very brightsource with a complicated structure might require more time than estimated by the OT. Another case might be
the need to observe a source whose flux density is highly variable and thus the major factor in determining thetime is to observe the source for long enough to track a certain number of variability cycles. If this is the case,then it is possible to override the sensitivity-based time with a user-entered estimate. This should be the timerequired for the most-extended 12-m configuration, including calibration and overheads. If other configurations
and arrays are required, the OT will calculate the times for these in the same way as if the 12-m time had been
calculated from the sensitivity. Why a user-defined override is necessary must also be rigorously justified in theTechnical Justification node and a detailed description of the user-defined time estimate given.
5.3.5.7

Simultaneous observing

This option is thought to be mainly useful for observations of solar-system objects and specifies that the 12- and7-m arrays should observe simultaneously (at the same time, for the same amount of time). If this is requested,
it must be the case that only a single 12-m configuration and the 7-m array are required or a validation error
will result. As implied, the 7-m time will be set to the same as the 12-m. Unlike other observing modes, it ispossible to use any 12-m configuration together with the ACA. Please note that configurations C-7, C-8, C-9,
and C-10 are however excluded from simultaneous observing, as they cannot be paired with ACA.
5.3.5.8

Time-constrained observing

It is possible to define various timing constraints for the observations that form a Science Goal. In general thisis only available when a single array configuration is required (single 12- or 7-m) although it is available if thesimultaneous option has been selected. Two kinds of time-constrained observations are allowed:• Specific dates – the SB will be observed during one of the specified dates. This will be useful for coordinating
observations with another observatory or for observing objects that are only visible during certain time
windows e.g. comets.
• Multiple visits – if the SB should be repeated several times, each visit can be specified individually andcan be either given as a specific date, as a time relative to a previous visit or a mixture of the two. Note,however, that some combinations do not make sense and are thus not allowed by the OT i.e. an abritrary
start date followed by a specific date. Reasonable margins on the requested times should be entered. Ifthese are too restrictive then it will be difficult to schedule the SB executions.
When defining relative multiple visits, it is perhaps worth noting a subtle difference between the two ways of
doing this, namely all visits being relative to the first visit or all relative to the previous visit. In the former
case, one can imagine all the visits as defining fixed points in time, the actual observations happening within thedefined margin around each grid point. If each is instead defined relative to the previous one, then it’s possiblethat the last observation may end considerably before or after the nominal end date if, for example, some quirkof scheduling leads to all visits being observed at the earliest or latest possible time. In the limit of normally
distributed deviations from the nominal time then both approaches are of course identical.

5.3.6

Technical Justification

In order for the proposal review committees to judge that the proposed observations are technically feasible andwill achieve the scientific objectives, it is necessary for the user to justify the various choices that were made41

when creating the Science Goal. For example, for a spectral line observation it must be shown that the requested
sensitivity and correlator setup will enable the line to be detected with sufficient signal to noise and that the
spectral resolution of the correlator mode, perhaps including spectral averaging, is appropriate.
From Cycle 2 onwards, the technical justification is no longer submitted as part of the PDF that contains thescientific case, but is instead created using a node in the Science Goal. This has been designed to help non-expert
users in particular in the writing of technical justifications by presenting various calculations based on the SG
contents e.g. the signal to noise ratio on the spectral line and the spectral dynamic range. For most projects, thetechnical justification node is split into four separate sections, each of which has a free-format text box in which
the relevant item must be justified. The four sections are:• Sensitivity: The OT presents a number of signal to noise calculations, depending on whether the SG istargeting spectral lines, continuua, or both. The discussion should convince the technical assessor thatthe line or continuum is being observed with sufficient signal to noise and that there enough spectral bins
across each spectral line to perform the scientific goals.
• Imaging: This should include an explanation of why the specific values of the angular resolution and largest
angular scale were requested and discuss whether the arrays selected by the OT will produce a suitable
image of the source. Images resulting from simulations that are relevant to this discussion should be
attached to the PDF containing the scientific justification.
• Correlator configuration: The main thing to discuss here is the spectral resolution that has been selected
and why. Spectral averaging should be mentioned if this has been requested.
• Choices to be justified: There are a number of setup options which, if selected, cause dedicated TJ text boxes
to appear. For example, single polarization will normally not be selected as this results in lower sensitivity.
However, for a given spectral window width, single polarization gives twice the number of channels andtherefore it can be useful when very high spectral resolution is required. As another example, mosaic
observations are normally conducted with the individual pointings separated by the Nyquist frequency, but
in survey observations where large sources are not being imaged, this is not necessary and larger separations
can be used. If this is the case, a brief discussion of the reasons why the non-Nyquist value was chosen canmake the job of the technical assessor a lot easier.
The exceptions are VLBI, phased-array and solar projects where fewer free-format text box are presented which
require information specific to those modes. As a sensitivity is not entered by the user in these cases, the OT
cannot display SNR calculations. In all cases, the justification texts must contain a minimum of 50 charactersand no more than 4000 are allowed.
Note that it is possible to copy and paste whole technical justifications from one Science Goal to another.
This can either be done via the Edit menu, or one can simply drag and drop the node into the destination SG.
Alternatively, the contents of individual text boxes can be copied and pasted.

5.4

Summary Information

Once the proposal is complete, various pieces of summary information can be obtained by right-clicking on therelevant node in the Project Tree. Of particular interest to most PIs is the amount of time required for the entire
project and that can be seen in all of the following summaries.
The summaries come in four varieties:• Science Goal summaries: These consist of a single page and show a lot of technical detail. These are, infact, mainly to be used by the technical assessors when reviewing the submitted proposal, but may also be
useful for the PI. They also include the contents of the Technical Justification node. Right-clicking on a
Science Goal will provide access to its summary whilst the same on the Planned Observing node can show
all Science Goal summaries together.
42• Proposal summary: This single page (effectively a “Cover Sheet”) consists of information entered in the
Proposal node (title, abstract, etc.) plus a very brief summary of the Science Goals. It also gives the total
time calculated for the proposal, separately for the 12-m Array (all configurations) and the ACA. The
names of the investigators are no longer shown.
• Whole proposal summary: This is a combination of the previous two summaries, plus the scientific justification PDF.
• Project time summary: Information of the total amount (and different types) of time, as well as data rates
and volumes can be viewed in the OT itself (as opposed to in a generated PDF) using this feature. Thisis available from the Toolbar, the Tool menu or by right-clicking on the project tree.

5.5

Proposal Validation

Before submitting the proposal to the ALMA archive, it is highly recommended that the validation procedure
be run in order to make sure that the proposal contains no errors. In fact, it is even more highly recommended
to validate regularly during proposal creation so as to spot mistakes as soon as possible. After a successful
validation and, optionally, having saved the work locally, the proposal can be submitted. Even if validation
is not validated by the user, it will be automatically performed at submission time. If this validation is not
successful, submission will fail.
For some large proposals, particularly those that include many sources that are spread over the sky, validation
can take significant amounts of time. In our tests, an OT with 3 GB of heap memory took approximately fiveminutes to validate the most complicated proposal we’ve ever encountered. This is a significant improvement
over the situation at Cycle 4 where it could take up to an hour, or not complete at all.

5.6

Proposal Submission

Proposal submission can only be performed by the PI. As all proposals are validated during submission, this may
take several minutes for larger and more complicated projects. After the project has been successfully submitted,
an email will be sent to all investigators and the PI will be asked to save the project to a local disk. Although it
is possible to only work on the archive copy, each submission overwrites the previous one. Therefore, maintaining
local copies can be useful in the event that reverting to a previous version becomes desirable. The OT will givea warning if submission of an older version of a project is attempted, just in case this was not the intention.

43

Figure 5.2: Example of the Time Estimate dialogue box. The user has entered a range of angular resolutions
and the OT has calculated that three possible configuration combinations fulfill the requested range and allow
the source LAS to be properly imaged. There are also two clusters.
44

Chapter 6

Phase 2 – Observing Program
Once a proposal has been approved, it is necessary to create the Scheduling Blocks that will be used to run
the observations at the telescope. The SBs are automatically generated from the information contained in the
Science Goals by observatory staff – this is no longer a task for the PI. Observatory staff can also build SBs fromscratch, or edit what generation has produced. SB generation continues to be improved and in most cases canbe relied upon, but special observing modes often require manual intervention.

6.1

Generation from Science Goals

6.1.1

Phase-2 Science Goals

Downloading an approved project from the archive will cause the Phase-1 Science Goals to be automaticallycopied over to the Program tab of the Project Tree and the project will open here. Technically speaking, thecopied Science Goals are Phase-2 Science Goals, but their visible content is absolutely identical to that of their
Phase-1 counterparts.
Note that PIs will no longer submit (or be able to edit) their Phase-2 SGs after they have been informed that
their project has been approved. The conversion from Phase 1 to Phase 2 is now undertaken by the observatory.
Any required changes to the contents of the SG will need to be communicated via a Helpdesk ticket.
Observatory staff can also create Phase-2 Science Goals from scratch, or create copies of existing ones. It iseven possible to copy a Phase-1 SG into Phase 2.

6.1.2

Scheduling Block Generation

All approved projects have their SBs generated by the observatory. Note that it is possible that one or more
SGs might be descoped by the proposal review process. If this is the case, SBs will not be generated from thedescoped SGs. Whether an SG has been descoped or not is shown in the General node of an SG.
The generated SBs (including the Observing Unit Sets in which they are contained) are attached below each
SG and cannot be edited by PIs, although the whole directory structure can be freely navigated and inspected.
Only observatory staff can edit any content below the Science Goal and indeed, no PI should greatly concern
themselves with the contents of the SBs. These contain a lot of technical information that the observatory will
ensure is set correctly before the observations are executed. Most vital is that the scientific aims encapsulated
in the SG are correct.
Observatory staff can generate SBs manually using the appropriate menu or toolbar options. Details of thecontents of the SBs can be found in Section 6.2.
45

6.2

Observing Program Structure

As has already been said, it is not recommended that SBs ever be created from scratch. However, observatory
staff can edit them without restriction and here we give here an overview of the their contents, in fact, the whole
structure of an Observing Program.
The structure of a typical Phase-2 project is shown in Figure 6.1 and shows each of the required entities:
Observing Unit Sets, Sheduling Blocks, Targets, Resources and Observing Groups.

6.2.1

Observing Unit Sets

The OUS is a fundamental part of the construction of an SB and, as explained in Section 3.7, a fixed OUS
nested structure has been agreed. This is automatically produced during SB generation and should also always
be followed when creating SBs manually. If desired, the entire contents of all OUSs (and their associated SBs)
can be protected from editing by activating OUS Write Protection from the Advanced tab of the Preferences
menu.
If a Phase-2 program is being constructed manually i.e. without a pre-defined Science Goal, the first step isto create a top-level OUS (usually refered to as the Science Goal OUS) in the Program tab of the Project Tree.
This is done via the Science Plan folder, either by using the right-mouse menu or the toolbar icon. A new Special
Observing Program folder will be created, and within this, the top-level OUS. Group and Member OUSs should
then follow.
Clicking on an OUS will reveal its Form editor which contains a number of panels, very few of which are
actually used at this time. Probably the only real option at the moment is to set the OUS name to something
useful.

6.2.2

Scheduling Blocks

Scheduling Blocks contain most of the information that is required to run the observations and are therefore very
complicated. The remainder of this chapter will describe in detail the contents of an SB and how the various
components fit together to produce a valid observation. Indeed, the OT’s validation function is also available at
Phase 2 and should be routinely checked to ensure that the project will submit without problems to the ALMA
archive. As usual, submission will not be possible for any project that does not pass validation.
When clicking on the Scheduling Block node in the Project tree, the SB’s Form editor will appear in the
Editors pane. It consists of eight panels, the first three of which are very similar to those in the OUS, but again,
very little of this information is currently used. A number of panels will eventually influence the automatic
scheduling of the observations, but ALMA does not yet have a mature scheduling system and so these fields arealso not currently read.
Of the remaining panels, the most relevant ones are SchedBlock and Advanced Parameters. SchedBlockgives the name of the observing mode and states which observing script e.g. StandardInterferometery.py, will
be used to actually run the observations. It also gives the number of executions that are allowed for this SB,
which is often set to a large number as executions above this number are not allowed. Advanced Parameters isparticularly relevant as a number of parameters can be defined here which will be read by the observing scripte.g. to tell the script that more than one phase calibrator has been defined and both should be observed.

6.2.3

Targets

Within the SB, a series of observations (the ultimate order of which will be determined by the observing script)
are actually constructed out of Targets. These define an observation of a given source and are close to theconcept of a scan, each of which might be repeated multiple times, most obviously for the science target andphase calibrator. A Target is constructed out of a Field Source, an Instrument Setup and an Observing Parameter– these are in turn refered to as Resources and are stored in a Resources folder.
46

Figure 6.1: An example of a typical project structure. This contains a single Group OUS, but multiple Memeber
OUSs for 12-m, 7-m and TP SBs. All but the first SB have had their structure hidden.

47

The Targets themselves reside in their own folder and clicking on this will reveal a table listing various
properties of each (Figure 6.2). Clicking on a Target will highlight the Resources that have been used to create
it and will also show the Forms editors for each Resource together in the Editors panel. This takes up a lot of
space and the OT should normally have its size maximised. A Target is created by either right-clicking on the
SB or Targets folder and selecting the appropriate option, or via the Edit menu.

Figure 6.2: Summary table shown when clicking on the Target folder. Each Target is shown along with somekey properties.
Freshly-created Targets are initially empty and their Resources need to be added. This can be done in two
different ways, the most convenient of which is to view the Target via the Editors window. This will show threepanels, for each of which an already defined Resource can be reused, or a new Resource created. If the latter ischosen, the newly-created Resource will need to be opened and the necessary information filled in. The second
method is to attach and detach the Resources via right-clicking on the Target. This brings up a dialogue boxthat shows all the pre-existing Resources in a column on the left, three of which need to be moved into the rightcolumn. Resources can also be independently created by clicking on the various Resource folders.
Each Target can only contain a single Field Source and Instrument Setup. It is technically possible to attach
multiple Observing Parameters – some sources might be used for multiple calibrations for example – but thisshould not be done as the observing scripts cannot currently deal with this.
In order for a project to validate, it is necessary that one of the Targets be marked as the Representative
Target – this is indicated with a [R] at the beginning of the Target’s name. Note also that the names cannot
be changed by the user as they follow a fixed format incorporating the source name and the observing intent (asset by the Observing Parameter). Targets without the three necessary Resources will cause a validation error.

6.2.4

Resources

A Resources folder contains three sub-folders, each of which contains the various instances of the individual
Resources required to create a Target i.e. Field Sources, Instrument Setups and Observing Parameters. Clicking
on each of these sub-folders will reveal a summary table of the currently-defined Resources and right-clicking
will allow new Resources to be added.
6.2.4.1

Field Source

A Field Source form looks very similar to the Field Setup form of a Science Goal (Section 5.3.2), the source
position, proper motions, etc., being displayed in the first panel. However, where in a Science Goal it is only
possible to define a rectangular mapping area or a set of single pointings, more options exist within an SB.
Reference (offset) positions can be defined e.g. for atmospheric calibrations, and a number of field patterns canbe selected.
An extremely important difference between the two is that within an SB it is possible to define a Field Source
query (Figure 6.3). Here, instead of a specific source definition, this conducts a cone search around a positionat the time of observation using the ALMA calibrator database. This is extremely useful as, at the time of SB
creation, it is not normally known when the observations will be observed and therefore the positions of planets
relative to the science target and the brightness of most calibrators are also highly uncertain. Any Field Source
can be converted to a query by ticking the box in the Query Status (topmost) panel, and vice versa. In addition,
this interface can be used to convert a dynamic calibrator (query) to a fixed calibrator by using a very similarinterface to the Calibrator Selection Tool that is described in Section 7.5.
Reference positions are used during observations in order to integrate on a patch of sky that is usually devoid48

Figure 6.3: Example of the query interface for a Field Source. This is for the phase calibrator and the source
coordinates have been entered automatically by the generation. Unticking the button at the top would return
this form to the fixed source format used in a Science Goal. The bar at the bottom also allows a fixed source tobe chosen from the ALMA calibrator database.
of significant emission. When measuring Tsys , for example, a bright source will significantly add to the power
detected by the antenna and increase the measured Tsys . It is therefore usual to offset the antenna by a few
arcmin in order to avoid the source. When observing Jovian or Saturnian satellites, the offset should be madebigger so as to ensure that the planet isn’t observed by accident. Single-dish OTF mapping also requires anoffset position so that the effects of changing atmospheric emission during the observations can be calibrated out.
The ability to add a reference position to a Field Source is not possible for all observing intents e.g. pointing.
The scanning used for the offset positions can currently only be done using equatorial i.e. J2000 and horizon
coordinates. There are long-term plans to add Galactic to the list of supported systems. It does not appear thatabsolute offset coordinates are currently supported.
Of the various field patterns that it is possible to define, not all are currently supported. “Point” and“rectangle” are the most commonly used options and “fill” is now used for fast mapping of the Sun. The inputs
for all options lie in the subsequent panel and change depending on which pattern is picked. Any observation thatinvolves integrating when the telescope is not moving i.e. not OTF mapping, should use the point definitions.
Each position in the table will be observed sequentially by the observing script, each for the subscan duration,
before the total requested integration time for the source is reached. If necessary, the script will return to thefirst source in the list and continue. As it is usually the case that equal sensitivity is required per pointing, thetotal integration time should be set so as to ensure that each pointing is observed the same number of times.
For SBs that have been generated from a Science Goal, the original rectangle definition will have been converted
to a list of pointings for the ALMA 12-m and ACA 7-m antennas. Similarly, it is possible to convert a rectangle
definition in the SB to multiple pointings.

6.2.4.2

Instrument Setup

By far the most complicated entity within an SB is the Instrument Setup. It defines a large number of parameters
to do with the tuning and correlator configuration and must do this for both the 64-input and ACA Correlators,
the parameters for which are not identical. As a consequence, it is beyond the scope of this document to describe
all the entry fields in detail, although concise descriptions of each can be found in the ALMA OT Reference
Manual. Help is also available from the ALMA Technical Handbook and the OT itself through its tooltips andvalidation. Finally, creating an Instrument Setup from scratch will set many of the parameters to reasonable
defaults.
49

The ultimate task of the Instrument Setup is to define the spectral windows that actually constitute thescientific data product i.e. their central frequencies, bandwidths, spectral resolution, etc. There are a large
number of restrictions in how spectral windows can be arranged and, as the OT is aware of these, automatic
generation from a Science Goal should always produce a complete Instrument Setup that requires very little
editing. The Visual Spectral Editor (Chapter 9 provides invaluable guidance when creating setups, as it shows
the spectral windows, basebands and sidebands in a graphical format.
Starting at the top of the Instrument Setup form, the various components will now be briefly described.
Fortunately, the ACA and 64-input Correlator inputs are similar enough that they can be dealt with together.
The first panel of any real interest is the third one as it defines various time parameters – these are the integration
duration (separation between data points in the science data) and the channel average duration (the same, but
for the channel average regions – see below). Additionally, for the 64-input Correlator, a dump duration mustalso be defined. Of the Walsh function options, 180-deg switching is usually enabled, but 90-degree switching isonly used when separating the sidebands at bands 9 and 10.
Next are the basebands, up to four of which can be created. Each defines a 2 GHz-wide signal that is
subsequently sampled by the spectral windows that constitute the actual data. The main user inputs are thedesired centre frequency of the baseband and the Doppler Reference. That the frequency is desired is, andapparently continues to be, emphasised because in general the actual observed frequency will differ from thatrequested, mainly because the value of the second local oscillator (LO2) is quantised. One notable exception
is the creation of only one baseband as here the unquantised tuning ability of LO1 can be fully utilised. The
actual frequencies are displayed after a tuning solution is requested using the “Calculate LOs 1 and 2” button(something that should always be done). It is possible to prioritise different basebands in the tuning solution
using weights between 0 and 100, but these are probably always left at the default values of 100.
During the tuning process, the Doppler Reference tells the OT (and the telescope control system) how
to interpret the baseband frequencies that are being passed to it and has three options: topo, rest and lsrk.
Topocentric means that any source velocity relative to the telescope is ignored and therefore that the requested
frequencies are those that will be observed, subject to any of the quantisation issues mentioned in the previous
paragraph. This is commonly used for continuum and some calibration observations, such as pointing. Probably
the most common choice will be to enter rest frequencies, the source velocity in this case being used to calculate
the observed frequencies in the frame associated with the velocity e.g. lsrk, barycentric, heliocentric. However, as
the OT does not know when the SB is going to be observed, it is not possible for it to make the final corrections
for Earth motion relative to this frame. Similarly, the final choice (lsrk) assumes that the frequencies are alreadyreferenced to the local kinematic standard of rest, but that the final Earth Doppler corrections need to be made(the source velocity is therefore ignored, as with topo).
That the Earth Doppler corrections can only be made at run time therefore means that, if Doppler Reference
has been set to rest or lsrk, the frequencies in the OT are generally not those that will be used during SB
execution. Therefore, it is possible that, although the OT can find a valid tuning solution, this might not be
the case when the SB is actually run, either because a baseband is very close to the edge of a band, or because
basebands are close to the edges of their sideband (a negative velocity correction would push the basebands awayfrom each other and possibly exceed the total width of the sideband, which is not allowed). As a check on thispossibility, the OT will not only calculate a tuning for the requested source velocity, but also for this velocity
plus and minus 32 km/s (unless the Doppler Reference is lsrk in which case the velocity is taken as zero). If theadditional velocity component results in no valid tuning solution being found, the OT will issue a warning.
Lastly, spectral windows must be added to the basebands. A fundamental property of a baseband is thecorrelator mode that will be used to produce its spectral windows. A different mode can be chosen for eachbaseband by setting a bandwidth, number of channels, polarization products and, for the 64-input Correlator
only, the number of bits and whether the data are sampled at Nyquist or twice-Nyquist rate. Currently, only
2-bit Nyquist sampling is allowed, but the other parameters are pretty flexible. The other parameters of aspectral window include the smoothing function to apply (Hanning is the default) and the correlator averaging
factor. It is highly recommended to use the latter as this greatly reduces the data rate (which is reported for eachbaseband – the summed value is also given) and volume. ALMA is designed to operate with an average data
rate of 6 MB/s and projects that require much more than this should be particuarly explored to see if spectral
averaging is appropriate. As well as the average data rate limitation, there is also an absolute maximum thatis allowed (70 MB/s) and this will cause a validation error if exceeded. Up to 10 spectral averaging regions can
50also be defined – these define sub-windows that are averaged to a single channel and also appear in the ASDM.
The position of the spectral windows within the baseband is set by the Center Offset Frequency, where
3000 MHz refers to the centre of the baseband. This value is quantised and must be a multiple of 30.517578125 kHz
for the 64-input Correlator and, for the ACA Correlator, a value which depends on the correlator mode thathas been selected. Fortunately, the OT provides a button that will adjust an entry to the nearest legal value.
Values that place any part of the spectral window outside of the 2 GHz-wide baseband are not allowed. As withbasebands, the spectral windows are summarised in an editable table, but the complete parameter set can only
be accessed from tabs below.
Both correlators are designed such that there can be multiple spectral windows per baseband – these use
the so-called multi-region and multi-resolution modes. The latter is yet to be commissioned and therefore every
spw in a baseband must currently have the same spectral resolution (before any spectral averaging is taken into
account).
6.2.4.3

Observing Parameters

The final Resource essentially ascribes to the Target an “intent” i.e. it states the purpose of the Target in
the observation. Most of the possible intents are for calibration and a large number are available (amplitude,
bandpass, phase, etc.). Also available is the Resource for observing the science target. In general, each has adifferent set of parameters. All calibrators include a cycle time which instructs the observing script to repeat thescan after that much time has elapsed since the last observation of that Target. In this way it is not necessary
to define a Target for e.g. each phase calibrator scan – the observing script will take care of this.

Figure 6.4: Examples of the Observing Parameters form for a science target (left) and a phase calibrator (right).
The tabs at the top show all the observing intents that could be created.
The various integration times require some explanation. Most calibrators also define a default integration
time which states how long an observation of a particular Target should last i.e. each scan of a phase calibrator
Target will have this duration. The qualifier “default” recognises that there are other parameters (not currently
used) that request a specific accuracy of calibration and that this might require more time depending on theconditions at the time of observation. Pointing calibrations are a little different in that the time spent is reallyset by the subscan duration – this defines how long is spent observing each position within the pointing pattern.
For other calibrators and the science target, the subscan duration sets the longest interval that the telescope51

should continuously integrate for before writing to disk. Its maximum length is essentially set by memory
issues and, for a commonly-used value of ∼30 seconds, a 1-min phase calibrator scan will contain two subscans.
Unfortunately, the subscan must be a multiple of the correlator’s dump duration and this is often an awkward
number such as 1.008 sec. Fortunately, the OT provides a button that will convert a round number, such as
30 sec, to the nearest multiple e.g. for a dump duration of 1.008 sec, a subscan duration of 30.24 sec would
result. There is a software overhead associated with each subscan so their number should be minimised. Whensetting integration times and subscan durations, it is important to realise that once a subscan has started, it will
run to completion. Therefore, a subscan duration of 30.24 sec and an (admittedly unlikely) integration durationof 61 sec will cause three subscans to be executed and result in 50% more data than expected. For scienceobservations the subscan duration also sets the amount of time spent observing each position within a mosaic
pattern or each strip of an OTF raster scan.
For the science Observing Parameter, there is also an integration time parameter, but unlike the calibrator
intents, this refers to the total time observed over the course of the SB’s execution, and not to the length ofindividual visits to that source. Therefore, an SB will continue until each science target in an SB has been
observed for the requested amount of time. Also contained within the science Observing Parameter are fields(desired sensitivity, Representative Frequency and Representative Bandwidth) that could potentially be usedby the scheduling software to derive the time required at the time of observation. This is useful because theintegration time requested will normally be an estimate based on a fixed value of the PWV – observations will
rarely be carried out in these exact conditions, not least because the PWV can be extremely variable. However,these parameters are not yet used and so a definite time must currently be provided.
Whilst the OT provides a lot of control information regarding the execution of a SB, it is the observing
script that ultimately decides what should be observed when. For example, the script may decide that, eventhough an amplitude calibration scan is included in the SB, this is not necessary due to one taken during aprevious execution of the SB remaining valid. The Observing Parameters make it possible though to override
this behaviour and force an execution of a calibrator. Similarly, an atmospheric calibration scan can be forced
for every execution of a Target.

6.2.5

Observing Groups

In order for a Target to be observed, it must be placed into an Observing Group (OG). These give a user more
control over how an observation will be conducted as each OG is observed once in the order that it appears.
Within each OG there is also some ordering in that, if there are multiple versions of a particular calibration
intent (and yet only one will be observed) the observing script will give precedence to the first instance of thatcalibrator type that it finds within the OG. The script though does set the order of each calibrator type, withbandpass preceding amplitude regardless of their order in the OG.
Group 1 is used for calibrators and should normally include Targets for bandpass and amplitude (flux) plus
associated pointing observations. Group 2 should contain the science targets as well as the phase calibrators.
Sources are placed into groups by clicking on the OG folder and copying the defined Targets listed in the left-handcolumn into that on the right (Figure 6.5). If the order of the OGs needs to be changed, this can be done usinga panel in the top node of the SB.
Included in the table is a column for marking which science source should be used as the Doppler Target.
This tells the telescope control system which source’s velocity to use when calculating the observed frequencies
and thus the tuning setup. Whichever source is selected is marked with a [D] in the Project Tree.

52

Figure 6.5: The Observing Group editor. The table on the left lists the already-defined Targets that could beplaced into this Observing Group, this being done by moving them into the table on the right. The order of thechosen Targets can be changed using the up and down arrows and are removed from the Group via deletion.

53

54

Chapter 7

Tools
7.1

The ALMA Template Library

The ALMA Template Library (Figure 7.1) provides a set of Science Goals that cover different proposal types.
Once opened (via the File or View menus), the Science Goals within can be inspected and sections copied andpasted (or dragged and dropped) into a proposal’s Science Goal. Alternatively, a complete Science Goal can becopied into a proposal and then edited as normal. A user’s own projects can also be used as templates and areopened as such (in read-only mode) from the File menu.
The Template Library has not been updated since Cycle 5 and as such is currently disabled.

Figure 7.1: The ALMA Template Library.

7.2

Sensitivity Calculator

The ALMA Sensitivity Calculator is most easily accessed via the obvious icon in the toolbar. It will calculate
the time required to reach a certain sensitivity, or vice versa, and can be separately configured for the 12-m, 7-m
and TP Arrays. An identical version is available as an applet in the Science Portal.
After having defined the input parameters (Observing Frequency, Bandwidth, Water Vapour, etc.) in thecommon area in the upper part of the interface, using the number of antennas and required sensitivity, the tool
now calculates the integration times for the ALMA 12-m Array, the ACA 7-m Array and the ACA Total Power
55

Figure 7.2: The ALMA Sensitivity Calculator.
Array. Note that the numbers of antennas will be set to their default values for the present cycle. The tool also
provides the inverse facility, i.e. estimating the sensitivities given an input integration time. The layout of the
Calculator is displayed in Figure 7.2.
In the GUI, the user has to specify the bandwidth per polarisation. Multiplying this number by the numberof polarizations gives the effective bandwidth. Sensitivity is treated as a flux density for point source detection
if the unit is either Jy or mJy, and as a brightness temperature of an extended source if the unit is either K or
mK. Therefore, an angular resolution must be entered if temperature units are to be used. Note that systemtemperature and atmospheric parameters are displayed for the specified frequency. There are 7 octile choices(0.472 mm, 0.658 mm, 0.913 mm, 1.262 mm, 1.796 mm, 2.748 mm, and 5.186 mm) for the Precipitable Water
Vapour (PWV) and these can either be selected manually, or chosen automatically by the calculator. It is very
important to realise that changing the PWV from its default value in the ASC has no effect on the OT’s time
estimate for your project. This uses the ASC code, but always chooses the automatic PWV option.
When the user enters a flux density sensitivity, a brightness temperature equivalent to the flux density value
is also displayed, if an angular resolution has been entered. Conversely, when a surface brightness is entered,a flux density equivalent to the surface brightness value is displayed. Finally, Integration Time Unit Option
allows a choice between the calculator automatically choosing an appropriate unit (recommended) or specificuser-defined units.
A much more detailed guide to the ALMA Sensitivity Calculator can be found in the ALMA TechnicalHandbook.

7.3

Spectral Line Picker

This tool allows a user to search the Splatalogue1 , a database containing millions of spectral-line transitions. A
subset of the Splatalogue is packaged with the Observing Tool, which should be sufficient to select some of themost commonly targeted transitions, even when working offline. If network connectivity is available, access tothe complete catalogue becomes possible using the online search functionality of the tool.
The tool is available either when creating a Spectral Setup in a Science Goal (see Section 5.3.3) or an
Instrument Setup in a Scheduling Block (Section 6.2.4.2). In both cases, the selected transitions can be used
to define observed frequencies as well as being available to overlay on the Visual Spectral Editor. In addition, a
1 https://splatalogue.online

56

Figure 7.3: The ALMA Spectral Line Picker.

separate instance of the tool on the spectral-setup page of a Science Goal allows rest frequencies to be defined(Section 5.3.3.12).
When the transition selector dialogue box is launched, the offline spectral line catalogue is displayed and everytransition in the catalogue is available for selection. Specific transitions can be located by using the controls in
the left-hand panel to set your search criteria. String matches to the transition name or description are possible,
as is matching by frequency and ALMA instrument band by dragging the range sliders or using the frequency
input boxes. The string matching is not standard: a bare piece of text will only match the beginning of a string,but if a wildcard (’*’) is placed at the beginning, the text will match anywhere (and not just at the end). Notethat the frequency slider refers to sky frequencies (these are calculated using the velocity of the first source in the
Science Goal). Double-clicking on the column headings will cause the table to be sorted according to the values
in that column (large triangle) and clicking a subsequent column will cause a secondary sort (small triangle).
The triangles indicate the direction of the sort and subsequent single clicks will reverse this.
If a desired line cannot be found in the offline catalogue, it may exist in the more extensive online catalogue.
The online catalogue can be queried by clicking the “Find More...” button; the query will use the species filter
and the frequency limits only and wildcards are not allowed. The results of the query will be added to
the list of selectable transitions, and will persist as part of the offline database for the rest of theobserving tool session.
Having located a target transition, it can be copied into the table of selected transitions by selecting it andclicking the obvious button, or simply by double-clicking. When creating a spectral setup, only one line canbe chosen at a time. However, when overlaying, multiple lines can be copied simultaneously into, and removed
from, the table of selected transitions, by highlighting multiple rows. Closing the tool using the “OK” button
will cause the selected frequencies to be entered into the OT.
An important part of the Line Picker is its ability to only allow lines to be selected that can be observed
together in a single tuning solution. This now has two modes – one which shows all lines that could be observed
given the currently defined spws and another which only shows those lines lying within the spws. When adding
spws, note that this feature makes no allowance for the width of a spectral line so it is important to check thatall spectral lines are properly covered by their spectral window.
Note that the filter which looks for potential lines has two layers, one for sidebands and one for basebands.
Let’s deal with those in turn. The baseband filter only considers those lines which might fit into the currently
defined 2-GHz-wide baseband. So, if a spw has already been defined (either with the SLP or manually), using
the SLP again to add lines to the same baseband will only show those which will fit into all possible locations of
the 2-GHz-wide baseband.
57

If the SLP is instead used to search for transitions in another, empty, baseband, there is much more freedom
as to where a line could potentially be placed and a tuning solution be found. This is where the sideband filter
comes into play. For example, if a line has been defined somewhere near the middle of a band in one baseband,
it could potentially lie in either the upper or lower sideband (the OT uses USB as a default where possible). The
SLP considers both scenarios and will show all transitions that might lie in the same sideband, or in the othersideband i.e. LSB if the original line would be in USB and vice versa.
Absent is a filter to ensure that basebands for 2SB receivers (Bands 3–8) are only created in pairs. For thesereceivers both baseband pairs must either be in the same sideband or one can go in LSB and the other in USB.
This may be added in the future.

7.4

Archive Search Tool

In order to retrieve a project from the ALMA archive, the OT provides an Archive Search Tool. This is started
most conveniently from the toolbar, but can also be accessed from the File menu. This brings up a fairly
straightforward dialogue box that is shown in Figure 7.4. Projects can be searched for in various ways, forexample using the project code or the user’s ALMA username. If a user’s credentials have already been enteredinto the Preferences menu, there will also exist shortcuts to show all the projects belonging to the current user
and, if the user has sufficient privileges, all users. Only one search field is active at any one time and all fields
are case-insensitive and perform partial matches.

Figure 7.4: The Project Finder dialogue box for searching for projects in the ALMA archive.

7.5

Calibrator Selection Tool

Calibrators can be added to both Phase-1 proposals and Phase-2 programs using a standard calibrator searchtool, although the details of how this works differs slightly in the two cases. Two catalogues can be searched: thefull ALMA calibrator database that is searched online, or a much more limited version (smaller and not so up-todate) that is contained within the OT and thus can be searched even in the absence of a network connection. The
former is of course recommended and is the default. The internal catalogue is basically a snapshot of the SMA
catalogue taken a few years ago and contains measurements at 3, 1 and 0.87 mm. The ALMA catalogue also
contains these SMA data, but also VLA measurements at lower frequencies. Most importantly, new measurements
taken with ALMA are now constantly being added.
The search interface is shown in Figure 7.5. Calibrators are found by matching a set of search criteria,
consisting of the centre position and radius of a cone search and a set of minimum and maximum values for theflux as well as the frequency over which this is valid. Criteria are enabled by the presence of non-zero values anda symbol next to the field will give a visual sign of whether a particular feature is enabled or not. Searching withall filters disabled will return the entire catalogue! A final field sets how many matches will be returned. From
the total number of sources that match the search criteria, these will always be those with the lowest values ofRight Ascension.
Once the search constraints have been entered, either the ALMA online catalogue or the internal OT catalogue
58

Figure 7.5: The Calibrator Selection Tool as used in the Calibration Setup of Science Goal. A search has been
made for all calibrators within a 10-degree radius of a source position, that have a flux greater than 500 mJy in
ALMA Band 3.
can be searched by clicking the “Submit Query” button. As with many other tables in the OT, the results can besorted by clicking on a column header; the direction of the arrow indicates the sort order which can be reversedwith subsequent clicks. Secondary sorts are not possible. Alternatively, the OT’s list of non-sidereal calibrators
can be displayed.
The calibrator tool can be accessed in a number of ways. At Phase 1, it is only available when defining auser-defined calibration in a Science Goal. However, at Phase 2, it is also available from the Tool menu and fromwithin a Field Source definition. In all cases, the search interface itself works identically, although the details of
how a chosen source is used vary. Please consult the relevant sections of this manual for more information.

7.6

LO Configuration Tool

The LO Configuration tool is available from the Tools menu, but only if privileged operations are enabled. It
is an interface to the algorithms used by the OT to generate tuning solutions. At its most basic, the centre
frequencies of up to four basebands can be entered and a tuning solution (LO1 and LO2 frequencies) requested.
Figure 7.6 demonstrates the use of this tool to derive a tuning solution for three basebands at Band 9. This tool
only calculates the frequencies of basebands – the LO4 frequencies which determine where within the basebands
the spectral windows lie must be separately calculated.

59

Figure 7.6: The LO Configuration Tool. Three Band-9 basebands have been requested with the tuning results
shown at the bottom.

60

Chapter 8

The Visual Spatial Editor
The Visual Spatial Editor allows an image of the source that you wish to image to be loaded and can subsequently
be used to determine where the telescopes should point, either by defining individual pointings or rectangularmapping areas. The information entered here will also appear in the Forms Editor that always accompanies theSpatial Editor i.e. it is not necessary to use the Spatial Editor to define any observation with ALMA, although
it will greatly aid in setting up some observations.
The Spatial Editor is enabled by selecting the Spatial tab at the top of the Forms Editor when either of thefollowing are selected:• the Field Setup node of a Phase-1 or Phase-2 Science Goal (selecting the Science Goal summary view will
also allow the Spatial Editor to be viewed)• a Field Source in an SB (selecting a Field Source’s Target will also allow the Spatial Editor to be viewed).
Whilst the Spatial Editor is identical in each case, the Forms Editor is somewhat different and is explained indetail in Section 5.3.2 (Science Goal) and Section 6.2.4.1 (Scheduling Block).
Note that use of the Spatial Editor can be enabled by default using the Preferences menu i.e. it will always
be shown when a Field Setup or Field Source is selected.

8.1

Overview of the Graphical Interface

The Spatial Editor’s graphical interface (Figure 8.1) uses libraries provided by the JSky project1 and is dominatedby a window for displaying images (in FITS format). In addition to this, there are also smaller windows fordisplaying the entire image (including a yellow square which indicates which portion of the entire image isdisplayed in the main window; this can be moved with the mouse) and another that shows the zoomed part ofthe image that is centred on the cursor position in the main window. Display of these is optional. The colourbar
at the very bottom of the image can be used to change the image contrast by dragging the mouse within it –the contrast can be reset to the default with a right-click.
Above the image display there is a toolbar that can be used for various operations including loading andsaving images, manipulating source and target positions and for setting the intensity cut level in the display.
Zooming controls and positional information are located directly below the image window.
Below the image display and its menu and control buttons, the FOV Parameters and Image Query panels
are visible (Figure 8.2). The former displays the value of the Representative Frequency (taking into account thesource velocity) and allows the user to select which interferometric array’s pointings to display, if there is a choicei.e. the 12- and 7-m arrays are required. Changing the source in the Forms Editor will change the Representative
Frequency to the value appropriate to that source. The Image Query panel allows the image server and the sizeof the retrieved image to be specified.
1 http://jsky.sourceforge.net/

61

A further feature of the graphical interface is the ability to measure the distance between two points within
the image by right-clicking and dragging the mouse (Figure 8.1).

Figure 8.1: An example of the image display area on the Visual Spatial Editor. This shows a pointed mosaic
observation of the outer reaches of NGC 253, the mosaic pointings having been automatically created based ona user-defined rectangle (green). The x-shaped cross at the centre marks the position of the coordinates given in
the Forms Editor. As this is an observation that requires the ACA, also shown is the rectangular area (in blue)that will be mapped by the Total Power Array. Also shown is the ruler for measuring distances between points
in the image.

8.2

Creating a Field Definition

An image can be loaded in one of two ways, either by loading a local one from disk using the image display’s
toolbar, or by querying an image server, a large number of which are available through a drop-down menu. Ifquerying a server, the image will be centred on the coordinates entered in the Forms Editor. These are indicatedon the map by a green x-shaped cross which will move if the coordinates are changed. As of Cycle 6, Galactic
coordinates are supported.
Once an image has been loaded, if any pointings or a rectangle were previously defined in the Forms Editor,
they will appear on the image and can be edited with the mouse. At the time of loading an image, the typeof field definition must already have been chosen, either a rectangular area or multiple pointings (the latter by
default). It is possible to change the definition using the Spatial Editor by clicking on the opposite definition on
the toolbar i.e. by adding a single pointing when a rectangle has already been defined. A warning will be issued
at this stage as the previous definition (size and orientation of rectangle, positions of all pointings) will be lost.
62

Figure 8.2: The FOV Parameters and Image Query panels in the Visual Spatial Editor.
As this implies, it is not possible to create a field definition that contains a mixture of single pointings and arectangle.
An important part of the Spatial Editor is the ability to display the pointings for either the 12- or 7-m arrays
together with their antenna beamsizes. For this to be possible though, the Representative Frequency must havealready been defined in the Science Goal’s Spectral Setup. Therefore, it is recommended that this section becompleted before using the Spatial Editor.

8.2.1

Single Pointings

Multiple instances of single pointings can be added to the field definition by using the “Add a FOV” button on
the toolbar and then clicking at the position in the image where the antenna should point – this must be clicked
every time a pointing is to be added. For your convenience, a single pointing is created by default at zero offset
from the source coordinates. Once defined, pointings can be moved using the mouse or deleted. Clicking on apointing will cause its background to become opaque - this indicates that this pointing has been selected andcan, for example, be deleted using the scissors icon in the toolbar or moved by being dragged with the mouse.
More than one pointing can be selected at any one time, either by using the rectangular selection button in the
toolbar, or by holding down the Ctrl key whilst clicking on each pointing in turn. A subsequent dragging ordelete operation will then apply to all pointings.
The pointings defined in the Spatial Editor are displayed in the Forms Editor where they can be edited ordeleted.

8.2.2

Rectangular Areas

Instead of one or more single pointings, it is possible to define a single rectangular area. This is used toautomatically calculate a mosaic of pointings based on the antenna spacing that is entered in the Forms Editor.
This is usually set to some fraction of the antenna beamsize and Nyquist is the appropriate choice in nearly allcases and also the default. Once a rectangle has been defined, either with the mouse or with the fields in theForms Editor, it can be manipulated further by clicking on the coloured boxes - the green box rotates and theblue boxes resize. Furthermore, the rectangle can be moved by clicking and dragging anywhere in its vicinity.
The mosaic pattern is not currently drawn by default and so the appropriate button in the toolbar must be
selected. The mosaic pattern for either the 12-m or 7-m Array can be selected and the number of pointings will
be displayed in the Forms Editor - as the spacing is usually a function of antenna beamsize, the mosaic patterns
will therefore be different for the two arrays. For Phase-I proposals, it is probable that a limit on the number ofpointings has been set for the current ALMA cycle and defining too many will result in a validation error thatwill prevent the project being submitted.
If the ACA has been selected, also displayed will be a turquoise rectangle that is a little larger than theuser-defined rectangle. This indicates the area that will be mapped by the ACA Total Power Array and isnon-editable.
638.2.3

Offset Versus Absolute Coordinates

When a pointing area is created using the Spatial Editor, its coordinates are interpreted by the OT as an absolute
position (R.A. and Dec.) or as an offset from the source coordinates, depending on what is selected in the Forms
Editor at the time of creation. Because pointing areas are being added with the mouse, which is chosen is not
terribly important and subsequently changing from one to another will convert all positions to the new system.
However, if the source coordinate is changed, the outcome depends crucially on which is currently selected,
namely that offset positions will move within the image whilst absolute positions will not. Be very careful whenchanging the source coordinate after setting up a field definition with the Spatial Editor!

64

Chapter 9

The Visual Spectral Editor
The Visual Spectral Editor allows the spectral windows that are defined by the user to be viewed in a graphicalenvironment that contains a number of aids to their placement, particularly the atmospheric transmission andthe receiver/correlator configuration (receiver bands, sidebands, etc.). The spectral window information enteredby the user is also visible as the Forms Editor always accompanies the Spectral Editor i.e. it is not necessary to
use the Spectral Editor to define any observation with ALMA, although it will greatly aid in setting up someobservations. It is strongly recommended that a spectral setup is always checked in the Visual Spectral Editor.
The Spectral Editor is enabled by selecting the Spectral tab at the top of the Forms Editor when either ofthe following are selected:• the Spectral Setup node of a Phase-1 or Phase-2 Science Goal (selecting the Science Goal summary view
will also allow the Spectral Editor to be viewed)• an Instrument Setup in an SB (selecting a Instrument Setup’s Target will also allow the Spectral Editor to
be viewed).
The Forms Editor for spectral setups is explained in detail in Section 5.3.3 (Science Goal) and Section 6.2.4.2(Scheduling Block).
Note that use of the Spectral Editor can be enabled by default using the Preferences menu i.e. it will always
be shown when a Spectral Setup or an Instrument Setup is selected.

9.1

Overview of the Graphical Interface

The Spectral Editor’s graphical interface consists of two frequency axes, one above the other, with the spacein between used to display various features of interest. The two axes themselves show the features in observed
and rest frequencies, depending on the source velocity. The display can be zoomed using mouse clicks (left-click:zoom in, right-click: zoom out) or the scroll wheel, the zoom being centred at the location of the mouse pointer(magnifying glass symbol). Once the display has been zoomed, it can be panned by grabbing one of the horizontal
green bars that appear whenever the mouse is somewhere within the graphical area. Additional zooming andpanning controls are located below the graph, as well as a number of other controls.
Just below the observed frequency axis are hatched areas that show the available receiver bands. These aredisplayed in grey, apart from the currently-selected receiver band which is coloured blue (and doubly, comparedto singly, hatched). The upper, wider part of the hatched area shows the full range of frequencies that can beobserved using a band whilst a narrower rectangle below this shows the allowed range of the first local oscillator(LO1).
A prominent feature of the graphical interface is the transmission curve. This shows how much of the radiationfrom the source is actually received at the telescope and is calculated using the Atmospheric Transmission at65

Microwaves (ATM) code1 that is also used in the ALMA Sensitivity Calculator and for the OT time estimates.
Years of monitoring have been used to determine the characteristic octiles of precipitable water vapour (PWV)
at the ALMA site and the transmission curve corresponding to each can be selected manually, or the OT can
automatically display the appropriate one. The latter is recommended as it is this value of PWV (or a very
similar one) that will be used to trigger the observation of a project, based upon the spectral windows thathave been defined in the Forms Editor, specifically by the Representative Frequency. Changing the displayedtransmission curve is for experimentation only as it will not affect the conditions assumed for the observations
and hence the OT’s time estimates!
It is also possible to display spectral lines using the Spectral Line Picker which is described in detail in
Section 7.3.

9.2

Viewing a Spectral Setup

The main purpose of the Spectral Editor is to allow the spectral setup to be viewed against the background of
the transmission curve and available spectral lines. The spectral windows themselves must be defined using theForms Editor as it is not possible do this using the graphical interface. These in turn are used by the OT tocalculate a tuning solution that sets the positions of the basebands and sidebands. Together with the spectral
windows, these can be viewed in the Spectral Editor, the exact details of what can be displayed depending onwhether a Science Goal or a Scheduling Block is being viewed.

9.2.1

Science Goal

After defining spectral windows in the Forms Editor, these will appear in the Spectral Editor (Figure 9.1) asvertical blue lines marking the central frequency and a horizontal bar to indicate the bandwidth. For band-9 and-10 setups, the “image” spectral windows will also be shown in the opposite sideband – these are indicated inorder to bring the user’s attention to other lines or atmospheric absorption features that may affect the qualityof the data in the “signal” spectral window.
If no warnings have been issued by the OT, a tuning solution will have been found and the sidebands andLO1 indicator will be coloured yellow. For a tuning solution to have been found, it should be the case that all of
the spectral windows fit within the sidebands. However, it is possible that small portions of the spectral windows
do lie outside the sidebands, but as long as these are coloured yellow, there is nothing to worry about. If nosolution is found then the sidebands are coloured grey.

Figure 9.1: The graphical representation of the frequency information in a Science Goal. Four spectral windows
are shown, a narrow one to observe the CO(3-2) transition and three other maximum-bandwidth ones for measuring a continuum. All four fit within the sidebands which are coloured yellow (as opposed to grey) to signifythat a valid tuning solution has been found. The displayed transmission curve has been set to a value (3rd octile)
appropriate for the frequency being observed. Also visible are the various controls as well as the green bars thatmust be grabbed to pan the display.
1 e.g. Pardo, J. R., Cernicharo, J., Serabyn, E., 2001, ITAP, 49, 1683.

66

For experimentation purposes, it is possible to move the sidebands by dragging the LO1 marker, but as soon
as the mouse is released, the sidebands will return to their original position. This is because the ALMA tuning
solution is calculated by an algorithm that takes the spectral window frequencies and bandwidths as input i.e.
the value of LO1 is not settable by the user. If no valid tuning solution exists, the sidebands will stay where
they are when released, but remain coloured grey.
The Targets panel in the Forms Editor contains a table with an overview of relevant source properties,
including their velocity and Representative Frequency. If multiple sources have been defined, this table allows
the user to display the spectral windows according to this source’s velocity. Only one source at a time can beselected.
As part of the tuning solution, the OT will also have calculated the positions of the basebands, but these are
not currently displayed in the Science Goal Spectral Editor.

9.2.2

Scheduling Block

The graphical display in an SB is similar to that of the Science Goal, but shows more features of the spectral
setup that is displayed/defined in the Forms Editor and allows more control over what is displayed (Figure 9.2).
The key features that are visible in an SB, but not in a Science Goal are the basebands and the spectral
averaging regions. As this is a lot of information to display, what is shown depends on the level of zoom that isbeing used. At low levels of zoom, only the sidebands and the basebands are visible. Further zooming in will
also show the spectral windows contained within each baseband, as well as the spectral averaging regions of each
spectral window.

Figure 9.2: The graphical representation of the frequency information in a Scheduling Block. This is a zoomed
view and hence the spectral windows and their spectral averaging regions can be seen. The basebands are shownas the green blocks and within these can be seen the spectral windows (horizontal bars). Below the basebands
are the spectral averaging regions (also horizontal bars). Note that there are two spectral windows in Baseband
2, each with a single spectral averaging region. Baseband 3 contains a spectral averaging region which extends
out of the spectral window and has thus been coloured orange to signify a problem.
Unlike in a Science Goal, it is possible to move the sidebands and LO1 using the mouse and this will
even update the value of LO1 displayed in the Forms Editor. However, this will again be ignored when theobservations are performed as the ALMA Control system will derive its own tuning solution using the spectral67window frequencies passed to it by the OT.
Whilst most of the controls are self-explanatory, the following are worth mentioning briefly. Checking FoldBasebands and Fold Spectral Windows allows the tool to use less vertical space, whilst Track selection
results in which ever baseband is selected in the Forms Editor to be shown zoomed.
Source velocities are slightly tricky in the context of the Spectral Editor in a Scheduling Block. If the Spatial
Editor is being viewed inside a Target, then things are simple and the velocity of that source will be used.
However, if viewing the graphical display from within an Instrument Setup, this can potentially be attached tomultiple Targets and therefore different sources. For calibrator Targets, these will use the velocity of the source
contained in the Representative Target. For science Targets, the first source in the Field Sources folder which is
attached to a Target will be used. However, regardless of which velocity is used, its value and the source it istaken from is displayed in the Forms Editor, just below the Calculate LOs button.

68

Appendix A

Create an External Ephemeris
This Appendix explains in detail how to use the JPL HORIZONS system to create an ephemeris file for solarsystem bodies. These can be used in either Science Goals (Section 5.3.2.1) or Scheduling Blocks (Section 6.2.4.1).
Only ephemerides generated by HORIZONS will work with the ALMA Control System and the OT will reject
the ephemeris if this is not the case.

A.1

NASA resources for HORIZONSThe following internet links can be useful for ALMA users requiring an ephemeris.
• https://ssd.jpl.nasa.gov/horizons/app.html: Direct link to the HORIZONS web interface. This isa very useful link as, if an ephemeris has previously been generated using the web browser, it will bring up
the inputs that were last used.
• https://ssd.jpl.nasa.gov/horizons: HORIZONS web page (web interface link can be found here, in
addition to multiple formats for documentation).
• https://ssd.jpl.nasa.gov/horizons/manual.html: On-line user manual. This is the ultimate reference, is extremely detailed and should not be required for most users.

A.2

Instructions and Settings

Go to https://ssd.jpl.nasa.gov/horizons/app.html. The HORIZONS web interface shows the current
settings, all of which can be modified using the “Edit” buttons. Previously-used settings seem to be remembered,so we first recommend that all inputs should be set to their default using the “custom” settings. The inputs
should then be set as follows:• Ephemeris Type should be Observer Table (default).
• Set Target Body to the relevant solar-system body.
• The Observer Location is most easily set to ALMA using the “Lookup the Specified location” option.
Entering “ALMA” will enable a search and the entry that should be chosen is Atacama Large mm/sub-mm
Array (ALMA) Center of Array [-7]. Note that geocentric locations should no longer be used.
• The Time Specification should be set as needed. The ephemeris should contain at least one row for every
hour and, except for fast objects, one row every 20 minutes is sufficient. The online system will linearlyinterpolate between rows in an ephemeris when determining the antenna pointing and propagation delay.
69

• Of the many possible Custom settings, only Astrometric RA & DEC and Obsrv range & rng rate are
required – there are options 1 and 20. It is also recommended that “Extra precision” be selected from theadditional settings. Do not select the elevation cutoff option as this is likely to fail.
Once the inputs have been checked and found to be okay, the ephemeris can be generated. This will take theform of text in the browser window which can be downloaded as a text file and then read into the Science Goal
or SB.

A.3

Example Ephemeris

The text below shows what a typical ephemeris generated by HORIZONS should look like – it was copied andpasted directly out of a browser window. Ephemerides that do not conform to the HORIZONS format will berejected by the OT.
*******************************************************************************
JPL/HORIZONS
2 Pallas (A802 FA)
2021-Nov-25 01:37:14
Rec #:
2 (+COV) Soln.date: 2021-Nov-10_04:32:18# obs: 8986 (1804-2021)
IAU76/J2000 helio. ecliptic osc. elements (au, days, deg., period=Julian yrs):
EPOCH= 2449860.5 ! 1995-May-23.00 (TDB)
EC= .2338718245610453
QR= 2.123202022785147
OM= 173.299720872062
W= 309.6980700058111
A= 2.771340476505324
MA= 354.0740855566733
PER= 4.61363
N= .21363344
DAN= 2.27927
DDN= 3.07984
B= -26.0524618
MOID= 1.22409999

Residual RMS= .37248
TP= 2449888.2387017086
IN= 34.8067960750926
ADIST= 3.419478930225501
ANGMOM= .02784275
L= 128.6147078
TP= 1995-Jun-19.7387017086

Asteroid physical parameters (km, seconds, rotational period in hours):
GM= 14.3
RAD= 272.5
ROTPER= 7.8132
H= 4.22
G= .110
B-V= .635
ALBEDO= .101
STYP= B
ASTEROID comments:
1: soln ref.= JPL#49, OCC=0
2: source=ORB**************************************************************************************************************************************************************
Ephemeris / WWW_USER Thu Nov 25 01:37:14 2021 Pasadena, USA/ Horizons*******************************************************************************
Target body name: 2 Pallas (A802 FA){source: JPL#49}
Center body name: Earth (399){source: DE441}
Center-site name: Atacama Large mm/sub-mm Array (ALMA) Center of Array*******************************************************************************Start time
: A.D. 2021-Nov-23 00:00:00.0000 UT
Stop time: A.D. 2022-Nov-23 00:00:00.0000 UT
Step-size: 14400 minutes*******************************************************************************
Target pole/equ : IAU{West-longitude positive}
Target radii: 275.0 x 258.0 x 238.0 km{Equator, meridian, pole}
Center geodetic : 292.245252,-23.029211,5.0748870 {E-lon(deg),Lat(deg),Alt(km)}Center cylindric: 292.245252,5877.51430,-2481.682 {E-lon(deg),Dxy(km),Dz(km)}Center pole/equ : ITRF93{East-longitude positive}
Center radii: 6378.1 x 6378.1 x 6356.8 km{Equator, meridian, pole}
Target primary : Sun
Vis. interferer : MOON (R_eq= 1737.400) km{source: DE441}

70

Rel. light bend : Sun, EARTH{source: DE441}
Rel. lght bnd GM: 1.3271E+11, 3.9860E+05 km^3/s^2
Small-body perts: Yes{source: SB441-N16}
Atmos refraction: NO (AIRLESS)
RA format: HMS
Time format: CAL
EOP file: eop.211123.p220216
EOP coverage: DATA-BASED 1962-JAN-20 TO 2021-NOV-23. PREDICTS-> 2022-FEB-15
Units conversion: 1 au= 149597870.700 km, c= 299792.458 km/s, 1 day= 86400.0 s
Table cut-offs 1: Elevation (-90.0deg=NO ),Airmass (>38.000=NO), Daylight (NO )Table cut-offs 2: Solar elongation ( 0.0,180.0=NO ),Local Hour Angle( 0.0=NO )Table cut-offs 3: RA/DEC angular rate (0.0=NO )*******************************************************************************
Initial IAU76/J2000 heliocentric ecliptic osculating elements (au, days, deg.):
EPOCH= 2449860.5 ! 1995-May-23.00 (TDB)
Residual RMS= .37248
EC= .2338718245610453
QR= 2.123202022785147
TP= 2449888.2387017086
OM= 173.299720872062
W= 309.6980700058111
IN= 34.8067960750926
Equivalent ICRF heliocentric cartesian coordinates (au, au/d):
X=-8.772609677396623E-01 Y= 1.913607209947000E+00 Z=-3.186495571164625E-01
VX=-1.170946514074898E-02 VY=-5.524088469211407E-03 VZ= 1.888876172855325E-03
Asteroid physical parameters (km, seconds, rotational period in hours):
GM= 14.3
RAD= 272.5
ROTPER= 7.8132
H= 4.22
G= .110
B-V= .635
ALBEDO= .101
STYP= B**********************************************************************************************
Date__(UT)__HR:MN
R.A._________(ICRF)_________DEC Ang-diamdeltadeldot**********************************************************************************************$$SOE
2021-Nov-23 00:00 A
22 50 16.793999 -11 56 27.28440 0.280824 2.70040288098657 22.3747456
2021-Dec-03 00:00 A
22 55 44.644163 -12 18 15.77017 0.267971 2.82992073319386 22.5898771
2021-Dec-13 00:00 Nm 23 02 53.610740 -12 24 32.78705 0.256335 2.95838322710588 22.1330438
2021-Dec-23 00:00 N
23 11 30.126431 -12 17 26.84881 0.246027 3.08233971188776 21.1599398
2022-Jan-02 00:00 N
23 21 22.102397 -11 58 55.56776 0.237041 3.19918190090926 19.7605042
2022-Jan-12 00:00 Nm 23 32 19.316031 -11 30 44.52487 0.229347 3.30650035089502 17.9576269
2022-Jan-22 00:00 N
23 44 11.735141 -10 54 39.61357 0.222882 3.40241637347632 15.8980342
2022-Feb-01 00:00 N
23 56 51.832169 -10 12 11.42441 0.217559 3.48565807925177 13.6190177
2022-Feb-11 00:00 Nm 00 10 13.439941 -09 24 45.80344 0.213316 3.55499994373594 11.1511967
2022-Feb-21 00:00 A
00 24 10.715417 -08 33 49.38248 0.210079 3.60977178274681
8.6184210
2022-Mar-03 00:00 A
00 38 39.990428 -07 40 36.20762 0.207782 3.64967489161781
6.0180910
2022-Mar-13 00:00 Am 00 53 38.018183 -06 46 22.98603 0.206384 3.67439760307169
3.3972043
2022-Mar-23 00:00
01 09 01.769840 -05 52 25.96048 0.205837 3.68417178343085
0.8482752
2022-Apr-02 00:00
01 24 49.840116 -04 59 52.18247 0.206105 3.67937764621516 -1.6597170
2022-Apr-12 00:00 m 01 41 00.417013 -04 09 56.15093 0.207174 3.66038365299680 -4.0649532
2022-Apr-22 00:00
01 57 31.827651 -03 23 49.16058 0.209021 3.62803719193081 -6.3112252
2022-May-02 00:00
02 14 23.441132 -02 42 37.40664 0.211641 3.58313608714007 -8.4449769
2022-May-12 00:00 m 02 31 33.531370 -02 07 36.23797 0.215039 3.52650835378701 -10.3964475
2022-May-22 00:00
02 49 00.470153 -01 39 54.24724 0.219214 3.45935446572210 -12.1461882
2022-Jun-01 00:00
03 06 43.040468 -01 20 39.18649 0.224183 3.38267418602595 -13.7415749
2022-Jun-11 00:00 m 03 24 38.368551 -01 11 05.38423 0.229969 3.29756032677099 -15.1136368
2022-Jun-21 00:00
03 42 43.693204 -01 12 15.96518 0.236585 3.20534638994320 -16.2769054
2022-Jul-01 00:00
04 00 55.967013 -01 25 16.01658 0.244068 3.10707389780470 -17.2675804
2022-Jul-11 00:00 m 04 19 10.115486 -01 51 08.97258 0.252448 3.00393607373007 -18.0258314
2022-Jul-21 00:00
04 37 21.303175 -02 30 41.63720 0.261746 2.89722247446922 -18.5950274
2022-Jul-31 00:00 m 04 55 23.658429 -03 24 41.99710 0.272010 2.78790064679093 -18.9935523
2022-Aug-10 00:00 m 05 13 09.190906 -04 33 42.08726 0.283266 2.67712352951536 -19.1771768
2022-Aug-20 00:00
05 30 30.338603 -05 57 51.67063 0.295533 2.56599769465667 -19.2093895
2022-Aug-30 00:00 m 05 47 17.619422 -07 37 15.19997 0.308853 2.45533546782246 -19.0893385
2022-Sep-09 00:00 m 06 03 19.529074 -09 31 21.61689 0.323228 2.34614061323848 -18.7909526
2022-Sep-19 00:00
06 18 24.894622 -11 39 12.17457 0.338656 2.23925735792677 -18.3832297
2022-Sep-29 00:00 m 06 32 19.367985 -13 59 26.81385 0.355139 2.13532469625281 -17.8456827

712022-Oct-09 00:00 m 06 44 46.693190 -16 29 44.05400 0.372615 2.03517650031244 -17.1659952
2022-Oct-19 00:00
06 55 30.362447 -19 07 04.17563 0.391006 1.93944980264050 -16.3973292
2022-Oct-29 00:00 Am 07 04 09.718060 -21 47 30.41483 0.410191 1.84874117176821 -15.4954150
2022-Nov-08 00:00 Am 07 10 24.058493 -24 25 26.12444 0.429926 1.76387983133252 -14.4506970
2022-Nov-18 00:00 A
07 13 54.628293 -26 54 11.45907 0.449899 1.68557105432760 -13.2785329$$EOE**********************************************************************************************
Column meaning:
TIME
Times PRIOR to 1962 are UT1, a mean-solar time closely related to theprior but now-deprecated GMT. Times AFTER 1962 are in UTC, the current
civil or "wall-clock" time-scale. UTC is kept within 0.9 seconds of UT1using integer leap-seconds for 1972 and later years.
Conversion from the internal Barycentric Dynamical Time (TDB) of solar
system dynamics to the non-uniform civil UT time-scale requested for output
has not been determined for UTC times after the next July or January 1st.
Therefore, the last known leap-second is used as a constant over futureintervals.
Time tags refer to the UT time-scale conversion from TDB on Earthregardless of observer location within the solar system, although clock
rates may differ due to the local gravity field and no analog to "UT"
may be defined for that location.
Any ’b’ symbol in the 1st-column denotes a B.C. date. First-column blank(" ") denotes an A.D. date. Calendar dates prior to 1582-Oct-15 are in the
Julian calendar system. Later calendar dates are in the Gregorian system.
NOTE: "n.a." in output means quantity "not available" at the print-time.
SOLAR PRESENCE (OBSERVING SITE)
Time tag is followed by a blank, then a solar-presence symbol:
’*’
’C’
’N’
’A’
’ ’

Daylight (refracted solar upper-limb on or above apparent horizon)
Civil twilight/dawn
Nautical twilight/dawn
Astronomical twilight/dawn
Night OR geocentric ephemeris

LUNAR PRESENCE (OBSERVING SITE)
The solar-presence symbol is immediately followed by a lunar-presence symbol:’m’’ ’

Refracted upper-limb of Moon on or above apparent horizon
Refracted upper-limb of Moon below apparent horizon OR geocentric
ephemeris’R.A._________(ICRF)_________DEC’ =Astrometric right ascension and declination of the target center withrespect to the observing site (coordinate origin) in the reference frame ofthe planetary ephemeris (ICRF). Compensated for down-leg light-time delay
aberration.
Units: RA in hours-minutes-seconds of time,
DEC in degrees-minutes-seconds of arc,

HH MM SS.ff{ffff}
sDD MN SC.f{ffff}’Ang-diam’ =The equatorial angular width of the target body full disk, if it were fully

72

illuminated and visible to the observer. If the target body diameter is unknown"n.a." is output.
Units: ARCSECONDS’deltadeldot’ =Apparent range ("delta", light-time aberrated) and range-rate ("delta-dot")of the target center relative to the observer. A positive "deldot" means thetarget center is moving away from the observer, negative indicates movement
toward the observer. Units: AU and KM/S
Computations by ...
Solar System Dynamics Group, Horizons On-Line Ephemeris System
4800 Oak Grove Drive, Jet Propulsion Laboratory
Pasadena, CA 91109
USA
General site: https://ssd.jpl.nasa.gov/
Mailing list: https://ssd.jpl.nasa.gov/email_list.html
System news : https://ssd.jpl.nasa.gov/horizons/news.html
User Guide : https://ssd.jpl.nasa.gov/horizons/manual.html
Connect: browser
https://ssd.jpl.nasa.gov/horizons/app.html#/x
API
https://ssd-api.jpl.nasa.gov/doc/horizons.html
command-line
telnet ssd.jpl.nasa.gov 6775
e-mail/batch
https://ssd.jpl.nasa.gov/ftp/ssd/hrzn_batch.txt
scripts
https://ssd.jpl.nasa.gov/ftp/ssd/SCRIPTS
Author: Jon.D.Giorgini@jpl.nasa.gov**********************************************************************************************

73

74

Appendix B

Acronym List
2SB: Two sideband (receiver)
ACA: Atacama Compact Array (also known as the Morita Array)
ALMA: Atacama Large Millimeter/submillimeter Array
APDM: ALMA Project Data Model
ASA: ALMA Science Archive
ASDM: ALMA Science Data Model
ARC: ALMA Regional Centre
ASC: ALMA Sensitivity Calculator
BWSW: Baseband Switching
B2B: Band-To-Band
DGC: Differential Gain Calibration
DDT: Director’s Discretionary Time
DSB: Double Sideband (receiver)
EB: Execution Block
EOC: Extension and Optimization of Capabilities
FOV: Field Of View
GOUS: Group Observing Unit Set
LAS: Largest Angular Scale
LO: Local Oscillator
LSB: Lower Side Band
MOUS: Member Observing Unit Set
MRS: Maximum Recoverable Scale
OG: Observing GroupOT: Observing Tool
OTF: On The Fly
OUS: Observing Unit Set
PI: Principal Investigator
PWV: Precipitable Water Vapour
SACA: Stand-alone ACA
SB: Scheduling Block
SG: Science Goal
SSB: Single Sideband (receiver)
SFI: Single Field Interferometry
SLP: Spectral Line Picker
SPW: Spectral Window
TFB: Tunable Filter Bank
TJ: Technical Justification
TP: Total Power
USB: Upper Side Band75

76