1 / 22

JCMT Software Workshop Introduction

JCMT Software Workshop Introduction. Nick Rees. Agenda. Monday: Overview of most systems Tuesday: AM: Overview of ACSIS, SCUBA and pointing+focus PM: Discussion. Identification of problem areas. Wednesday: Interface discussion groups Thursday: Write up

ayala
Télécharger la présentation

JCMT Software Workshop Introduction

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. JCMT Software Workshop Introduction Nick Rees

  2. Agenda • Monday: Overview of most systems • Tuesday: • AM: Overview of ACSIS, SCUBA and pointing+focus • PM: Discussion. Identification of problem areas. • Wednesday: Interface discussion groups • Thursday: Write up • Final interface documents should reflect current thinking • Friday: Wind-up • Note: • Can you bring presentations to me before the talk

  3. Social Agenda • Tonight: Pizza’s. My house, 7 pm (Pizza’s provided). • Wednesday lunch: Suggestion we go to Nihon. • Thursday evening: Royal Siam, 7 pm (Food provided) • Other meals organized on the day.

  4. Tonight - Pizza’s @ 7:00 pm • 171 Halai St. Ph: 935-4158 • Pizza’s and salad will be provided • Please bring drinks.

  5. Workshop Goals • Generate interface descriptions of all major interfaces in the JCMT observatory control system • Internally review the overall system design • Generate a common understanding of the development track for new JCMT software systems • Generate an identity as a ‘JCMT Software Community’

  6. Some History • Apr 94 Discussion of JCMT Control System Futures • Sept 95 “Upgrades to the JCMT Control System” • Sept 96 ACSIS proposal • Oct 96 Heterodyne OCS - Project Overview (OCS/SN/1) • Apr 97 Original ORAC proposal (called OCSDR) • Apr 97 OCS Design & Planning Meetings - TODD, Proj. Plan • Aug 97 First RTS Specs (ACSIS Note 6) • Oct 97 Joint ACSIS/OCS discussion meetings • Dec 97 Software Forward Look (OCS 6 months) • Feb 98 Beta-1 Release of the TODD • Apr 98 ACSIS PDR

  7. More History • Jun 98 First OMP project plan (OMP/PN/002) • Jan 99 NPR becomes head of JAC software • Mar 99 JCMT, UKIRT and Gemini Scheduling Workshop • Aug 99 RMP left JAC • Jan 00 OCS put on hold • Apr 00 OCS project reformulated so it is at ATC (RTS, TODD, TODD recipes and OT for ACSIS. Observing Manager not part of ATC deliverables) • Jun 00 RTS Requirements Document. RTS starts taking shape • Aug 00 ORAC released, JCMT TCS released • Nov 00 OMP project restarts/JAC Software groups reorganized. • Dec 00 SCUBA OT added to OCS project deliverables • Jan 01 RTS written review

  8. Common Infrastructure • Basic Software Requirements • Common interfaces (base methods) • Error handling and propagation

  9. Basic Software Requirements - 1 • Delivery via CVS • Minimal number of modules (i.e. source trees) • cvs checkout <module>; configure; build • Must build entire tree • All dependencies must be explicitly identified in configuration. • ESO example • User and programmer documentation. • Programmer docs largely extracted from code headers.

  10. Basic Software Requirements - 2 • Simple, run-up: startup scripts part of deliverables. • Run-up scripts should support -h and -sim options. • Avoid raw socket protocols • Must be able to switch versions with a single command.

  11. Common interfaces - Actions • JAC Instrumentation Task • INITIALISE - normally once only at startup. • CONFIGURE - before an observing sequence. • SEQUENCE - perform an observing sequence (JCMT only) • DEBUG (?) - should this just be a parameter? • TEST - Performs self-tests. • REPORT - Reports current status of task. • HELP - Reports what task does. • EXIT - Runs down task

  12. Common interfaces - JIT • Generic instrumentation task library developed (jit) • All actions are currently trivial • Can extend as required. • How to handle ‘sub-classing’? • Overloading the action definitions. • Callbacks. • How useful Is adding functionality to the library? • Eliminates repetition • Can develop best methods, but: • Additional dependencies sticky ‘lump’ • Relying on jit developer (JAC). • CVS may help

  13. Common Interfaces - XML • Need to adopt a single XML parser • Need to provide support for different formats: • File on disk • Drama string • Translation to and from a DRAMA structure. • Could be done via something similar to GitGetSDS • Look for parameter string, else check on disk, • Automatically convert XML into SDS.

  14. Error Handling • Low(er) level systems decide error severity • Errors either Fatal or non-Fatal • Fatal errors indicated by an action returning a non-zero status on action termination. They will nearly always result in termination of the sequence, and possibly termination of the MSB. • Non fatal errors just result in a message, but appropriate diagnostic information must also get into the file headers. • Implications: • Must be able to alter severity through an engineering interface (I.e. sub-systems must be able to mask errors).

  15. Fatal Error Consequences • TODD pops up a three button dialog box essentially asking ABORT, TERMINATE or CONTINUE? • TODD performs programmed cleanup (typically kicks/cancels all actions initiated at this level - i.e. active SEQUENCE actions). • All active actions must shut down cleanly having received a kick/cancel. • Should the TODD automatically handle Fatal errors in general (may avoid error storm)?

  16. Non-Fatal Errors • These are warning messages from tasks • TODD can log these • Is a scrolling window interface all we need/require?

  17. System Architecture • Entirely new - VMS system needs to be replaced. • Need commonality with UKIRT at high level and, where possible, at lower levels (i.e. TCS). • All observations are defined using an observing tool. • Observing interface essentially queue control of defined observations. • External interfaces to be kept simple, and consistent. • Detailed sub-system control in engineering interfaces • Reason is so development groups can have reasonable freedom to do what is right for them.

  18. OMP Project Observation Preparation Schedulable Blocks Obs. Management Observation Database Observation Translation Observation Selection JCMT OCS Project OCS System System Configurations ORAC Project Pointing + Focus Observation Sequencing ACSIS DR Ancillary Control System Telescope Control System Instrument Control System Data Handling Data Reduction HARP, ACSIS IF, ACSIS Corr, SCUBA JAC Observing Model

  19. JCMT implementation of JAC Observing Model

  20. JCMT System - Alternative view • Green: Direct control interfaces • Red: Monitoring interfaces • Blue: Indirect control interfaces

  21. Deficiencies • Ignored observing interface • Basically queue manipulation • Hence ignored queues… • Queue interfaces may have other requirements • Tim Jenness will cover some of this

  22. Summary • We have a lot to do this week. • Start of an on-going process • Communicate, communicate, communicate….

More Related