CIAO features users liked the least
Back to the Survey9 - long parameter inputs 14 - hidden parameters 18 - Slow, SEGVs happen occasionally, require lots of memory 19 - The inability to run multiple instances of the same tool at the same time, even on different machines, without complicated setup (using local parameter files, etc). It is extremely time consuming to, for example, extract spectra for 2000 sources one at a time on a single machine while other available machines sit idle. 24 - I don't know. I don't really use the ones I don't like. 28 - syntax is nonintuitive and awkward 29 - some of the low-level tools (dmlist,dmcopy) are much less intuitive than their ftools counterparts. Also, something like xselect would be nice. 33 - Many tools require an unreasonable amount of memory and cpu time. 35 - Grating threads are not very straightforward. 38 - sherpa - absolutely useless.... 39 - Very frequent updating of CIAO. When is it going to be stable ? 43 - sherpa's inscrutable, context-sensitive commands chips extreme verbosity for simple tasks. slow (any equivalent, e.g., fselect vs dmcopy, is faster). hybrid syntax (slang and command line) large code size; large parameter sets; frequency of segv's 47 - Execution speed. Various tool instabilities. Obscure error messages. 60 - Sometimes it is not convenient to download the thread, the website is very slow. 62 - chips - there are already plenty of plotting packages in the world - why adding another one. 63 - Some of the tools are just too slow. I think you know which ones I'm talking about ;-). 64 - I don't use the spectral analysis tools. I prefer XSPEC. Also, it would be helpful if the photometry and/or positions from wavdetect were more reliable. 69 - csmooth - its slow and is too much of a 'black box' program. I've started using my own adaptive smoothing programs. 71 - parameter files 72 - syntax/parameter name changes when changing version of ciao (i.e. change from param "ccd" to "chip" in merge_all, or [dm|ps]extract now using aoffs, now asols, now expmaps..) 75 - speed (especially sherpa, csmooth), stability 82 - that command line inputs change between versions, often breaking dozens of scripts that little time/effort is being devoted to PSF library enhancement. 83 - I want it to become more faster 90 - It is annoying that if one forgets an "=" sign when using pset, that other parameters get screwed up. 99 - Sherpa manual a disaster to read -finding things difficult, written poorly, at times incomprehensible. 100 - examples in ahelp are often trivial need links to other ahelp tasks that explain how to get the files needed by this one 105 - Sherpa. I found it difficult to use and I gave up. 108 - complicated to do any reprocessing because of many arguments for each tool etc. Many can be scripted - like psextract 111 - new features, where it is not clear if it is very important to use them and to redo the full analysis 115 - the way I can waste huge amounts of time puzzling over syntax or obscure documentation, without gaining any understanding of how anything works 121 - sherpa 124 - Speed. Speed. Speed. Sherpa and many of the tools are excruciatingly slow. One reason I fall back to Funtools and Ftools is to get better throughput. For example, converting a script over to using funcalc instead of dmtcalc provided a big performance improvement. I was using funimage instead of dmcopy for awhile, and I'm thinking of going back to funimage. (The main downside is having to fix up the various header keywords.) I always use funtools if they will do the task (e.g., I always use funhead to examine the FITS headers.) The ~/cxcds_param is a royal pain. I often have multiple analyses going on. The only way to keep from clobbering myself is to work hard to ensure that everyone has their own local uparm. A large motivation for wrapping everything in scripts is to allow me to have the script set up the (huge) ciao environment, and set up a local uparm. Periodically I find myself deleting the contents of ~/cxcds_param and then write-protecting it.
Back to the Survey