1 / 35

Summary

Summary. Nick Rees. Overview. ACSIS AIPS++ development environment Error timeouts in low-level systems Propose XML interface in JIT JIT. Observing Tool. ACSIS Re-reduction problems How do we re-reduce the MS data during the day? Iterator use - TODD vs OT

skyla
Download Presentation

Summary

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. 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

More Related