iraf.net

Sorry for long and detailed description of a simple formatting bug that does not cause any noticable problem in IRAF (at least at first look), but I think the people should be at least warned not loose much time looking for occasional inconsistencies of high precison RV measurements. I would like to pay the attention again to the problem discovered (and not yet) solved here:https://iraf.net/phpBB2/viewtopic.php?t=86131It occurs when the dispcorr is called with 2 reference spectra (with weights according to time difference) and the non-linear dispersion is required (linearize option s is OFF).I have just proved that in the latest 2.14 this problem is still persistent.Today my colleagues astronomers had faced it again when trying convert the WAT keyword string information into their own spectra analysis tools (having a lot of files from high dispersion echelle spectrograph reduced in IRAF.The problem is simple. The string for one non-linear dispersion solution (e.g. with chebyschev koefficients) is merged with second solution and so the weight ot second dispersion is lost and merged as the additional decimal places of the last polynomial coefficient..This can introduce tiny error in value of this coefficient adding further decimal places to it (in principle the weigths may be 1.0 so can simply add 1 at the last decimal place - but usually the coefficients are very small so adding more places does not cause any harm. Of course you have two decimal points (the full stops) but some reading procedures may not care or the fixed length of string is expected to read in every coefficient. But I can imagine that at strongly non-linear cases the increase of the coefficient may increase the error in computed function a liitle - this may mean tiny errors in high dispersion echelle measurement of smal RVs (e.g. extrasolar planets analysis - Iodine cells spectra etc ...)But more critical is that the parsing of the whole WAT string is thus very complicated when you just consider the separation of terms by spaces. The problem may look as happening only occasionaly (it was re-discovered by us when checking why the code sometimes does not work or produces wrong data) as the NON-LINEAR dispersion has to be present (many people just use default linearize but the more experienced know its another source of errors in precise RV work) AND BOTH reference spectra with weights have to be set in header REFSPEC1 and REFSPEC2.
Some observing procedures simply ignore taking comps BEFORE and AFTER stellar exposure and there may be assigned only one reference spectrum (often manually by hedit ot table) This bug makes difficult life of scientists who want to have accurate results using additional spectra analysing tools outside IRAF (the lazy ones just compute wavelengths in linearized spectra from CRVAL and CDELT after conversion to separate orders by scopy) As I understand the non-linear diipersion is on the fly computed from both functions during the analysis (splot) or before copying them to ASCII (wspectxt) or doing scopy with linearzation. otherwie the data are just copyid from header...
At the first moment it looks that IRAF tools are working correctly but its a difficult to distinquish wheteher the whole WCS is correct as in every analysis some errors are intrinsic and without detailed analysis a tiny changes are not seen immediately.I have some suspicion that some combination of WCS tasks introduces small errors (sometimes a result of scopy to single orders did not work the same way as direct usage of splot on non-linear headers(comparing detailed line profiles) but do not have any proof now in hands..
Just remember that about 2 years ago getting the spectra in *.ec and having done scopy produced strange non-linear solutions on some files but other worked well. At that time I could not find differences and so had to use imcopy instead to separate to files with individual echelle orders.Does somebody know why the IRAF does not care when reading mixed solution strings (so what is the algorithm to correctly separate into 2 pieces of lambda solution having the strings mixed otherwise well ?And is tthis his magick realy ALWAYS working (even in scopy, wspectxt etc ... ????)Best regards,
Petr Skoda

Hello Petr,Could you send me all the data needed to run dispcor and get the problem you report. I believe it is still a problem but my test did not produce the merging of the strings. I think what is needed are the identify or ecidentify database files and either the three images (the two set by refspec for the target spectrum and the target spectrum) or header listings. Please also include the command line and parameters for DISPCOR. You may send me this stuff directly to me (valdes@noao.edu). You can put files in the anonymous ftp directory at iraf.noao.edu in the pub directory if they are too large to attach to an email.Yours,
Frank Valdes