Summary

1. Summary Nick Rees

2. Overview • ACSIS AIPS++ development environment • Error timeouts in low-level systems • Propose XML interface in JIT • JIT

3. Observing Tool • ACSIS Re-reduction problems • How do we re-reduce the MS data during the day? • Iterator use - TODD vs OT • SCUBA integration within OT - not considered well at the moment. • Responsibilities of low-level sub-system development groups

4. OMP • Needs site quality information. • Needs to sort out conventions for folders etc. • Needs to sort out handling engineering observations. • Need to be easily able to grant time to projects (e.g. be able to grant a few minutes to finish an observation).

5. Translator/Queue • Queue needed to broker between the OMP dealing with MSB’s and the TODD dealing with observations • multiple observations per MSB. • How much parallelism do we need? • Do we need parallel queues? • How do we handle engineering • in general (do we need the full system to engineer a part of it) • whilst observing (conflicts between instruments)? • Engineering tests on ACSIS - how much of the system do we require? • Engineering interfaces. • Modify TODD to use djava? (NO)

6. TODD - 1 • If TODD uses Drama (I.e. djava), it creates a problem since then it needs Drama when designing recipes • TODD can only handle very simple scalar data-types. • Only one TODD can be running on one machine. • Parallel commands are needed for asynchronous operations (e.g. pause, abort etc). • NOT really for doing parallel observations. • Aborts and pauses get into the TODD using parallel commands.

7. TODD - 2 • TODD has three message screens on Solaris, one on other systems). • System is a kludge (uses X-terms on Solaris, and stdout on other systems) • Should be replaced, if possible, by an intelligent system monitoring the log files, so you can have multiple clients. • To do this, we need to be able to flush Java file buffers. • To switch between local and remote the TODD currently needs to be run down and up. • Timeout issues.

8. RTS • Naming conventions should be RTS specific. • Need XML naming conventions to avoid namespace clashes i.e.: • <system>_CONFIG • <system>_SEQUENCE • Need to have capability of having single big XML file (for archiving) and individual files (for sub-system control). • Need to finalize the RTS specs. • Dennis flagged the fact that waitSamp is overloaded: • needs waitSamp (for interval control), and • needs another thing (say endSamp) for integration blanking.

9. TCS • Should the TCS have an XML configuration? • Since there can be more than one CONFIGURE per SEQUENCE, do we need a pre-SEQUENCE action, or is all pre-SEQUENCE configuration passed to the SEQUENCE command.

10. Front End • Debugging should not be set at initialization, but done from an engineering interface. • What is meant by INITIALISE? • Normally done only once. • Should be able to be done a second time to do a ‘soft reset’ of the task • Need array of active channels • Difference between CONFIGURE, TUNE and SEQUENCE • RTS signals don’t have defined maximum timeouts • Initial/Final state must be define by the configure. • Load switching could happen as part of SEQUENCE

11. ACSIS • Tony’s points • Error reporting from AIPS++ ACSIS -> TODD • Gridding/Handling non-sidereal objects • Real-time display requirements • scalar/status monitoring • Front End data? • Antenna/Beam algorithms • Sample DRAMA monitoring code. • Additional header items must be able to be added by adding a single line to a configuration file. • How much is in the configuration file and how much in the TODD? • Drama monitoring problems.

12. ACSIS-DR • TODD configures RTD? Multiple RTDs, So which RTD? • Need a mapping between the XML files and the Glish tables. • Need to be able to implement polarimeter recipes. • Need to coerce the ACSIS-DR XML so that it is easy to handle the translator. • How to handle calibrations.

13. Pointing and Focus • ACSIS will provide a method of notifying synchronous completion of a data reduction process. • Unclear whether it is better to control telescope via the TODD or the pointing and focus tool.

14. Major points -Translator • Translator work needs to be streamlined. So we need to distinguish between: • Data from the OT • Data from static configuration files determined by sub-system and observing mode. • Need to define CONFIGURE and SEQUENCE commands better • How many CONFIGURE’s per ODF? (i.e How does the translator know how many files to prepare) • How many SEQUENCE’s per ODF. • Does SEQUENCE command take the state table? • Do we need a pre-SEQUENCE command (IAS’s SETUP)

15. Major points -XML • Syntax • How much do we use a DTD? • Generalization vs XML verification. • XML from OT must be easily mappable to: • Syntax of XML files/fragments for sub-systems. • How many XML files are required for each TODD recipe? • How many CONFIGURE commands/system? • How many SEQUENCE commands/system? • Definition of CONFIGURE and SEQUENCE needs to be well understood. • TODD recipe. • TODD Recipe parameters.

16. Major Points - ACSIS • We must distinguish between: • Data which is not related to sequence information (e.g. temperatures) • Data which is static during a sequence (i.e. uniquely defined at configuration time - i.e. by configuration file) • Data which may change during a sequence (i.e. must come in sequence number packets). • Drama monitoring problems • JAC needs to be able to write a task that demonstrates this. • We need to test this. • FITS keywords

17. Major points - Specific interfaces • TCS XML definition • ACSIS FITS headers • All - distinguish between OT information and static files.

