Date - 2000.06.24 - 2000.06.28 Tester - S.T. Myers (AOC) Platform - Linux (kernow) Version - Weekly (1.4 build 120) Note: Below are some notes pertaining to aips++ that have been suggested by discussions with some of the students trying out the program during the summer school tutorial, as well as some of my own recent experiences ------------------------------------------------------------------------------- 1. The new version of imager where the fuctions can be displayed by category is an improvement, but under these menus it would be useful to order the functions by functionality and likely order of use rather than alphabetically (keep alphabetical order in the "all" group). For example, image should default to image.view() and the setup group should be first in the list with a default to setdata (with setimage second), with the setup - setdata being what appears after the tool is constructed. One thing new users have problems with is remembering to actually call the functions like setdata and setimage - there is no indication whether you have already set these or not. 2. New users seem to get confused between the "image" tool and the "imager" module (especially the imager.image function!). Some suggestions: - rename the "image" tool of module "images" to "imagetool" - rename the "image" function of "imager" to "makeimage" - offer access to the "imagetool" from inside imager as an "image" function (saving having to go outside to a separate tool) 3. If you forget to close a tool accessing the ms, it often hangs when you start another tool (with that annoying "waiting for write lock" error). It should issue an alert asking the user to detach the other tool from the ms rather than just locking up (sometimes even getting out of the offending tool doesnt help and the only recourse is to exit aips++). Also, it seems that in the case of an ms function, you need to actually use "Done" rather than "Dismiss" from the GUI, which doesnt seem right. 4. There are some useful basic "AIPS-like" functionalities that are missing or are difficult to make: - The ability to get a plot of the antenna locations in the array as you get at the end of a PRTAN listing - The ability to get a succinct and easily readable scan listing of the data in a ms as in OPTYP="SCAN" of LISTR - Output similar to the "GAIN" and "MATX" listings from LISTR Some more advanced additions need to be added soon: - There needs to be uv-plane (and image plane) modelfitting as in DIFMAP and AIPS - The ability to work with multiple measurement sets concurrently without "dbconning" them - this should be transparent to the user - graphical data editing (at least two modes, like DIFMAP vplot and AIPS tvflg for example) which will double as visualization (ie. a visualization tool which also can edit) 5. Some possible enhancements that will improve the "look and feel" of the aips++ GUI. My attitude (and I think many others) has been that the current GUI was a stopgap until a better one was implemented. Other than bug fixing, I think a reworking of the GUI and other aspects of the user interface are the next most important things to tackle: - Most of the GUI seems to be form-based "fill in the blank" pages, essentially just corresponding to the glish level commands. It would be better to shield the user from the individual functions, and to have some sort of control panel that describes the state the tool, ie. what things have been set and to what. The default should be to select on all the available data - Although the "map" tool tries to bridge between the imager and calibrater modules (it creates one of each), it would be good if you were not just faced with some blank slots and have to bring up separate list managers to select and run stuff. Again, the GUI should actually use some graphical interface to the data and these form-based menus are NOT graphical. - The GUI should emphasize the interconnections between the uv-data, the selection/filtering/masking, the calibration, and the images and models. Some sort of "construction palette" where the user selects datasets, tools, filters, modelers, calibraters, and output images and models would be ideal. This is the de-facto standard in computer graphics, audio, and visualization (eg. IDL) and would be a very good model to use here. Is something like this within the capabilities of the aips++ programmers? 6. Ive been thinking about a possible graphical paradigm for aips++ interferometer data processing: +-------------+ +-------------+ +-------------+ | | | | | | | ms file 1 | | ms file 2 | | ms file 3 | ... etc | | | | | | +-------------+ +-------------+ +-------------+ | | | +---------------------------------------+ +----------------------+ | | | | | uv plane filter engine | | uv vis-ualization | | |--| engine | | ( mask, weight, combine, gain ) | | ( plot, edit, stat ) | | | | | +---------------------------------------+ +----------------------+ | | | +---------------+ +---------------+ +----------------+ | | | | | | | calibrater | | imager | | modelfit | | engine | | engine | | engine | | ( solvers ) | | ( fft,dft,? ) | | ( parameters ) | | | | | | | +---------------+ +---------------+ +----------------+ | | | +---------------------------------------+ +----------------------+ | | | | | image plane filter engine | | image visualization | | |--| engine | | ( mask, pbeam, mosaic, models ) | | ( plot, fit, stat ) | | | | | +---------------------------------------+ +----------------------+ | | | +-------------+ +-------------+ +-------------+ | | | | | | | image 1 | | image 2 | | image 3 | ... etc | | | | | | +-------------+ +-------------+ +-------------+ Each of these 5 "layers" might have a GUI Tool associated with it, in which the individual modules can be setup with inputs, outputs, and interconnects. +--------------------------------------------------------------+ | | | | | ms Layer (1) contains: ms datasets and selections | | | | | +--------------------------------------------------------------+ +--------------------------------------------------------------+ | | | contains: uv masks, flags | | visibility engine Layer (2) filters, flagger, visplot, | | weight & calibration overlays | | | +--------------------------------------------------------------+ +--------------------------------------------------------------+ | | | contains: imager, calibrater, | | transform engine Layer (3) modelfit, dragon, mosaicer, | | fft, dft | | | +--------------------------------------------------------------+ +--------------------------------------------------------------+ | | | | | image control Layer (4) contains: mask, primary_beam, | | mosaic, model_components | | | +--------------------------------------------------------------+ +--------------------------------------------------------------+ | | | | | image Layer (5) contains: images, components, selections | | | | | +--------------------------------------------------------------+ which show roughly what functions fall where. The problem with this is that its fairly linear in structure (between layers) with some parallel processing (within layers). I think we will need to break things up into some sort of "Layers" for managability, but the same functions (by default many of the lower level functions like measures and quanta, and maybe others) can be "plugged" into different layers. The idea is each layer is a separate large palette window hopefully with drag & drop tools that get plugged in, with I/O and interconnect pipes between them. There would be an overall layer navigator to choose between the layer that is being edited. Note that in this formulation, the user "assembles" a group of tools and functions, connects them together, assigns parameter values, and then executes the whole thing. The assembled macrofunction can be saved as a whole and read back in to use again. This is more like what I think the GUI should be - a graphical method of assembling the aips++ tools and functions, much like Visual C is for c coding, rather than the current fill-in-the-blank and click-to-execute. Of course you could build small tools, or access the tools themselves like you can now, to just drive aips++ like the current GUI (we would just keep the current GUI as-is probably). Any comments?