NUMBER: 1 KEYWORDS: splot, scopy, imslice, multispec DATE: Mon Jan 3 14:22:09 MST 2005 FROM: valdes Q: I have spectra that have been produced by 'apall', with 4 bands and 2 apertures, with 3071 data points, thus have dimension [3071,2,4]. I want to shift from band to band simply by using the ')' and '(' within 'splot', I actually have to exit 'splot' each time, and specify the band at the prompt or on the command line. What I tried to do is separate the 2 apertures into 2 distinct files, each one of them being [3071,1,4]. Naturally, I can accomplish this more or less with 'imslice', in which case I end up with 2 files, each [3071,4]. In principle, this is perfectly OK, but the problem is that when I try to use 'splot' on these [3071,4] files, I still cannot shift from band to band simply by using the ')' and '(' within 'splot'. A: The '%' key in SPLOT can be used to go to a new band. You have to enter the band so it is not quite as convenient as '(' and ')' which is for apertures. The ')' and '(' keys do have a special feature that if there is only one aperture then it steps through the bands which is why you thought of splitting the apertures. For the approach of separating the apertures you cannot use IMSLICE because it automatically changes the dimension of the multispec image. There are ways to add the dimension back but they are not easy. Instead use SCOPY to copy out each spectrum with its extra bands. This task can split multispec formats to single spectra but it doesn't naturally split things into multispec organized by aperture. However, with a simple loop you can do what you want. The solution is on> for (i=1; i<=2; i+=1) scopy ("abc.ms", "abc"//i//".ms", aperture=i) Of course with just two spectra you could just do the command twice without the loop and the generation of output names based on the line number. NUMBER: 2 KEYWORDS: tables, binary, fits, tprint, tdump DATE: Tue Jan 4 02:44:51 MST 2005 FROM: fpierfed Q: How do I convert a table in FITS binary format to ASCII using IRAF? A: Converting a table in FITS format to ASCII is pretty simple. All you need is the TABLES package, developed and distributed by STScI (http://www.stsci.edu/resources/software_hardware/tables). Within TABLES, the tasks that you might want to use are tdump and tprint. The first one is pretty simple to use. tprint on the other hand offers more control on the output. At the minimum, you can do something like this: tt> tdump combined_dr2_062404.fits > my_ascii_table.dat Please, keep in mind that any further support on the TABLES package is handled by STScI directly (help@stsci.edu). - NUMBER: 3 KEYWORDS: filesize largest 64bit DATE: Wed Jan 5 10:47:47 MST 2005 FROM: zarate Q: I'm working with some large images (1-2 GB), and IRAF has a problem with this. Any tool I try to run gives me the message: ERROR: Attempt to write out of bounds on file This is an example from an 'imarith' attempt, but it seems to happen with all tools. It seems to me that IRAF isn't allocating enough memory in some sort of buffer to be able to work with the images. Does this sound correct? And if so, do you know how I can fix it? I'm running this on a UNIX system (Solaris 8) with 4 GB of RAM, running IRAF version 2.12.2a. Let me know if you need any more info. A: Iraf file size is limited to the 32 bit range which is about 2GB. When an IRAF task like imarith opens an input image and tries to creates another one near this limit you migth get this kind of problems. The same limitation applies to memory requirements of a task. To find out if this is your problem, you could you can operate on a subsection of the big image and see if it goes to completion. This will be addressed with the 64 bit extension of IRAF which is still pending. NUMBER: 4 KEYWORDS: vertical labels specplot txset DATE: Wed Jan 5 15:12:05 MST 2005 FROM: valdes Q: How do I write vertical labels in SPECPLOT? A: Unless the application, such as IGI or SPECTOOL, provide features for adjusting the text attributes, or an application like IDENTIFY automatically writes vertical text, the only control you have is with the "cursor mode" capability. To learn about this type "help cursors" in IRAF. Cursor mode is quite a nice feature since it applies to all graphs but it has the drawback that any redraw of the screen (by the application) will lose the changes and it is not possible to put the cursor mode commands in a file to be executed again. Before describing what to do with SPECPLOT I will point out that you might investigate the tasks noted above. In particular, SPECTOOL is a powerful alternative to the tasks in the standard NOAO spectroscopy packages. It has features for stacking, like SPECPLOT, and for marking and labeling things, like IDENTIFY, and general interactions like SPLOT. There are GUI control panels to do things like set the graphics attributes. Now for SPECTOOL start up the program. As described in the cursor mode help page, to get the graphics on your screen to look like they will look (approximately) in a postscript file you should type ":.txq h". Then do a 'r' to redraw the SPECPLOT graph. This allows the lettering to be drawn with strokes rather than hardware fonts. Next rotate the lettering path with ":.txset up=180". Then start adding the labeling with the 'T' key available in cursor mode. You can save intermediate states with ":.w " which you restore with ".r ". Note that if you write to the same file more than once it will append. When you read it back the screen will flash with all of the past saves. Finally dump the graph with something like ":.snap eps". Again, if you do a redraw SPECPLOT will forget about the changes you made with 'T'. NUMBER: 5 KEYWORDS: encapsulated postscript snap DATE: Wed Jan 5 15:16:12 MST 2005 FROM: valdes Q: How do I make a postscript file from the SPECPLOT? A: When you have the graph you want type one of the following :.snap eps :.snap epsl :.snap psdump The first two produce a file sgiXXXXXX.eps in your working directory and the last produces a file irafdmpXXXXX.ps in /tmp. Because of buffering you might need to type ".gflush" from the cursor mode or "gflush" from the CL command line. The two EPS files are in portrait and landscape. You would probably want to rename the files so you remember what they are. Note that postscript in IRAF is black and white only. To get color postscript see http://iraf.noao.edu/iraf/web/faq/FAQsec08.html#8005 Another task to call your attention to is "igi" in the tables.tbplot package. This is a Mongo-like graphics language interpreter that understands IRAF files. While you need to learn the language it is what I use if I really need complex graphics with lots of labels and spectra. It is convenient because you can keep the commands in a text file. If you are happy with SPECPLOT for what you are doing then this would be overkill. NUMBER: 6 KEYWORDS: longslit fitcoords transform fceval DATE: Thu Jan 6 12:44:12 MST 2005 FROM: valdes Q: I would like to generate a mapping from (x,y) pixels of an image to a wavelength and a spatial axis coordinate. I know this is what TRANSFORM through the FITCOORDS database. Can I do the evaluation directly from the CL? I found that the IRAF math libraries include routines for evaluating the FITSCOORDS mappings but I can't find a CL interface for them. Is there a way to use the math routines to evaluate the FITCOORDS mappings? A: You are in luck because a task to do what you want was added to V2.12.2 (and following patches). So if you have the latest IRAF then the task you want is LONGSLIT.FCEVAL. As far as accessing the functions in the math package these are purely for SPP programming. In future there will be language bindings for access from other languages but it will still be largely intended for software developers rather than users. While it might be an interesting idea to wrap these functions into CL callable tasks it might not be so useful depending on how the input is defined. Anyway, this is a low priority at this time. We do welcome suggestions such as the one that led to FCEVAL which was basically similar to your request. NUMBER: 7 KEYWORDS: VMS Platform Support DATE: Tue Jan 11 12:12:33 MST 2005 FROM: fitz Q: Is IRAF still available for VMS? A: We haven't supported VMS in a few years so the most recent version we have is IRAF V2.11.3 (Dec99) which was prepared under VMS 7.1. You can still download this from the archive directory: ftp://iraf.noao.edu/iraf/v211/VMS7 If it works you're in luck, but if there are problems I'm afraid there's not much we can do to help as all our VMS systems were abandoned a while ago. NUMBER: 8 KEYWORDS: xgterm, RedHat Enterprise WS3, ncurses, garbage on screen DATE: Wed Jan 12 10:31:17 MST 2005 FROM: valdes Q: We are running RedHat Enterprise WS3 (Taroon update 4) and implot produces garbage on the screen. We are not using xgterm because it requires curses 4 and we only have curses 5 A: Be sure that you aren't using konsole or gnome-terminal, as neither of these implement the textronix tools. You must use xterm or xgterm. Garbage on the screen is typically due to a mismatch in the terminal setting. If you see the garbled text when usign an xterm, then you probably have the terminal set to 'xgterm'. Edit your login.cl file. To get xgterm working, there are two things you can try. There is version of x11iraf that is linked against ncurses version 5. You can get that from the following link: ftp://iraf.noao.edu/pub/fitz/x11iraf-v1.3.2-bin.redhat.tar.gz The alternative is to create a symbolic link as follows: cd /usr/lib ln -s libncurses.so.5 libncurses.so.4 NUMBER: 9 KEYWORDS: DS9, color problem DATE: Wed Jan 12 10:42:01 MST 2005 FROM: valdes Q: We are using DS9 with RedHat Enterprise WS3 and when we use the IRAF display task we only see a pink box though directly loading by DS9 works fine. A: The user reported that upgrading from DS9 V3 to DS9 V3.03 fixed the problem. NUMBER: 10 KEYWORDS: DS9, display, WCS, coordinate display DATE: Wed Jan 19 09:02:12 MST 2005 FROM: valdes Q: When I load a fits image (say, a 2Mass image) from within DS9 (with file->open), the cursor on the DS9 display provides the x,y and RA,DEC position on the image. If instead I use the IRAF/display command to load the same image on DS9, then I only get x,y from the cursor, no RA-DEC. Why can't DS9 read the world coordinates of the image when displayed from IRAF cl? Is there a parameter I should update somewhere? A: When IRAF sends the image WCS to the display server it includes the pathname to the image, however DS9 doesn't currently do anything with this filename and so only displays the x,y coords and approximate pixel value based on the z1/z2 scaling. When DS9 loads the image standalone it's able to read the image pixels/wcs directly and makes use of them. There is no parameter you can set, this is a change that needs to be made in DS9 to have it access the image when displayed from IRAF. NUMBER: 11 KEYWORDS: Debian, LNUX, IRAF platforms DATE: Wed Jan 19 09:07:38 MST 2005 FROM: fitz Q: Is there any distribution of IRAF compatible with the Debian linux? A: The standard PC-IRAF system supports Debian using the LNUX architecture. You'll need the as.pcix.gen source distribution, and the ib.lnux.x86 (core IRAF) and nb.lnux.x86 (NOAO package) binaries as well as the pciraf.ps installation guide (all files compressed so note the .gz extensions). See also the README file. You can download the files from our archive in ftp://iraf.noao.edu/iraf/v212/PCIX. NUMBER: 12 KEYWORDS: cosmic rays, crutil DATE: Fri Jan 21 11:38:07 MST 2005 FROM: valdes Q: Last year, Wojtek Pych (Copernicus Center, Poland; also Dunlap Obs.) published an interesting paper on a fast algorithm for CR removal from single CCD images, suited especially for 2-D spectral images (Pych, PASP 116, 148, 2004 Feb). His C code is available at http://www.camk.edu.pl/~pych/ Do you by any chance know whether anyone has written an IRAF task that runs this code? (I have asked Pych directly, who does not know of any such task.) If that hasn't been done yet, I'll try to have one written, since Pych's code seems to be very efficient and good at CR removal from single 2-D spectra. A: I am not aware of anyone that has implemented this in an IRAF task. I just quickly read the paper and the method is simple enough that it should not be hard, particularly with the code available. It would be a interesting addition to the suite of tasks recently collected together in a CRUTIL package. NUMBER: 13 KEYWORDS: mosaic astrometry, WCS solutions for multiple amps/CCD DATE: Fri Jan 21 11:51:46 MST 2005 FROM: valdes Q: I am trying to derive a WCS for a new mosaic camera. I have used CCMAP to derive a fair WCS using ten bright stars on one amplifier of one ccd. To simplify the situation, I have cut three of the CCD's out of the mosaic, so I have only two amplifiers (and two extensions) to work with. My first question deals with how to treat both amps at once. CCMAP seems to want only one extension at a time, or a frame that has been put into a simple fits format. I can create the simple format by copying the two extensions into one simple fits file (but I lose the header info from extension [0]), but I don't think this is what I should be doing. I assume I derive a WCS for the mosiac and then make a simple fits file which is corrected and shifted to a point common with the other dithered images of the same object. Am I right? How do I treat the two amps (extensions) with CCMAP? A: Your are right that you should derive a single WCS for a CCD since multiple amplifiers are geometrically linked. This is what is done with the CTIO mosaic that has 2 amplifiers per CCD and I do a single WCS solution for each CCD which are then divided across the amplifiers. The way this is done is to derive a database solution for the merged single CCD using MSCTPEAK. In the database it should say pixsystem is physical. Then the other thing is setting up the mapping between physical coordinates (think of this as CCD coordinates) and the pixels in the amplifier images correctly. This is done with the LTV1 keyword. Normally you would have no LTV or LTM keywords in the raw data but it might depend on the presence of any over/pre scans on the left side of the image. LTV1 should be the offset from the first pixel of the real data, i.e. the merged CCD image and the first pixel in the amplifier image. An example is best here. Suppose you have two amplifier image extensions called im1 and im2. In im1 there is nothing on the left. This means pixel (1,1) is the first CCD pixel corresponding to (1,1) in the image you used for MSCTPEAK. Then the offset in x is 0 and you can either set LTV1=0 or leave it out because the default for a missing LTV keyword is 0. Now the first amplifer reads out the first 1024 pixels of the CCD. The second amplifier reads out the second 1024 pixels. Again, if there is no dummy data on the left of the image for im2 then the first image pixel maps to pixel (1025,1) in the merged CCD image. Then the offset is LTV1=1024. Once you have this setup to define this "physical" or CCD coordinate system then MSCSETWCS will apply a database solution appropriately. This only modifies the WCS keywords and will set CRVAL1/CRVAL2 to some real point on the sky for the exposure based on a keyword in the header. That is, the one solution for the CCD will be set appropriately for each of the two amplifiers. Note that what this really means is that the keywords will be the same except that the CRPIX1 keywords will differ by some amount. As a reminder CRPIX1 is the pixel relative to the image that corresponds to the "tangent point" where the CRVAL1 keyword gives the RA (in degrees). As noted in the astrometry write up the celestial point on the sky needs to be the same for all the pieces of a mosaic and then the CRPIX keywords define the different distances of a WCS to that point on the sky in terms of the origin of the particular image. To illustrate what I do for the CTIO mosaic I make 8 solutions for the 8 CCDs. These are labeled im1, im3, im5, etc in the database. I then copy the first 8 to the end of the file and change the labels to im2, im4, etc. There is nothing else changed in terms of the WCS. Once you have the database file then running MSCSETWCS to populate the WCS in the mosaic data will preserve the headers and only change the WCS keywords. References: http://iraf.noao.edu/projects/ccdmosaic/astrometry/astrom.html http://iraf.noao.edu/projects/ccdmosaic/generic/generic.html NUMBER: 14 KEYWORDS: binary tables, spectra, splot, rspectext DATE: Fri Jan 21 12:19:28 MST 2005 FROM: valdes Q: I have at my disposal spectra in FITS format, but with a binary table extension. The extension contains the following: WAVELENGTH R %10.3f ANGSTROMS FUNNORM R %10.4e "" FNORM R %10.4e "" SNR R %10.1f "" ORDER I %3d "" I am wondering how I can use IRAF NOAO tasks such as SPLOT (to examine, e.g. 'fnorm' vs 'wavelength') or CONTINUUM (to continuum normalize 'funnorm') on these data. A: We would like to eventually have SPLOT, and other ONEDSPEC tasks, operate directly on this table format. A table format for spectra is a reasonable thing but in the IRAF NOAO packages we use an image format with a WCS in the header to handle the coordinates. The current solution is to extract the data you want into a two column text file. The tasks in the TABLES package provide the ability to convert a FITS table into text. The TABLES package must be installed separately from the STSDAS distribution which is also available at http://iraf.noao.edu/contrib.html You could also use TABLES tools for plotting and GRAPH for the text files. But all of the analysis features in SPLOT require use of image format. The columns would be wavelength and one of the flux columns. You would then use the task ONEDSPEC.RSPECTEXT to convert the text file into an image spectrum. In this task there are choices about how to create the wavelength coordinate system. If the coordinates vary smoothly a fit is a compact description. But you can also use the non-linear mode to store each wavelength in a list in the header. Note that this method has a limitation that the list, which is stored as text, has to fit in less than 999 68 character strings. So a very long spectrum could not be handled in this way. NUMBER: 15 KEYWORDS: spectra, continuum DATE: Mon Jan 31 09:35:44 MST 2005 FROM: valdes Q: I am having a strong continuum in my extracted blackbody corrected spectra of which I want to get rid off ( I am looking for a faint emission on this continuum). Can you suggest me a way to do it effeciently, since I am having 100 such spectra. A: The task CONTINUUM in the ONEDSPEC package may be used. Defining the continuum can be hard if there are many lines. Thie method in CONTINUUM (which is also available with the '/' key in SPLOT) is to fit a function with rejection of the high and low points. It primarily works well with spectra that are either all absorption or emission so that a one sided clipping can be used. For your question about emission you should use something like a 1-sigma threshold below and 4-sigma (or higher) above. This will then approach the continuum from below removing the absorption lines while not removing emission lines. NUMBER: 16 KEYWORDS: spectra, smoothing, filtering, boxcar DATE: Mon Jan 31 09:37:58 MST 2005 FROM: valdes Q: Is there any way in IRAF by which I can take a 5 point running average for a given specta (say spectra.imh). A: This can be done either with the SPLOT 's' key or with the task BOXCAR. In both cases a moving average is also called "boxcar smoothing". In SPLOT it is interactive for visual interaction. The result can be saved from SPLOT if you want. Note that other tasks in the IMFILT package (see help imfilt) can be applied to 1D spectra as well as 2D. The most common alternative to boxcar filtering is gaussian filtering. NUMBER: 17 KEYWORDS: crosstalk, MiniMosaic DATE: Thu Feb 3 16:32:20 MST 2005 FROM: valdes Q: Where can I find the latest MiniMosaic crosstalk files? A: As far as we know, there are no crosstalk files for MiMo. Users generally are more concerned if a bright star is present for issues of saturation bleeding and ghosting (ghosting is described in the MiMo manula). As to crosstalk, it is assumed to be low (an old measurement is "a few adu in multiple 10,000 adu". NUMBER: 18 KEYWORDS: photometry, DAOFIND, CENTERPARS DATE: Thu Feb 3 16:43:14 MST 2005 FROM: valdes Q: We are doing variability photometry and occasionally get about 700 CCD images per night. I do the reductions in IRAF, and mostly it goes pretty quickly, except dealing with coordinate files. Is there any way to specify the positions of the stars to do photometry on, so you don't have to edit 700 coodrdinate files that come out of DAOFIND? The drift of the objects during the night is fairly small, but not zero, but the fields are not crowded, so if there is so me way to define a coordinate box where DAOFIND looks, that would save alot of editing and messing around with S/N cutoffs, and max brightness levels to try and reduce the number of stars DAO finds to a manageable level. A: There is no need to use DAOFIND before every exposure when the images have only small shifts. Once you have a list of pixel positions of the stars, say from DAOFIND, in one exposure all you should have to do is recenter the pixel coordinates for each exposure rather than "find" them again? The DAO package photometry tools have options to center on the sources provided by the input coordinates. The centering option would be controled by the CENTERPARS parameter set. So consult the CENTERPARS help file. Centering works when the shifts are fairly small and the field is not too crowed. The CENTERPARS options work within a box around the starting coordinate. So the box should be big enough for the shift but not so big as to include another star within a couple of magnitudes fainter (very faint stars should not affect the centroid). NUMBER: 19 KEYWORDS: spectra, convolution, multispec, 3D DATE: Fri Feb 4 13:02:22 MST 2005 FROM: valdes Q: I have a set of multispec FITS that I need to convolve (gauss, boxcar, ...). Each multispec FITS has 3 spectrum with the same dispersion and all of them need to be convolved. The gauss or boxcar tasks complain about the higher dimensions. Is there a way to convolve the multispec without having to extract each aperture, convolve, and them combining them again? A: The BOXCAR, GAUSS, ..., tasks will work on 1D and 2D data. If you have multiple apertures in the multipec format, that is more than one line, then you would set the convolution size in y to 1. Now if you have the third dimension, the "extras" information from APALL, then you do have to do something because the tasks are not designed for 3D data. You can do things fairly easily as follows. Let me assume you have multispec data which is [*,3,4]. There are some number of wavelength points along the first dimension which you want to convolve, there are 3 spectra, and each spectrum has the primary spectrum and 3 associated spectra. Note whether it makes sense to convolve the sigma spectrum I won't address. For this example suppose you want to do a boxcar convolution of 5 pixels. cl> boxcar spec.ms[*,*,1] band1 5 1 cl> boxcar spec.ms[*,*,2] band2 5 1 ... cl> imstack band1.band2,band3,band4 newspec.ms You could also do this with a loop: cl> for (i=1; i<=4; i+=1) >>> boxcar ("spec.ms[*,*,"//i//"]", "band"//i, 5, 1) cl> imstack band1.band2,band3,band4 newspec.ms In summary, you want to use image sections to select bands of the 3D multispec file and use IMSTACK to rebuild the 3D multispec format. NUMBER: 20 KEYWORDS: apall, long slit, dispaxis DATE: Fri Feb 4 13:15:40 MST 2005 FROM: valdes Q: I am attempting to run apall to extract spectra from images that have the dispersion axis running horizontally (along x-direction) and the spatial axis running vertically (y-direction). However, it seems that this IRAF task is hard-wired to interpret data with the oppsite orientation, and I am having a difficult time finding the parameter which can be changed so that the program recognizes the orientation of my dispersion axis. Currently, it chooses a dispersion line which runs parallel to my dispersion axis...i.e. it chooses a line that misses my object spectrum all together! I think that the program should be choosing a line that runs perpendicular to my dispersion axis (and consequently my object specrum) so that eventually the dispersion line will run across my object, from which I can define an aperture window from there. A: I think you are asking about defining the dispersion axis. This is done either by a header keyword DISPAXIS or the parameter "dispaxis" in the parent package parameters. For example, if you load APEXTRACT then use "epar apextract". If you use KPNOSLIT then do "epar kpnoslit". The values of dispaxis are 1 for dispersion increasing/decreasing with the column (first image axis), which is horizontal when viewed in an image display, and 2 for the opposite orientation. From what you describe you want dispaxis=1. NUMBER: 21 KEYWORDS: Gemini, SALT, crosstalk, xtalkcor DATE: Mon Feb 7 08:47:35 MST 2005 FROM: valdes Q: I am using the GEMINI package convention of using EXTNAME and EXTVER, so that the image extensions are named [SCI,1], [SCI,2], etc. This would have worked with the old xtalkcor.cl, but with the new one I am getting an error message: Warning: FXF: extname and/or extver value already exists in extension ('SCI') A: I did manage to use xtalkcor on Gemini-convention data. I thought you might be interested in how in case anyone else asks. By the way, the reason I am doing this is that I am adapting the Gemini package (with their approval) to use on the Southern African Large Telescope (SALT); I am PI on the first major instrument, Prime Focus Imaging Spectrograph (PFIS), which has a similar CCD layout and mode set to GMOS. I wanted to graft your xtalkclcor into it, since they say their crosstalk is too small to bother with a correction, and ours is not. The only incompatibility arises from the Gemini extension names, which are [SCI,1], [SCI,2], etc. Xtalkcor appears to slice the MEF into individual fits files named xxx_SCI,1.fits, xxx_SCI,2.fits, etc. The comma in the fits name confuses those tasks that interpret image lists, where "," denotes a new image. The crosstalk correction is correctly applied, it just trips up trying to glue the fits files back into an MEF. So I used your "split" option and glued them back together myself, begin careful to not use routines that use image lists, or by escaping the "'" with a "\". It works fine, and is nice and fast, even for unbinned data: ---------------- # do crosstalk correction using mscred.xtalkcor # ignore bpm for now # get around xtalkcor bug by splitting extensions # and re-assembling them with fxcopy if (canxtalk) { mscred.verbose=l_verbose; mscred.logfile=l_logfile xtalkcor(output[ii],output[ii],output[ii], xtalkfiles=tmpxfile,bpmthreshold=-10.,split+, fextn="fits",noproc-) tmpfile=mktemp("tmpfile")//".fits" fxcopy(output[ii],tmpfile,groups="0",new_file+,verbose-) imdelete(output[ii]//".fits",verify-) imrename(tmpfile,output[ii]//".fits",verbose-) for (jj=1;jj<=n_ext[ii];jj+=1) { fxcopy(output[ii]//"_"//l_sci_ext//"\,"//jj//".fits", output[ii]//".fits", groups="", new_file-, verbose-) salhedit(output[ii]//"["//jj//"]","EXTNAME",l_sci_ext, "Extension name") salhedit(output[ii]//"["//jj//"]","EXTVER",jj, "Extension version") } salhedit(output[ii]//"[0]","XTALKCOR ","yes", "Corrected for amplifier crosstalk") print (output[ii]//"_"//l_sci_ext//"*.fits") delete (output[ii]//"_"//l_sci_ext//"*.fits", verify-) delete (output[ii]//"*.pl", verify-) delete ("pfisxtalk_*", verify-) } ----------------------------------- NUMBER: 22 KEYWORDS: graphics, windowing, zooming, gtools, identify DATE: Mon Feb 7 09:01:45 MST 2005 FROM: valdes Q: I've been able to get to the wavelength calibration part of my spectral reduction, and am currently assigning wavelengths to my arc..however there was a bad column in the chip, and thus there is one segment of my plot that has a horrendous spike...now I have tried to find a way to remove that spike and re-plot my arc spectrum (after extraction, naturally), but haven't found a way...I also tried to find a way to change the y-axis (i.e. :y 300 500) but that doesn't seem to work when I am executing the task IDENTIFY. A: There are two questions here. One is editing the data in an applicatation graph, what you called "remove that spike". There is no generic way to edit data in a graph though some applications such as SPLOT and SPECPLOT let you do that. The second question about replotting the data is very common. This is how one "expands" the plot to see finer detail. In many of the science applications, though not all and not in the core PLOT or IMAGES package, there is an interface called GTOOLS. If you type "help gtools" you can read about it. These are commands to tell the application how to redraw the graph. So in IDENTIFY you would do something like 'w' 'e' 'e' to expand the graph. Also 'w' 't' to put an upper limit in order to chop off the spike. It is important to know that 'w' 'a' will return you to autoscale which is what the applications usually do by default. So there are lots of keystrokes available. Note also that the 'z' and 'p' keystrokes in IDENTIFY let you zoom around the marked features and then cancel the zoom. But what I most often use with IDENTIFY are the e and a window commands. NUMBER: 23 KEYWORDS: apall, upper/lower, aperture widths DATE: Mon Feb 7 09:12:06 MST 2005 FROM: valdes Q: One thing I did want to clarify under the APALL parameters, numerous as they be...the actual extraction aperture is defined by the "upper" and "lower" parameters, true? The profile centering width, nsum, etc are simply for centering purposes, as far as I can discern...though this is my first time reducing spectra. A: In APALL when you first type 'm' or use the automatic find the application needs to have a default aperture width. You are correct that upper and lower define the default. If you edit an aperture in the edit mode and then mark a new aperture it will use the last defined aperture. But for most purposes you need only to be concerned with "upper" and "lower". You are also right that the widths used for centering on a feature for setting an aperture and tracing are not the same as the aperture width. NUMBER: 32 KEYWORDS: uncertainties, errors, sarith DATE: Mon Aug 1 09:06:52 MST 2005 FROM: valdes Q: I have a question about the behavior of sarith in noao.onedspec package. I have a so-called 3D multispec format fits files, with basically the standard contents: optimally-extracted, no-weighting, sky, and sigma vectors. When I tried to do an arithmetic globally on this fits file, this is what I get: cl> sarith f1672.oii / 2.38e-18 f1672.oii clobber+ format="multispec" f1672.oii.fits[*,1,1](1) / 2.38E-18 --> f1672.oii.fits[*,1,1](1) f1672.oii.fits[*,1,2](1) / 2.38E-18 --> f1672.oii.fits[*,1,2](1) f1672.oii.fits[*,1,3](1) / 2.38E-18 --> f1672.oii.fits[*,1,3](1) f1672.oii.fits[*,1,4](1) --> f1672.oii.fits[*,1,4](1) I'm wondering why sarith does not do the intended computation on the 4th vector. I've tried explicitly specifying the band 4 within the task option, but for some reason operation on that band does not yield intended results (which is dividing by 2.38e-18 here). Is this a bug, or the behavior is intended? Also, to make sure I'm interpreting the multispec format. The 4th vector is an error vector, which means the error/uncertainty associated with the particular pixel for the optimally-extracted spectrum (1st vector). So basically if x1, x2, ... , xN are the optimally extracted pixel values, then the 4th vector contains dx1, dx2, ..., dxN, such that x1 +/- dx1 x2 +/- dx2 .. xN +/- dxN are the array of pair (best estimates, uncertainty). I hope I'm interpreting the format correctly here, but if I'm not, I'd appreciate if you could let me know. A: The behavior with the error or uncertainty vectors is intended though it raises a common question. The reason for the behavior is that since SARITH can be doing arbitrary operations, as well as possibly resampling the spectra, it was decided that rather than do the incorrect thing to uncertainty it was better to do nothing. SARITH is not sophisticated enough to due correct error propagation. Your understanding of the meaning of the error array is correct. In the more constrained situation of extraction from a 2D CCD image with specified noise model (the readout noise and gain with Poisson statistics) the uncertainty is the formal 1 sigma error estimation. Correct and, more important, meaningful error propagation in a general image and spectral processing environment is hard and IRAF task have generally avoided this for some indefinite future. NUMBER: 33 KEYWORDS: quadformat, quadred, quadproc, gain and readout noise DATE: Mon Aug 15 09:24:13 MST 2005 FROM: valdes Q: Settings for the read noise and gain appear in the parameter sets for zerocombine, flatcombine, qzerocombine and qflatcombine [maybe elsewhere, too??] I've got data with one chip from Tololo, but each quadrant is read out separately. So, there are four gain readings and four read noise readings in the header. I've been averaging these four gain and four noise reading values, and entering the average read noise and gain in the qzerocombine nad qflatcombine parameter sets. Is that correct, or does quadproc automatically pick the four noise readings and four gain readings from the header, and enter them into quadproc? Do I have my parameter files etc., straight? A: The gain and read noise parameters are used by the underlying combine task to try and identify cosmic rays or other transient noise. While this could be potentially useful in the tasks you mention, there are other rejection methods, I recommend "avsigclip", that work just as well and don't require the gain or read noise. The reason I say this is that the current software doesn't know about the keywords in the quadformat (see "help quadformat") which define the gains of the individual amplifiers; though they should be present as GTGAINij and GTRONij in your data. So I suggest you not worry about this since CCDPROC doesn't need this and there are other rejection methods in the combining tasks that should be fine. After flat fielding the issue of the gain and readout noise is put off to applications such as photometry which don't understand the quadformat anyway. If you want to do more than I suggest there are two approaches you could try. One is the task QUADSCALE which can scale the data to a common gain. The other is to split the data with QUADSPLIT and treat each quadrant (or half) as separate data sets. I need to qualify my response by saying that I have never reduced CTIO quadformat data and some of the tools were written by others at CTIO. If you want more guidance on reducing this data you might contact the instrument scientists at CTIO that support the instrument you used. NUMBER: 34 KEYWORDS: mscred, msccmatch, mef, single images DATE: Fri Aug 26 11:47:31 MST 2005 FROM: valdes Q: I've been using mscred for a long time and have grown used to the efficiency of msccmatch for WCS fitting and installation. Is there anything like it for single CCD images? I'm aware of the imcoords package, but it seems like it would be a lot of work compared to msccmatch, which just runs by itself. A: Msccmatch will work with single images. So you need to have an initial WCS. Note that msccmatch is not a general matching method so the assumption is that the WCS is off by a zero point shift, possibly a small (~1deg) rotation and have some linear distortion. In general many of the useful mscred tasks will work on single images (mscdisplay, msczero, msccmatch, mscfinder, and mscimage are examples). You are right that a general solution would involve imcoords package. The task ccxymatch is one of the tasks for finding WCS from scratch but it is sensitive to parameters settings. NUMBER: 35 KEYWORDS: identify, scripts DATE: Fri Nov 4 12:35:45 MST 2005 FROM: valdes Q: I am writing some IRAF scripts involving the use of the task "identify". I would like to use the task interactively, as when it is launched from the command line. Everything works fine at the beginning: the task is launched and the graphical window pops up, waiting for the interactive commands. The problem is that whenever I try to mark some features using the "m" key the task does not allow me to type in the wavelength, just as if the enter key is automatically hit, so that the feature wavelength remains INDEF. Trying to hit "u" to enter the wavelength is of no help. The keystrokes and colon commands work fine, but there is no way of typing in the wavelength for marked features. I also tried to launch identify through a simple script with just a line: "identify", and I noticed that at the end (being the "autowrite" parameter set to "no") the script does not stop waiting for my answer, but it gets the last entry and directly exits; also this behaviour suggests that it is just like an enter command is automatically sent to the task. Could you give me any suggestion on how to solve this problem? Thank you for all the help you may provide. A: This is a common "gotcha" (FAQ) with using IDENTIFY. The IDENTIFY task reads input from the cursor, from parameters, and from the standard input of the task. It is this last part, where it asks for such things as the wavelength, that causes problems with the simplest way to invoke a script. I suspect you are doing something like: cl> cl < myscript.cl In this case you are redirecting the standard input of the CL from the terminal to the script file which then causes the problem you have. There is an easy solution. You must declare the script as a task as follows: cl> task $myscript = myscript.cl cl> myscript # This runs the script The script must use the .cl extension. The path, such as home$, is optional but if you don't specify a path then the script will only run in the directory where the script file is located. The first $ in the task statement says that the script does not have parameters. Note there are other ways to write scripts, which also use the task statement to define them, that include parameters and is more like a programing language (see http://iraf.noao.edu/iraf/ftp/iraf/docs/script.pdf). To repeat, IDENTIFY cannot be used in a script that is executed by redirection to the cl but can be used in other forms script invocations. NUMBER: 36 KEYWORDS: psfmeasure, ellipticities, position angles, imexamine DATE: Mon Nov 14 12:53:53 MST 2005 FROM: valdes Q: I have a (long) list of x and y positions of stars in an image. I would like to measure the ellipticities and position angles of the images non-interactively. How should I do this? A: IMEXAM I suggest you look at the task PSFMEASURE. In the current version of IRAF it is part of the OBSUTIL package. To do the non-interactive job you want you would make a text file of x/y for all your stars. ob> psfmeasure starfield imagecur=mystars.dat >G dev$null ** Select stars to measure with 'm' and finish with 'q'. ** Additional options are '?', 'g', and :show. NOAO/IRAF V2.12.2a-EXPORT valdes Mon 12:47:40 14-Nov-2005 Image Column Line Mag FWHM Ellip PA SAT starfield 164.79 184.59 0.00 2.206 0.06 -23 Full width at half maximum (FWHM) of 2.2061 This is with the default parameters. Note the redirection of the graphics to null file. You could redirect the graphics to a metacode file viewable with (e.g.) GKIMOSAIC. However for 30,000 stars I don't think you want that. The algorithms in PSFMEASURE are largely the same as in IMEXAM. NUMBER: 37 KEYWORDS: colbias, ccdproc, fit1d, prescan, overscan DATE: Mon Nov 14 14:13:04 MST 2005 FROM: valdes Q: I have a question concerning the colbias command in the noao.bias package of IRAF. I am working with a telescope which uses columns 1-48 and 2096-2158 as overscan regions. The bias is found by the colbias command. I was wondering if it is poissible to set up the parameters in such a way that both sections (so 1-48 and 2096-2158) are used for this purpose. Could you help me with this question? A: It is not common to use both the prescan and overscan columns at the same time. The standard IRAF tasks for handling bias (colbias and ccdproc) do not allow use of more than one contiguous region for bias. However, if you wish to do so you can use FIT1D to do what you want. The parameters I recommend are: I R A F Image Reduction and Analysis Facility PACKAGE = imfit TASK = fit1d input = Images to be fit output = Output images (axis = 1) Axis to be fit type = difference Type of output (fit, difference, ratio) (interac= no) Set fitting parameters interactively? (sample = 1-48,2096-2158) Sample points to use in fit (naverag= -100) Number of points in sample averaging (functio= chebyshev) Fitting function (order = 2) Order of fitting function (low_rej= 0.) Low rejection in sigma of fit (high_re= 0.) High rejection in sigma of fit (niterat= 1) Number of rejection iterations (grow = 0.) Rejection growing radius in pixels (graphic= stdgraph) Graphics output device (cursor = ) Graphics cursor input (mode = ql) The type of "difference" subtracts the bias, the "sample" parameter defines the data to use for the bias. The value of -100 says to take the median of each bias region (a median is good to avoid bad pixels and cosmic rays), and the function and order fit a line between the two regions. The value of the fit is subtracted from each pixel in the image. Read the help page for this task for the various options. To later trim away the bias regions you would use imcopy with image sections. cl> imcopy [49:2095,*] NUMBER: 38 KEYWORDS: zscale, display, autoscaling DATE: Mon Dec 5 15:37:00 MST 2005 FROM: valdes Q: I can't find a description of the 'zscale' scaling algorithm anywhere. Do you have a reference for how it determines the proper scaling of the pixels? A: The algorithm is described in the IRAF help for the DISPLAY task in a section on the algorithm. I include the section below for your convenience. In summary, the algorithm consists of selecting a subset of pixels (using masks if defined to exclude data), sorting the values, chopping off the ends, and fitting a linear function. From the DISPLAY help page: ZSCALE ALGORITHM The zscale algorithm is designed to display the image values near the median image value without the time consuming process of computing a full image histogram. This is particularly useful for astronomical images which generally have a very peaked histogram corresponding to the background sky in direct imaging or the continuum in a two dimensional spectrum. The sample of pixels, specified by values greater than zero in the sample mask zmask or by an image section, is selected up to a maximum of nsample pixels. If a bad pixel mask is specified by the bpmask parameter then any pixels with mask values which are greater than zero are not counted in the sample. Only the first pixels up to the limit are selected where the order is by line beginning from the first line. If no mask is specified then a grid of pixels with even spacing along lines and columns that make up a number less than or equal to the maximum sample size is used. If a contrast of zero is specified (or the zrange flag is used and the image does not have a valid minimum/maximum value) then the minimum and maximum of the sample is used for the intensity mapping range. If the contrast is not zero the sample pixels are ranked in brightness to form the function I(i) where i is the rank of the pixel and I is its value. Generally the midpoint of this function (the median) is very near the peak of the image histogram and there is a well defined slope about the midpoint which is related to the width of the histogram. At the ends of the I(i) function there are a few very bright and dark pixels due to objects and defects in the field. To determine the slope a linear function is fit with iterative rejection; I(i) = intercept + slope * (i - midpoint) If more than half of the points are rejected then there is no well defined slope and the full range of the sample defines z1 and z2. Otherwise the endpoints of the linear function are used (provided they are within the original range of the sample): z1 = I(midpoint) + (slope / contrast) * (1 - midpoint) z2 = I(midpoint) + (slope / contrast) * (npoints - midpoint) As can be seen, the parameter contrast may be used to adjust the contrast produced by this algorithm.