Date: Sat, 01 Apr 2006 18:26:09 -0500 From: John Hibbard Subject: Re: A few uber comments (fwd from Walter) I'm going to wait to talk to Crystal and Ed after they get back before responding to the larger thread (including stuff David brought up, and the recent points raised by Michael). But I wanted to make two quick points: 1) for tasks, I think there should be a task.inp(verbose=T) or inp(task, showall) or inp.showall or something that shows all inputs (for the clean example, this would be the equivalent of specifying all possible alg choices). I worry that someone (like me) would forget all the things a task might do or need, and might actually want to page through pages and pages of inp parameters to remind himself. 2) Several people seem against the separate "Select" function. I was too at first, but I'm beginning to think it would be quite useful. From what people have written, I think they think select doesn't do anything; but that was the point of making it separate: if I understand correctly, select would actually go to disk, open the ms, and read into memory the appropriate data. So I could imagine wanting to do a select, then perform many operations on that selection (plotting, weighting, flagging, etc) before or after my clean. So having a separate select function would be expedient. But I agree that people might want to have select specified withing the clean task so you don't have to run it separately. In this case, my understanding is that we wanted the system to test the current selection criteria against the ones that were used last time data was selected, and do nothing if they are the same (so we avoid unnecessary open-close's on the same dataset). -john =============================================================================== Date: Sat, 1 Apr 2006 17:26:32 -0700 (MST) From: Steven T. Myers Subject: Re: A few uber comments (fwd from Walter) On Sat, 1 Apr 2006, John Hibbard wrote: > I'm going to wait to talk to Crystal and Ed after they get back before > responding to the larger thread (including stuff David brought up, and the > recent points raised by Michael). But I wanted to make two quick points: > > 1) for tasks, I think there should be a task.inp(verbose=T) or inp(task, > showall) or inp.showall or something that shows all inputs (for the clean > example, this would be the equivalent of specifying all possible alg > choices). I worry that someone (like me) would forget all the things a > task might do or need, and might actually want to page through pages and > pages of inp parameters to remind himself. Hmmm, interesting. Would be easy to add a "verbose" argument that you could toggle on command line or in the interface, e.g. inp task ['option1','option2',...] verbose=T > 2) Several people seem against the separate "Select" function. I was too > at first, but I'm beginning to think it would be quite useful. From what > people have written, I think they think select doesn't do anything; but > that was the point of making it separate: if I understand correctly, > select would actually go to disk, open the ms, and read into memory the > appropriate data. So I could imagine wanting to do a select, then perform > many operations on that selection (plotting, weighting, flagging, etc) > before or after my clean. So having a separate select function would be > expedient. The main reason to have a SELECT task available outside the tasks was so that you didnt have to replicate the long parameter list inside each task. There are currently 9 params in imager.setdata, including the catch-all TaQL select string which allows us to have this few. I remind you all that the general NAUG consensus was that TaQL was reviled and that we wanted selection params for more of the common selection options (like antennas, baselines, timeranges, etc. (more like the long page of selection in the old glish msplot tool - take a look at that for an eye-opener). Now for imager you would have to have this long param list available for each ms (though the new selection scheme that is still being worked on will allow better common selection between different datasets). I think we should really think carefully whether it is absolutely necessary to add these 12+ parameters to every ms-based task, or whether its too much to ask the user to SELECT before doing something else. It does not seem so to me, and what you gain is the ability to have a single place to select, plus the ability to tailor this to make multi-ms selection easier without mucking in the other tasks. Plus I think if we ever move to ms objects and an ms-server the SELECT task approach will be more closely aligned with the code underneath and thus better to use the full power of ms-servers. But thats further off... > But I agree that people might want to have select specified withing the > clean task so you don't have to run it separately. In this case, my > understanding is that we wanted the system to test the current selection > criteria against the ones that were used last time data was selected, and > do nothing if they are the same (so we avoid unnecessary open-close's on > the same dataset). Yes, that would be there. Its trickier than if selection were relegated to the single SELECT task since it knows its own params. We would have to be sure to tie together all tasks that use ms selection as CALIB could have modified the selection since the previous use of CLEAN for example. Possible certainly, but not as simple as a single selection... -s =============================================================================== Date: Sun, 02 Apr 2006 11:51:26 -0400 From: John Hibbard Subject: Re: A few uber comments (fwd from Walter) I think enough people think a separate "Select" task is useful enough that it should be on our wish-list of separate tasks. However, the question of whether to make tasks such as "clean", "calib" etc truly standalone (i.e., include the 9 params in 'select' within 'clean') is separate, and sounds like a purely User Interface issue. It sounds like we are split on this issue. I don't feel strongly either way. Whether you see 9 extra parameters within clean, or always have to epar a select before a clean is a "pick your poison" type of question. What would be cool would be for the epar form-like interface to have "tabs" for inputs, like David showed us for the qtviewer 'adjusts'. A tab for select, a tab for output, a tab for each "alg", a tab for weight. This may be difficult to do with the text-editor manifestation (but not impossible - it would be quite similar to the iraf epar hierarchial parameter lists, where you decend into each list). Personally, I would vote for the latter, in which case including a 'select' tab within clean would not be a big deal (but also keeping a separate 'select' task). -john ===============================================================================