Loving ISIS - Confessions of a Former XSPEC User
If ISIS is so Great, Why isn't Everyone Using It?:
Darn good question. The best I can come up with is that, admittedly, there is a bit of a learning curve with ISIS. The paradigm of switching from a 'command line' interface to a 'scripted' one takes some getting used to (although less so for those of us already very used to IDL). Then there is the fact that ISIS started out as Chandra gratings/wavelength-centric. ISIS, however, is much more than that, and it has been used to analyze both Chandra CCD and gratings data, RXTE data, radio data, optical data, HST-STIS data, XMM data, Swift data, INTEGRAL data, etc.
ISIS's heritage as a Chandra gratings analysis tool, however, shows up in a couple of ways, while its design philosophy as a powerfully scripted program shows up in another:
- The ISIS defaults are for functions, arrays, etc., to be in wavelength ascending order.
- Whereas ISIS has always properly treated background files, default data loading did not automatically load the background files, nor did default plotting subtract the background. This is a fine choice for Chandra gratings, but it is less useful, say, for RXTE-HEXTE data.
- ISIS presumes that many things, such as grouping data, will be done during analysis, and therefore it will ignore default binning and systematic errors in FITS file headers.
The first two points, although already addressed by ISIS intrinsic functions, were in large part the motivation for my startup scripts. The third point is a matter for debate, but one where I come down firmly on the ISIS side. Binning is something that can't be "pre-ordained". It's something that should be based upon analysis, and something that should flexibly change during analysis. Furthermore, it is something that I believe is much easier to keep track of in analysis scripts, rather than being buried in FITS file headers.
My aforementioned
nameless friend
disagrees with this. I will just remind him, however, that he
recently redid a CPU month of analyses because he mistakenly
believed that his RXTE extraction scripts had been set to place
systematic errors in the FITS file headers, when in fact that toggle
accidentally had been left off. That is a mistake, I believe, less
likely to occur when most analysis decisions are left to analysis
scripts, and relatively fewer decisions are put in data extraction
scripts, especially when such 'analysis decisions' are more likely to
be changed during analysis. (I will parenthetically add here
that he has also written a Perl script to drop
out of an active XSPEC session, regroup a data set using the
FTOOLS
grppha function, write the new file to disk, pop back into
XSPEC, and then re-read in the data set. OK, this is cool. But for
us plain folk, S-lang scripting, without any rewriting of data files,
is easier and more elegant.)
I think the biggest reason why people might be reluctant to change is, somewhat understandably, inertia. It takes some time and effort, although not nearly as much as you might fear, to switch. The best analogy for myself was when I switched over to referencing via bibtex. There's no question that my life is much, much easier using bibtex. But there was this couple of year period where I was still cutting and pasting references from old files, because hey, there's this proposal deadline coming up fast and I don't have time to learn something new now, I'll do it tomorrow. This is the same. You're used to XSPEC. You're familiar with XSPEC. It will take some effort to switch. But, there's no question, you're life will be better for it. Once you make the switch, you'll be glad you did and you won't look back.
The example analysis that starts on the next page guides you through a practical data analysis session. It uses my ISIS startup scripts. These scripts, which bring back some of the familiar syntax of XSPEC, and this example, will hopefully reduce the inertia you might feel for making the switch.
