Suggestions for the SD side of CASA. These were compiled as a result of the difficulties/confusions that were most commonly voiced during the NAASC SD training kindly provided by NAOJ Dec. 7-8, 2011. *** It was noted that there is little consistency between the interferometric and SD syntax in CASA. While a complete reconciliation would be very time consuming (and there are other users of the SD package beyond ALMA), there are a few concepts where this seems particularly confusing for ALMA users and would probably be worth the effort: (1) The task iflist (and its contrast with listobs) and the use of IFNO instead of spw in general throughout the SD package. Much effort has been expended in training the community on the meaning of spw. It is even used throughout the ALMA technical handbook to explain the spectral window concept/properties. The current mode of switching between ms and scannable and then back again further exacerbates the differences between the two sides of the package. It would seem advantageous to reconcile the two packages to have the same syntax spectral window syntax. (2) For imaging you convert back to ms, so suddenly the user needs spw syntax. (3) In sdimaging, the specification of the desired output cube uses different syntax compared to the clean task. For example "step" instead of "width" etc. These differences will make it more difficult for users to create SD and interferometric images on the same grid as used for the interferometric data for ease of feathering in Cycle 1. Suggest trying to gauge more widely how detrimental these issues are for general ALMA users to see if some effort on this front is warranted. If deemed too disruptive to more general use of SD CASA for other single dish telescopes, perhaps ALMA specific task wrappers are warranted. *** The concept of what constitutes a "scan" in the SD package is currently very confusing (at least for position switched data): (1) The current highly variable content of scans produced much confusion. Some scans contain very little data while others quite a lot. Thus plots of the "scans" show wide variation in S/N and makes data inspection confusing. (2) The combination of "on" and "off" measurements into the same scan, and the practice of only reporting the position of the "average" position makes it very difficult to understand what is happening -- first impression is that the raster wasn't taken at the right position. Because of (1) the position of the raster also appears to change from scan to scan, further confusing the issue. Indeed, it is non-trivial to find out what the off position was - this is only possible through browsetable which shows it in decimal degrees. (3) It isn't possible by looking at sdlist or any other way I could discern that the data were position switched, except by noting that the intents contain "on" and "offs". Indeed, beyond this clue, its not possible to tell that this is SD data at all. This is more minor but it would be nice if the data taking mode were captured in the metadata, certainly from an archive perspective. One possibility to address 1 & 2 would be to change the filler so that each row of a raster (or single pointing) be filled into a unique scan with the associated "off" appearing in the subsequent scan. Then you would see the average position of the raster row and independently the off. *** Confusions related to the sdaverage calibration task: (1) The name of this task seems secondary to its main overall purpose of calibration. Suggest renaming to something that evokes calibration for ease of user intuition for what tasks to use. (2) The organization of the task could be improved to relate the averaging features to the observing modes that they can be used with. For example it is possible to pre-time-average the data in each scan, in position-switched data which would result in the data being un-calibratable. Perhaps the averaging features could be made expandable parameters to each mode so that you get ones that make sense as a function of mode. In that case post-calibration averaging could be enabled in a different stand alone task. *** Polynomial used in sdbaseline is "regular". Chebyshev (of first order) is likely a more stable, better option. *** After starting active version of sdbaseline, it was difficult to quit out of it.