Breakout Topics and Questions ----------------------------- STM v1.0 2006-03-27 1400MST v2.0 2006-03-28 1000MST v2.1 2006-03-28 1730MST Materials available at: http://www.aoc.nrao.edu/~smyers/aips++/uiwg/ What the Project Scientist wants to know... 1. Command Interface Background: the ALMA and EVLA SSR docs require us to provide interactive command-line interfaces (CLI) and optionally some graphical user interfaces (GUI) to the package. We want to get the look-and-feel right to let the user (of any level) process their data most efficiently. - What part(s) of other package interfaces should import for ours? (e.g. AIPS, Miriad, difmap, IDL, ?) - Is our basic CLI model right? e.g. a) enter interface for tool/task b) query/set parameter values c) save/get parameter values (from/to file) d) optionally get some help (see #4 below) e) execute task - What method of parameter setting is desired? e.g. a) param = value b) scrollable menu - Should the tool and task interfaces be the same? See #3 below... - Should hierarchical parameter lists be supported? See #3 below... - How do we best accommodate users of differening expertise levels (novice, intermediate, expert) and needs (casual user, frequent user, heavy user)? Do we need different look/feel and if so what should these be? - Does the CASApy interface previewed here and in the latest ALMA test look to be on the right track? If not, what should we be doing instead? If so, what is right and what can we do better? 2. Graphical Interface - Some GUIs are necessary, e.g. a) image/data display (viewer) b) data plotting (msplot, plotcal) c) graphical parameter setting (clean boxes/regions) d) data flagging (in viewer and msplot) Are the current tools for these on the right track? What would the users like to see? Are there better models out there? Should these be simple or have extensive functionality (e.g. viewer)? - Is there a role for GUI parameter setting (forms, tool managers)? Should the package provide a uniform GUI interface equivalent to the CLI? - Should we provide extensive capabilities for custom GUI development by the user or is Python enough? - What bits can or should be farmed off to standalone apps (e.g. the Miriad model)? 3. Tools and Tasks - Do we have the models and definitions right? e.g. "tool" - bottom (fine-grain) level of functionality, important for scripting and tool/pipeline development. In c++ "task" - a more coarse-grained bundling of functionality akin to AIPS and Miriad tasks, used to carry out basic or commonly used sequences of data processing operations with "astronomical knowledge" built-in. Most likely in c++ "procedure" - a Python script that runs a sequence of tool and/or tasks. Can be provided by project or user developed. - What should be done to rationalize the toolkit (the fundamental level beneath the tasking interfaces)? These include: a) make sure parameter names and usage are consistent across toolkit b) consolidate "set" methods, particularly to contain common params c) setdata => selectdata uniformity (perhaps through ms server?) - What is the list of key tasks to work on first? What level of combination is needed (e.g. imager+calibrater for selfcal)? What are the parmaters for these? What are the defaults? - Is extensive feedback from tasks (e.g. return variables for pipelines) needed? - Do we have the inteface models right (see #1 above)? Are there reasons to have task interfaces distinct from tools or procedures? - Should the tasking model be more "data-centric" (e.g. you choose a dataset to work on up top and the tools/tasks follow, perhaps using an "attach" command)? - Are global variables desirable? What variables should be pre-defined as global (if any)? - Should parameter lists for task and tools be hierarchical (e.g. setting a particular param=value implies a new set available) or flat (like AIPS and Miriad)? - What levels of "stickiness" for parameters local to tasks is desirable? Are all params sticky (until reset) or does the user specify which ones are sticky? - Can the open/close (e.g. of ms in tools) be hidded from the user sensibly yet still not hurt efficiency and flexibility for large datasets? 4. Documentation - What are the levels of documentation needed? e.g. a) quick tool/task info (e.g. INP) b) more extensive help (e.g. HELP) c) detailed explanations (EXPLAIN) d) Cookbooks e) Getting started docs (or merge with Cookbook?) f) user programming docs g) detailed programmer docs - What (inline) help is needed at the CLI? - What should the (online) documentation contain? - Who needs to create and maintain what documentation? (Note - there is currently no budget provided to the aips++/casa group that will allow extensive user documentation beyond basic interface info.) - Is there a role for consensual community documentation (e.g. wikipedia)? X. Other comments on stuff like: - Distribution (is this working for people?) - Known Issues (existing stuff that doesnt work right that had better be fixed) - Existing Schedule/Plan (Query to Projets: is this schedule ok?) =============================================================================== Summary for Day 1 2006-03-27 1. Agreed: Documentation inline "info", "help", "explain" highest priority, along with accurate online User Reference Manual. 2. There were several proposals for param setting look and feel (e.g. IRAF epar, sticky variables). Wanted to see demo of IRAF / Pyraf. 3. Agreed: Some rationalization of the toolkit (param naming, consolidation of set methods) should be done asap, as this has implications for the tasks. 4. Agreed: a good method for parameter save/get (tput/tget) is essential within the command interface. 5. Joe wanted: a) preliminary high priority task list + param list + defaults b) us to look over the current "tasks" (clean, feather, invert, mosaic) =============================================================================== Summary for Day 2 2006-03-28 1. There was considerable discussion of just what a "Task" was and whether differentiation between Tasks and Procedures was warranted. I propose that the definitions be amended to: "Task" - a series of operations, beyond those covered by use of the toolkit, carried out in the package through the standard tool interface (CLI and/or GUI). The Task may be constructed using Python or C++ (or any other language) but must obey the standard interface and must include standard parameter and error handling, plus full documentation. It is expected that the Tasks will be higher level functional bundling of toolkit operations but that they will be indistinguishable to tool at the user level. "Procedure" - a Python script obeying the (minimal) standard parameter interface, but not requiring the same level of error handling or documentation as Tasks. Similar to AIPS procedures. "Scripts" - a Python script that strings together toolkit or task commands, which may or may not have an interface or functional call. Basically used as examples for processing, but may have more general utiliity. 2. There is no clear need for "Tasks" at this time. Given the pending toolkit rationalization plus the complications of writing down full use cases for calibration or imaging the group could not think of a high-priority "Task" that is must-have right now. We propose to await the outcome of the toolkit rationalization (in particular selection and general argument uniformity) before reassessing the need for programmer-provided Tasks beyond the toolkit. It was also remarked that the projects had no clear definition for tasks. 3. It was thought that a mechanism (as in Pyraf) for setting arguments by setting attributes, e.g. cb.modelfit(niter=100,...) ==> cb.modelfit.niter = 100 which persist, and will be carried out at execution cb.modelfit() Note that cb.modelfit(niter=200) would use 200 instead but keep the current value, maybe queried by cb.modelfit.niter? Note that this would really make scripting better! 4. If there were Tasks, then it was strongly felt that open/closing of tools and selection of datasets should be hidden from the user (e.g. open if not already open, select if the selection has changed). 5. It was strongly felt that uniform and efficient ms selection was very important, and should include: a) uniformity across tools (as for all parameters) b) ability to transfer selection params between tools (through .par files, or objects) c) ability to associate ms selection with particular ms in the case of multi-ms inputs (e.g. to imager) d) select once until changed (particularly in Tasks) e) desirability of selection objects f) desirability of an ms-server g) efficient selection implementation (e.g. only select when needed, create new or sub ms when warranted) h) selection for data restriction and selection for data transformation (e.g. mapping ms channels to image channels) should be clear and distinct 6. Ways of better manipulating weighting selection in imager was desired (e.g. "and"-ing weights robust + taper + range) maybe through objects or a special parmam set (e.g. im.weight.type, im.weight.briggs.robust, im.weight.uvmin which is distinct from selection uvmin by the way). More efficient weighting application (not creating weight column until actually needed) might be good. 7. Agreed: Calibrating data weights/errors (as in DOCAL=2) is essential. 8. Better way to specify mapping of ms channels to image channels is desirable, e.g. im.inchannels.bchan, .echan, .nchav and/or im.outchannels.nchan, .fstart (or .vstart), .fwidth (or .vwidth) 9. A discussion commenced on what we though MUST be implemented before any CASA v1.0 release. A rough list: a) toolkit rationalization (at some level) b) data weight calibration c) inline documentation uniform and correct across package d) some viewer capability (qtviewer) in CASA e) a set of basic scripts (preferably but not necessarily Procedures) covering fundamental processing use cases f) some key functionality (filler, fitsio, ...) We will work on this further... 10. We liked what we saw in Pyraf (in the tutorial) but wanted to investigate it further.