Date: Tue, 11 Apr 2006 11:34:51 -0600 From: Frazer Owen Subject: Comments: First draft of UIWG report Executive Summary The draft Seems to miss what for me was the most important point: that we need an interface which allow adverbs to be sticky. That is one needs to be able to enter a parameters at the command line or through an epar-like interface and keep them set to those values until one changes them. We also need a mechanism that allows parameters to be set at the command line at the time the task or tool is run. The current syntax is OK for this purpose. Many of the individual requirements seem to assume what I outline in the first paragraph but this is not said clearly up-front. 2.1 Timescale Phases seem wrong for EVLA. EVLA needs major support for CASA for commissioning WIDAR starting Q3 2007. Q3 2008 is much too late. That date may be appropriate for ALMA. It is not clear to me that we can have one timetable for both EVLA and ALMA. Of course, we can't expect as much to be ready in Q3 2007 as in Q3 2008. What we need then is a core set of capabilities and then a plan for a collaboration between In-house EVLA astronomers and CASA developers first to get CASA to perform the calibration and then to begin doing imaging. To me that should be the definition of full support for commissioning. Given that priority for EVLA, I see less priority for getting the package ready for outside users. Clearly we need to work on that but it should be lower priority compared to getting EVLA to work with CASA. 2007 Q3 is really too late for a major deployment aimed at getting VLA Users to use CASA. In discussions with Steve, it seemed that one might keep the 3 times for the timescales but redefine somewhat what was expected at A, B, C. In particular, B might be basic EVLA commissioning support plus a beta release (not really "mature") for outside users, C: support for both ALMA and EVLA commissioning plus a "mature" CASA release. Given my problem with the defined timescales and apparent priorities it is hard to make comments on the detailed requirements but I will try. I only have a few detailed comments on individual items: U1-1-R1 Maybe the point about sticky parameters should be made here or at least just after this requirement. U1-1-R4 Whatever the Timescale for this requirement, it should have Priority 1. U1-1-R7 to U1-1-R9 All these should have the same priority and timescale. Probably Priority 1 and timescale B. That is SAVE/GET and TGET/TPUT are equally important. If anything TGET/TPUT is more important. U1-2-R6 I would argue that when one uses this method of setting parameters they should be sticky (not just until the task as been executed). The priority here should be 1. ============================================================================== From: Steven T. Myers Subject: Re: Comments: First draft of UIWG report On Tue, 11 Apr 2006, Frazer Owen wrote: > The draft Seems to miss what for me was the most important point: > that we need an interface which allow adverbs to be sticky. That > is one needs to be able to enter a parameters at the command line or > through an epar-like interface and keep them set to those values until > one changes them. We also need a mechanism that allows parameters > to be set at the command line at the time the task or tool is run. The > current syntax is OK for this purpose. This is UI-2-R6 but I agree this should be moved into section 1 and made clearer. You seem to be the major proponent of setting sticky parameters outside the CLPI. I think the right mechanism to do this is suggested in UI-2-R6. I am somewhat hesitant to move this to P1 but could do so if there is a consensus. In SSR (e.g. ALMA SSR) delibrations, there was a definite bias against global parameters, hence the notion that you save non-default "defaults" or old values explicity and must do something to recall them. I think we agree on the parameter setting, saving, restoring features of the CLPI (SAVE,GET,etc.). One question I have is should we ask for the CLPI to be scriptable from the OS or Python? Many of us are used to writing a csh (or other such) file to run AIPS or other packages. One might think of asking for something like: inp clean << EOF get clean.par niter = 1000 threshold = '0.01Jy' go EOF or from a runfile inp clean runfile='clean.run' Or do we just want the CLPI to be interactive only (simpler)? > Many of the individual requirements seem to assume what I > outline in the first paragraph but this is not said clearly up-front. > 2.1 > > Timescale Phases seem wrong for EVLA. EVLA needs major > support for CASA for commissioning WIDAR starting Q3 2007. Q3 2008 > is much too late. That date may be appropriate for ALMA. It is not clear > to me that we can have one timetable for both EVLA and ALMA. Of course, > we can't expect as much to be ready in Q3 2007 as in Q3 2008. What we > need then is a core set of capabilities and then a plan for a collaboration > between In-house EVLA astronomers and CASA developers first to get CASA > to perform the calibration and then to begin doing imaging. To me that > should be the definition of full support for commissioning. > > Given that priority for EVLA, I see less priority for getting > the package ready for outside users. Clearly we need to work on that but > it should be lower priority compared to getting EVLA to work with CASA. > 2007 Q3 is really too late for a major deployment aimed at getting VLA > Users to use CASA. > > In discussions with Steve, it seemed that one might keep > the 3 times for the timescales but redefine somewhat what was > expected at A, B, C. In particular, B might be basic EVLA > commissioning support plus a beta release (not really "mature") > for outside users, C: support for both ALMA and EVLA commissioning plus > a "mature" CASA release. Agreed, and phrasing in the timescale definitions changed (keeping the current times). > Given my problem with the defined timescales and apparent > priorities it is hard to make comments on the detailed requirements but > I will try. I only have a few detailed comments on individual items: > > U1-1-R1 > > Maybe the point about sticky parameters should be made here > or at least just after this requirement. Agreed. Seems the right place to do this. > U1-1-R4 > > Whatever the Timescale for this requirement, it should have > Priority 1. If thats the consensus. This seemed more like a neat option, rather than a critical item, to me. I thought the most basic thing was to set param=value pairs, look at 'em, get help, save/get pars, and go &c. Putting it P2 doesn't mean that it goes away in any event. > U1-1-R7 to U1-1-R9 > > All these should have the same priority and timescale. Probably > Priority 1 and timescale B. That is SAVE/GET and TGET/TPUT are > equally important. If anything TGET/TPUT is more important. Possibly. I am hesitant to move everything to P1. > U1-2-R6 > > I would argue that when one uses this method of setting > parameters they should be sticky (not just until the task as been > executed). The priority here should be 1. Move to UI-1 as noted before. Wording will be made clearer. ============================================================================== Date: Wed, 12 Apr 2006 08:11:24 -0600 From: Frazer Owen Subject: Re: Comments: First draft of UIWG report Steven T. Myers wrote: > On Tue, 11 Apr 2006, Frazer Owen wrote: > > > The draft Seems to miss what for me was the most important point: > > that we need an interface which allow adverbs to be sticky. That > > is one needs to be able to enter a parameters at the command line or > > through an epar-like interface and keep them set to those values until > > one changes them. We also need a mechanism that allows parameters > > to be set at the command line at the time the task or tool is run. The > > current syntax is OK for this purpose. > > This is UI-2-R6 but I agree this should be moved into section 1 and > made clearer. > > You seem to be the major proponent of setting sticky parameters > outside the CLPI. I think the right mechanism to do this is suggested in > UI-2-R6. I am somewhat hesitant to move this to P1 but could do so if > there is a consensus. In SSR (e.g. ALMA SSR) delibrations, there was > a definite bias against global parameters, hence the notion that you > save non-default "defaults" or old values explicity and must do > something to recall them. I thought there were clearly others who liked them. Sticky parameters are very different from global parameters. It also appears to me that other things you say in the document imply what I mean by sticky parameters. I certainly cannot support the result of the Focus Group without that concept. > I think we agree on the parameter setting, saving, restoring > features of the CLPI (SAVE,GET,etc.). One question I have is should > we ask for the CLPI to be scriptable from the OS or Python? Many > of us are used to writing a csh (or other such) file to run AIPS or > other packages. One might think of asking for something like: > > inp clean << EOF > get clean.par > niter = 1000 > threshold = '0.01Jy' > go > EOF > > or from a runfile > > inp clean runfile='clean.run' > > Or do we just want the CLPI to be interactive only (simpler)? By default, I want each task to remember the parameters that have been used for the previous run if they have been been set with the sticky syntax. That is task.param=X or the epar-like input approach. I don't want to have to save the parameters each time. Of course, one can restore the defaults. I also want a method of running a task without having the parameters stick. That could be the current syntax with task(para=X). The TGET/TPUT function might recover the inputs from the last use of the task regardless of how they were set. Also it should be possible to TPUT the inputs of a task to a named file so that one could a particular set back at some time in the future. The TGET/TPUT functionality seems quite important to me and needs to have a very high priority. There also needs to be a an AIPS-like SAVE/GET functionality, which saves and gets a snapshot of all the parameters for all tasks/tools at a given time. This package of stickiness and different ways to have parameters available from past usage is the most important aspect of the User interface that we currently do not have in my opinion. ==============================================================================