IMEXAMINE - complaints and justifications for V2.11 changes
Frank Valdes wrote on Dec 03, 1997
Q: I've been noticing that imexamine has been behaving strangely for me under 2.11 and I see that it is because several of the new features have become the default behavior. I have no objection to the new features, but making them the default is mighty confusing for us veteran imexamine users. In particular having moffat as the default profile, and iterating on the fitting radius are the ones that have caused me the most grief. I've had some problems with the moffat fitting failing and imexam crashing. Changing the fitting radius without any notice is pretty scary when you are trying to do quick aperture photometry. I'd be in favor of changing the default behavior back to match to old behavior. Also, have the results of 'a' spread onto two lines makes the output very difficult to read. End of griping. A: Comments such as yours are welcome. I will give some justifications (though I don't minimize your complaints) and possibly something you haven't discovered yet. The default was changed for the reason that for the various data I looked at from KPNO the Moffat function gave better results than a Gaussian function. Some scientists were concerned about the incorrect or poor values produced by the Gaussian fit for the FWHM. Another staff scientist strongly lobbied for the radius being interated, again so that one did not need to change things for different data and a wrong radius can give wrong FWHM values. The thing to realize is the IMEXAM is one of the most heavily used tools at the telescope for evaluating FWHM. I agree that for photometry you don't want the radius to be iterated; but IMEXAM was not really intended for anything more that quick-look photometry. Following the IRAF philosophy default values can be changed and, so long as the parameters are not unlearned, you can customize parameters to always behave as you want. So in the "rimexam" parameter set you can set iter=1 and fittype=gaussian once and for all. At the last minute I added the new keys "," and "." which provide the same results as "a" and "r" in the previous version. This is probably all you really want. The key values were changed since we want to encourage users to use the best algorithms. Concerning the two lines output, the logfile produces just one long line but I find two lines which are less that 80 chars to be more readable than wraparound lines in an 80 char wide terminal window. Of course the software should not "crash" or go crazy. I will track down these cases. The problem is that as more types of data are examined I find that more complex algorithms are needed to give consistent results (particularly for the very important FWHM quantities). These algorithms do work better in many cases but also tend to have more ways they can go wrong with other types of data.
Last post on Dec 03, 1997