 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1556 |
|
W. Young
NRAO
1997 March 26
A postscript version of this note is available.
The changed nature of computing since Observe's introduction have caused us to review Observe's current status and reflect on how we might "modernize" it. Modernization might include:
There are two options:
Option 1 leaves things much as they are. Current documentation would be updated and there would be some programmer documentation. This option doesn't improve the interface for the observer or improve the maintainability of Observe. Screen real-estate in the current version is very limited, it is difficult to add new features. Information is hidden and navigation is not always straight forward.
Option 2 requires rewriting and to some extent redesigning Observe. A redesign would allow a more natural interface (and avoid the keypad altogether). The current version closely couples the user interface with program functionality. A redesign would allow loosening the coupling, so the user interface and scheduling/file-checking functionality are more logically separated.
There are several choices for an event-driven program:
In all choices, almost none of the existing code will be preserved. Translating many of the concepts and algorithms from VLA Observe to the new version should be fairly straight forward.. The AIPS++ Measures code will be used for Doppler corrections, coordinate and time conversions (probably as a server object). All AIPS++ tasks/objects use the Measures code, so Observe's numbers will be consistent with those of AIPS++.
A "Classic X11" based program would require compiling and linking for each platform. This is very much a classical approach for providing software. Users down-load Observe and ancillary files to their local machines, configure for their local environment, and run Observe on the local machine. Often we see files submitted using an out-of-date version of Observe. Porting to a non-supported architecture while not difficult does require time and some effort. Often when a port is needed, a computer of that architecture is not available locally.
Tcl/Tk and GlishTk are a Tk-widget-based X11-toolkit called from a command interpreter. Tcl/Tk uses the wish shell and GlishTk is the AIPS++ command interpreter. Writing Observe in GlishTk provides a straight-forward interface with existing AIPS++ code. While being quick-to-prototype, both have their drawbacks. Some problems with Tcl/Tk include:
Problems with GlishTk include:
A Java based program offers the hope of "write-once run-anywhere" (no porting issues). A user connected to the net could be guaranteed the latest version (including the latest calibrator positions and NRAO defaults). Observe seems particularly well suited to "net". Links are possible between Observe and the most-current (best?) advice on observing strategies, interference problems, and other timely observing information. User could also down-load the Java byte-code and run Observe locally. The biggest drawback to Java is, "it is cutting edge".
There are three phases in redesigning and reimplementing Observe:
Considering the nature of observe, the language of choice is Java. Why Java?
The following list is a "back-of-the-envelope" targets list that would be refined after the design work. Time estimates indicate the relative amount of work (rather than the actual time). The time required to implement the GUI is likely to be independent of implementation (Java, X11, Tcl/Tk, or GlishTk).
Testing individual components and programs will follow the AIPS++ model. As we finish parts of the project, we prepare test-cases with known results. At regular intervals the test-cases are run and compared with expected results. If a test fails we can track it down before it becomes a bug report. Also, we can run the test-cases after any changes to ensure no unforeseen problems have occurred. Testing the GUI is more labor intensive and will require interactive testing by NRAO staff members.
| VLA Observe - Targets |
| Phase 1 - Design - deliverable (2 weeks) |
| rudimentary design of current Observe |
| redesign Observe |
| Phase 2 - Foundation (17 weeks) |
| ASCII Text to Observe file - deliverable (9 weeks) |
| conversion into Java |
| parser |
| user defined |
| observe file |
| interface with AIPS++ Measures |
| scheduling routines |
| frequency checking |
| output routines |
| unit testing |
| Reports - deliverables(4 weeks) |
| analysts |
| scheduling |
| frequency |
| time-on-source |
| summary |
| unit testing |
| Databases - NRAO/user (3 weeks) |
| frequency setups - deliverable |
| calibrator - deliverable |
| source - deliverable |
| position |
| orbital elements |
| interpolated from table |
| Integration into a scheduler - deliverable(1 week) |
| Phase 3 - Interactive Interface (20 weeks) |
| Scheduler GUI (10 weeks) |
| screen layouts - deliverable |
| source catalog - deliverable |
| frequency/correlator setups - deliverable |
| scan editor - deliverable |
| visual loser - deliverable |
| LO calculator |
| band/interference plots |
| Doppler tracking |
| observe file viewer - deliverable |
| scan contraction/expansion |
| starting conditions - deliverable |
| editing schemes |
| User Testing (4 weeks) |
| Planning Tools - deliverables (2 weeks) |
| uptime |
| uv-coverage |
| az-el plots |
| calibrator flux history |
| Distribution - deliverable (1 week) |
| Documentation (4 week) |
| programmer - deliverable |
| user - deliverable |
| tutorial |
| on-line help |
| Phase 4 - Futures (?) |
| suggested schedule |
| time range, source, frequency, pick calibrators, etc... |
| optimal scheduling |
| incorporate VLA plan |