18. Decisions - 1 • 1 XML file/sub-system/TODD ODF • 1 CONFIGURE action/sub-system/TODD ODF • Have a STATE_TABLE action before the SEQUENCE action. • State table definition is responsibility of sub-system, not translator. • State table keyed by name (keyed by observing mode). • No intersection between data passed by the CONFIGURE and STATE_TABLE commands • ACSIS measurement sets don’t distinguish between synchronous and asynchronous data - asynchronous data is just filled into empty entries.

19. Decisions - 2 • No software should preclude switching to remote operations during the middle of observing. Hence, being able to run up a second observing controller and taking over control seamlessly is ideal, but we can revert to using VNC, if necessary. • A goal is to support multiple instruments simultaneously but in practice, this will probably mean supporting a single continuum instrument and a single Heterodyne combination at one time. • ACSIS project must provide some practical method of re-reducing measurement set data.

20. Discussion groups (Wed am): • XML interface definitions (Re-convene at 11am to present proposal). • TCS (NPR, RDK, CAW - NPR’s office) • Front End (PF, ROR, WFRD, KKY - PF’s office) • ACSIS (FJO, Tony Willis, JFL, TJ - large conf. room). • Error handling • IAS, BDK, GH, XFG (small conf. room) • OMP/OT interface • FE, MF (FE’s office).

21. Other areas • Error Handling (Thusday) • Generic C/Drama SW, JIT, XML parsing • RTS Protocol (GH, XFG, BDK) • ACSIS FITS headers • Pointing and Focus • How do we re-reduce measurment sets

22. XML Feedback • How much can we change the Gemini PIT - where is the DTD for the current Gemini PIT? • Base position is an extension of the target position. • Can we always use machine aliases - e.g. TCS task is tcs@tcs.jcmt.jach.hawaii.edu • ACSIS requires 3 positions from TCS, not 2. • How much repeated information should occur in the XML? • Some FE XML could make use of attributes

23. XML Feedback • FE line source information (potentially part of a state table) may need to be passed to ACSIS (hence passed in the sequence #) • Need to understand frequency relationships a bit better - does ACSIS need to take into account frequency motion before gridding. • Frossie needs to know what coordinates the target has and how long the observation will last

24. Discussion Groups (Wed pm) • XML rationalization • TJ, FE, MF, ROR • JIT design

25. JIT design feedback • Overall ideas OK. • Need to implement • Simpler monitoring • Make REPORT, DEBUG and TEST follow paths. • Integrate TIDE and JIT? • provide TIDE_LIST functionality in JIT. • Provide TIDE parameter file in JIT. • make EPICS use optional? • Need a JitGetPath (without machine name) • Add new actions • Maybe add task entrance and exit hooks? (Exit hooks may cover early routine exits better). • Add callbacks for actions.

26. JAC BSR’s • No task should have paths to other tasks hard wired - must be able to change paths

27. Error Handling • Think about error interface • Non streaming message interfaces • Audio • AIPS++ has red and yellow criterea. • Recovery vs diagnosis • Some error messages provide no diagnostic ability, but permit immediate recovery. • Alarm State vs. Error messages • Alarm state normally changes only once • Error messages can often be repetitive if state doesn’t change • However error storms can also be caused as the result of a single command propagating through the system.

28. Error Handling - 2 • How to deal with noise spikes? • ACSIS synch task • If messages arrive out of order Synch task will mark earlier, incomplete, samples incomplete. • Front end active channels should be routed through the front end so that the Front-End can mask channels during engineering.

29. Errors handling system requirements • System should run all the time (not just when OCS is) • Should be independent of observing system • System should have very few dependencies on operating system or language • Must be able to mask/filter error notification • Assume that the error rate is not so high that the network is swamped. • It is desirable to have filtering at the error source, but this can be delegated to the application programmer. • Messages must have an associated severity. • User tool, debugging messages may be separate.

30. TODD Error Handling • Any error will abort the current recipe, aborting all current actions. • BDK will modify TODD to do this automatically if a variable is set. • Method of efficiently restarting observation TBD. • Go back to OT • Be able to specify partial recipes.

31. Message system design • Central message logger driven by DRAMA monitors • Drama Uface message handler just updates an task parameter to contain the message structure • Message logger just monitors this well known parameter in top-level tasks.

32. Message system design • AIPS++ will have a task with an identical parameter to fake the Drama message structures: • Error message structure: • TASKNAME (char[DITS_C_NAMELEN) • FLAGS (int) • STATUS (int) • MESSAGE (array char[MSG_C_LEN]) • Simple message structure: • TASKNAME (char[DITS_C_NAMELEN) • MESSAGE (array char[MSG_C_LEN]) • Status is 32 bits: • 3 bits severity, 12 bits number, 1 bit system, 11 bits facility, 1 bit user facility, 4 bits reserved.

33. Message system design - 2 • EPICS state will be monitored using TIDE or similar, and EPICS logger may also be incorporated. • NPR will be responsible for initial design • Logger will probably log to a file that will be monitored by multiple clients using a rules based system • Initial clients will be responsibility of the people on the OMP project.

34. Message handling system Email Client Scroll Window State Client Message system clients Central Message handler AIPS++ Error Sources Drama EPICS

35. XML meeting summary • ACSIS will adopt TCS source definition • ACSIS