1 / 12

The OCS Translator and Queue System Overview for JCMT Interfaces

This document provides a detailed overview of the OCS Translator and Queue system used within the JCMT Observing Interface. It explains how the observing tool's output is formatted for compatibility with observing systems, detailing the translation of OT XML to TODD and SCUBA ODFs. The interaction between the Observing Manager (OM) and the queue is outlined, highlighting how multiple science programs are managed and stacked for seamless execution. Additionally, it addresses current system integrations, future improvements needed, and potential enhancements for SCUBA compatibility.

sheena
Download Presentation

The OCS Translator and Queue System Overview for JCMT Interfaces

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The OCS Translator and Observing Queue Tim Jenness JCMT Interfaces Meeting / April 2nd-6th 2001

  2. What does it do? • Converts Observing Tool output to format required by observing system • Converts OT XML to TODD ODFs and SCUBA ODFs • The Nexus between the high level system and the low level system

  3. How does it run? • The Observing Manager (OM) asks for a Science Program to be translated • The OM receives the translated program (either as filenames or as the contents) and sends it to the queue

  4. Why have a queue? • The TODD and SCUBA can only receive a single observation • Each Science Program may consist of multiple observations • Multiple science programs can be stacked up to form a science plan

  5. What is the queue? • Currently a DRAMA task based on the SCUBA QUEMAN system • Stack based • At the moment just works with the TODD

  6. System Design • OM uses CORBA to talk to the Translator “server” • OM uses DRAMA to talk to the queue • Queue uses plain socket to talk to the TODD • Queue UI monitors DRAMA parameters from TODD and Queue

  7. Issues - translator • Needs to know the OT XML • Needs to know the required TODD inputs (currently assumes keyword/value ODFs) • Need to know whether a single XML file is required for the entire system or individual XML files for each subsystem

  8. Issues - queue • Must be updated to work with SCUBA to replace QUEMAN • Might be better to re-write the queue as a CORBA server. Will need to support: • rescheduling actions (to monitor the TODD) • parameter monitoring • Would be interesting if the TODD used DRAMA or CORBA!

  9. Summary • For TODD, translator needs to know requirements of each of the subsystems • For SCUBA, the ODF parameters fully specify the observation • Queue will have to be extended for use with SCUBA • Queue might be incorporated into the OM

More Related