iraf.net

Hi Folks, I have successfully tested both the FXCor and RVIDLINES with spectra available online, and I have been able to confirm that the protocol I am following yields consistent results with those found in the literature. However, when it comes to my own spectra (which do not come wavelength corrected), I find there is at least a 100 km/s systemic offset I cannot account for. I have not been able to reduce the flats and biases using flatcombine and zerocombine yet, and therefore I am unable to proceed with CCDPROC. I only started with IRAF two weeks ago. Anyways, I thought pre-processing merely enhances the SNR of the science image and obviously the flats remove the flux sensitive instrumental response, but could skipping this step introduce a wavelength offset(?) If so, why(?)Nevertheless, I proceed as follows with a science image called "obj.fits" and an arc called "comp.fits" (following the tutorial of Brian Keeney):
- apall obj (everything proceeds nicely and I get wonderful fits)
- apall comp ref=obj recen- trace- back- intera- (follow the same procedure)
- identify comp.ms (I get lovely fits here too)
- hedit obj.ms REFSPEC1 comp.ms add+ ver- show+
- dispcor obj.ms
- splot obj (beautiful normalization too)
- rvidlines (or FXCor)Is there some offset in the arc and science images that is taken out in the preprocessing that I am not accounting for(?) Or is it something else(?) Cheers and many thanks(!)

You are correct that basic CCD instrumental calibrations (bias, flat, etc.) are not absolutely necessary. This should not introduce an error. The first thing that comes to mind is to make sure the arc calibrator and the science source are treated in the same way, at least as regards any trimming. There is a possiblity that if something was done differently but you are sure that the pixels coordinates are matched (i.e. pixel 1,1 corresponds to the same wavelength) that there is still a logical/physical coordinate mismatch. Logical coordinates are the pixel intuitive pixel coordinates and physical coordinates are pixel coordinates from a parent image when trimming or taking out subrasters. To check if this is so there should be no LTV/LTM keywords or the values should be the same. IDENTIFY works in physical coordinates.There could be some other possible effects. I don't think you said how many pixels 100km/s corresponds to. If it is of order a pixel it could be due to charge transfer tails (where the bright lines have wings to one side).Just a couple of thoughts.Frank