Overview of current JCMT OCS Project

1. Overview of current JCMT OCS Project Richard Prestage Joint Astronomy Centre

2. Overview • Current JCMT Software/Instrumentation • Current JCMT Observing Modes/Control • JCMT Control System Upgrades/Strategy • OCS project (and the Todd) • Relationship to ACSIS and Observation Management Project

3. Current JCMT Software • Three main components: • Telescope control software (TEL, SMU, TMU) • Heterodyne instrument control software (Frontend tasks, IF task, backend tasks, data storage task, data display task, control task) • SCUBA control software (~ six tasks including a control task) • All Vax/VMS (ADAM) based.

4. JCMT Instrumentation • SCUBA - the only continuum instrument. • Existing heterodyne instrumentation. • Heterodyne array program (2001 - ?): • ACSIS • HARP-B/D • ACSIS/HARP expected to revolutionise spectral line mapping in the same way that SCUBA revolutionised continuum mapping.

5. JCMT Observing Modes • All JCMT Observations consist of complex sequences of “atomic” operations performed by individual sub-systems. In many cases these can and should execute in parallel. • An “observation” typically consists of a basic unit of integration (~ seconds to ~minutes) repeated for a few to a few tens of minutes, and resulting in a single data file.

6. JCMT Observing Modes • For heterodyne observations, these are co- ordinated by the CONTROL task (an ADAM CD-task). • CONTROL task must be configured, and observations performed manually via ICL procedures. • For SCUBA observations, these are co-ordinated by SCUCD, a CD task which operates by interpreting “scripts” (written in a custom scripting language). • Observations are defined in advance in an Observation Definition File (including appropriate script name) and may be placed on a simple queue for execution.

7. Problems with the existing OCS • heterodyne CONTROL task: • implemented as a VAX ADAM CD-task • undocumented • observing modes are hard-coded in Fortran, difficult to modify existing observing modes or add new ones, continual fear that modifications will “break” other observing modes • difficult to correctly execute actions in sub-tasks in parallel (startobey/endobey problem)

8. Problems with the existing OCS • SCUBA SCUCD task: • interprets scripts and is much more flexible and easy to modify • parameters of observations are specified in advance (ODF files) and observations may be placed in a queue • SCUCD is still a Vax ADAM Fortran task

9. JCMT Control System Upgrades • As a self contained project, upgrade the TCS to a new, more efficient and flexible Unix based system (being done in collaboration with AAO). • Retain the existing SMU and instrument control, data storage and display tasks (no effort to re-write these). • Replace the existing heterodyne and SCUBA control tasks with a single new “control task” (the Todd). • Provide higher level software such as queue managers, observation preparation tools, observing databases, etc.

10. Upgrade Strategy • Develop the new control task and recipes for existing observing modes for heterodyne instruments. • Replace existing SCUBA control task and recipes with new system. • Include ACSIS team in discussons of new control task to ensure that it meets their requirements for observation control • Anticipate likely form of higher level software (and hope to benefit from Gemini and UKIRT developments) but no effort to develop these during the existing OCS project.

11. Specifications for New Control task • Must be capable of controlling SCUBA, existing heterodyne instruments and ACSIS/HARP. • Observations should be defined as “recipes”, with parameters for specific observations defined in advance in Observation Definition Files. • Must be easy to develop, modify and extend recipes. • One of the prime requirements is that it must be easy to define and efficient to execute “parallel” commands (groups of primitive commands to be sent in parallel to different sub-systems). • Must provide good support for any move to a flexible scheduling scheme.

12. The Todd • Telescope Observation Designer and Driver. • Java application developed by Dennis Kelly at ROE (ATC). • Provides a GUI for both creating and executing recipes. • May be driven from a queue manager (not yet developed) or a scripting language (currently any unix shell via the “toddle” program).

13. Todd Details (ask Dennis Kelly!) • Recipes defined using the built-in GUI. • Recipe components consist of Command, FoldBox, CaseBox, Choice and Pause. • Command components may be built-in commands, or commands to be sent to tasks. • Built-in commands manipulate Todd variables; Commands to tasks correspond to usual get, set obey, obeyw, cancel. • Communicates with tasks using DramaTodd (drama “user interface” process) • Observation definition files consist of the name of a Todd variable to be created or redefined, followed by the value.

14. Current Status • Todd is under beta-test at JAC using heterodyne recipes, Dennis is addressing ACSIS wish-list. • Mary is developing heterodyne observing recipes (and ODFs) , hope to complete these July 1999. • Current plan is that Tim should start work in March on a simple queue manager. • Dennis is in process of developing SCUBA recipes (and “helper” tasks) to allow Todd to replace existing SCUCD task. • ACSIS team are discussing use of Todd for ACSIS for detailed internal design review to be held in June 1999.

15. Future Work • Replacement of existing CONTROL tasks will (hopefully) be complete this summer. • Next stage - Observation Management Project. • Main goal is to make life easier for JCMT support staff, and for visiting astronomers while present at the telescope. • OMP will be described in presentation by Remo Tilanus. • ACSIS requirements will be described by Bill Dent.