Juergen ran these by me earlier, but of course I've probably forgotten what I said about them :( I'll try to reconstruct... These are just comments at this point, and have not been put in the system. On Fri, 9 Oct 2009, Juergen Ott wrote: > - plotms does not rescale the data after flagging. A reload is needed or some > manual rescaling. WOuld be good to have a way to rescale easily. STM: Sometimes plotms rescales when you dont want it to, and sometimes doesnt when you do! We probably need a "refresh" button to just do a redraw with rescale rather than having it happend when you do something (or not). > - I had trouble to copy/paste from the logger to some other window. I ran > casa remotely on a linuxbox from my Mac, which may have something to do with > it. STM: Yeah, thats a known issue with the qt logger (on the Mac the logger is actually quite different, more stripped down). In general it often fails to copy multiple lines. I end up going into the casapy.log file and grabbing the text in the editor. Longer term we should decide what to do with the logger. > - suggestion: would be nice to have a task that pulls the available > calibrator information from the web (fluxes, quality and uvranges for > calibration, etc) STM: This would be a job for the EVLA SciOps to formulate and maintain such databases. I am not inclined to do anything with the current hodgepodge of Calibrator Manual (a big text file) or other databases. This could be done in python, might be a good small project for an intern or student. > - maybe CASA could find the models of calibrators for a given frequency > automatically. Looks like one has to dig deep in the directory structure > right now. STM: Could have it check the paths to ./ and $CASAHOME/data/NRAO/VLA/CalModels (and any other standard area) when given a modelimage name. > - autoscale of data in plotcal appears to work only on both or none axis. > Would be good to allow autoscaling on just one axis. (but as I hear plocal > will go into plotms which has that option) STM: I'm afraid plotcal is deprecated and we are awaiting getting cal plotting in plotms. Will not do anything to plotcal other than serious bug fixes. > - I would appreciate a way to flag of edge channels by giving one or two > values, like 20,30 (flagging first 20 and last 30 channels). It is a bit > cumbersome to figure out the channel numbers, say 0-20,235-255) STM: Originally had proposed the ability to use percentages in channel selection syntax, e.g. spw = '0:10%~90%'. Could ask for this from Sanjay. I guess the problem is in the "last" channels, could also have a syntax like spw='0:10~-10'. > - flagdata: I was very confused by selection and cliprange and spw keyword > etc. Looks like the selection is different from the clip expression which can > flag inside out outside the expression. But it appears that the > inside/outside flagging is independent from selection. It just was pretty > conusing > In addition, I was also confused about the data criteria to flag versus what > data is flagged, e.g., 'ABS RR' is that what flag looks for to find the > extreme values? Or is it the stuff that is actually flagged? In any case I > think both should be full stokes as default. STM: I'm not that happy with the overloading of the clip syntax on manualflag (e.g. its set up so the default is to flag everything meeting selection). I would somewhat prefer the 'manualflag' mode to not have clipping, and have a separate clip mode. Not that thrilled with the clip syntax either, but its useable I guess. You can see the sordid history in JIRA, e.g. the 'ABS RR' comes from an Ed ticket CAS-212. See CAS-295 for similar suggestions. > - suggestion: when I reduced data, I frequently switched between two or three > different ways to plot the data. Like time-amp, channel-amp, real-imag, etc. > It was a bit cumbersome to always have to switch the axes, averaging > parameters etc. I wonder if the parameters of say the last 5 plots could be > stored and listed e.g. in the upper drop down menu? Then one could select a > previous plot easily without going through all the changes in settings. STM: I tend to change the selection when I change the axes, so I wouln't find this that useful. But having a dataset/axes/selection "history" in a History menu might be helpful. > - suggestion for plotms: flag individual visibilities by clicking in the > plane, which selects the most nearby datapoint to be flagged STM: would need a "bombsight" icon or something to do this I guess. Also would be nice to have a clip function. But I dont think these are high priority. > - I was also confused about the use of 'a,b' versus ['a','b'] formats for > inputs in selections, etc. STM: All selections are single strings, e.g. spw = '0:10~220,1:30~210'. Some tasks take lists of things (like selections in flagdata) to allow multiple processing to be done at the same time. I think this is consistent throughout, but if not should be noted. The safe thing is to give a single string. > - there should be a good way to set the rest frequency in the uv data. This > would allow to display data as a function of velocity (eg plotms). Very much > needed when different data is being combined and for determining the channels > that one would like to image in a cube STM: Most tasks that need it like plotxy (eventually plotms), cvel, clean, have the restfreq (and frame) parameter. Relying on something inside the MS is fraught with peril. See http://casa.nrao.edu/Memos/229.html#SECTION000615000000000000000 for a description of the SOURCE table which can have multiple rest frequencies. Would be good to have a consistent idea of how we want to use metadata like this which will come through the sdm. Then can have tasks (e.g. vishead) set this. > - also I was surprised thet the task 'clean' would happily overwrite a > previously created dataset. Found that dangerous but maybe this is intended? STM: Its true that if you run clean again with an existing imagename but have changed key size params, it will start over rather than terminating with a warning. Should we have it do that? > - the tools have a regular fft available but maybe this could also be a task? STM: I think this is still a fairly uncommon operation, and thus its simple enough to use ia.open then ia.fft. But I havent tried this either! > - in 'clean' I would love to see options to have the following outputs dirty > cube/image, clean components cube/image, clean components convolved with the > clean beam cube/image, residual cube/image, in addition to resdiual+clean. > Its possible now to recreate them from the resdidual and image output. But > since they are all calculated internally anyway,m it would be nice to have an > option to write them out. An application would be the flux correction as > suggested by Gustaafs paper from a few years ago. STM: It already outputs .image, .psf, .flux, .residual, .model, .mask so I would prefer not to see more by default! Note that im.clean makes you explicitly set names for some of these (done for you in the clean task). Could have an outimages parameter, e.g. outimages = 'residual, psf, flux, dirty, restored'. Note that not all these are really calculated internally or used, so its extra work (or extra space to save). For big images it would probably be good to have the user control what is actually kept. > - even simple flags cause a redraw in plotms, which is very time consuming > for large datasets STM: see above, it might be good to have less of these redraws done automagically > - time labels in both, plotms and plotxy/plotcal overlap each other STM: known issue. Should add to CAS-1415 to remind George. > - I encountered a flagging error in plotms: "desired slice extends beyond the > end of the array" maybe specific to my datasets STM: what triggered this? > - when both, the viewer and plotms are open at the same time (both run from > within casa), they appear not to behave independently. e.g. drawing a box in > plotms will bring the viewer in the foreground STM: Ive not seen this, but if repeatable should bring to attention. Might be a dbus thing? > - flagging by reason i guess is possible, I need to look into this a bit > more. But I would like to avoid unflagging system flags created from the EVLA > in the raw dataset. STM: The initial flags are in the .flagversion on fill (but not split), plus backups if flagdata is used. Use flagmanager to list and replace old versions. > - for some applications I would have found it nice to have wildcards possible > for mutiple filenames in vis inputs STM: Some tasks take this (e.g. I think concat might) but its fraught with peril if order is important (since file globbing can give strange orders). See the SMA example of Crystals to see how she has to do this: http://casa.nrao.edu/Doc/Scripts/sma_reduction_example.py Should probably give an example in the Cookbook. > - plotsymbol '-' appears not to connect lines in plotcal STM: known plotcal deficiency (will not fix), make sure plotms does better! Need to get a "connect" option in if not there already. > - imaging: in clean i tried to image a data cube (mode='channel') but got the > following error: > > 0%....10....20....30....40....50....60....70....80....90....100% > 2009-10-09 03:18:29 SEVERE Exception Reported: SkyEquation:: PSF > calculation resulted in a PSF with a peak being 0 or lesser ! > *** Error *** SkyEquation:: PSF calculation resulted in a PSF with a peak > being 0 or lesser ! > **** Error **** SkyEquation:: PSF calculation resulted in a PSF with a peak > being 0 or lesser ! > > however, the task works it but works just fine in mode 'mfs' STM: please point me to this example so I can see if this is a bug (e.g. after the current clean problems are fixed). > - finally, once I tried to split the data first into primary calibrator, > secondary, and source. It was also a complicated data set because the > bandpass was at two offset frequencies (different spw) which needed to be > merged into one at the intermediate frequency. This was not a good idea. I > could not transfer calibration tables between the different measurement sets. > So I suppose that split should only come after all the calibration is done... STM: Have to ask George about this, eventually we want to be do stuff like this to transfer calibration from small MS with calibrators to large target MS. > ok, so much for now. I think I got reasonable calibration but haven't checked > the accuracy yet. I also still need to look more into imaging where I could > not get a good result yet since I had the trouble as described above. > Cheers, STM: Thanks! If you need help let us know.