ecreidentify
Guest wrote on Nov 22, 2006
Hi,
I have a question about the IRAF task echelle.ecreidentify that I have been
unable to find an answer for anywhere so I hope you can help. I am using the
task to calculate a zero order shift in the wavelength solution and this works
OK. The only problem is that the result is only with 2 decimals. For the
precision I would like I need at least 4 decimals in the result. Can I get that
and how?
I thank you in advance hoping for a positive answer.
Yours faithfully
Karsten Brogaard
University of Aarhus, Denmark
Post generated using Mail2Forum (http://www.mail2forum.com)
I have a question about the IRAF task echelle.ecreidentify that I have been
unable to find an answer for anywhere so I hope you can help. I am using the
task to calculate a zero order shift in the wavelength solution and this works
OK. The only problem is that the result is only with 2 decimals. For the
precision I would like I need at least 4 decimals in the result. Can I get that
and how?
I thank you in advance hoping for a positive answer.
Yours faithfully
Karsten Brogaard
University of Aarhus, Denmark
Post generated using Mail2Forum (http://www.mail2forum.com)
Mike Fitzpatrick wrote on Nov 22, 2006
The only way to change the output precision is to modify the code and recompile. If you tell me specifically which number you'd like to change I can post detailed instructions.
-Mike
-Mike
Karsten Brogaard wrote on Nov 22, 2006
fitz
The only way to change the output precision is to modify the code and recompile. If you tell me specifically which number you'd like to change I can post detailed instructions.
-Mike
The number I am after is the 'user shift'
Mike Fitzpatrick wrote on Nov 22, 2006
I believe then that you need to change the format on line 158 of noao$onedspec/ecidentify/t_ecreid.x, which now reads
to change the '%10.3g' format to include more precision (e.g. a '%12.4f' format). Note this will shift the output columns a bit.
Once the change is made you'll need to recompile the package. This assumes you have $iraf and $IRAFARCH defined in your unix environment and permission to modify the files:
Then test to see whether you get the expected results. Normally you would reset the package architecture to 'generic' but this isn't strictly required, however reconfigureing the package before you do the build IS required. If you have any problems please post the error messages. Hope this helps.
Cheers,
-Mike
call fprintf (fd,
"%20s %3d/%-3d %3d/%-3d %9.3g %10.3g %7.3g %7.3g\n")
to change the '%10.3g' format to include more precision (e.g. a '%12.4f' format). Note this will shift the output columns a bit.
Once the change is made you'll need to recompile the package. This assumes you have $iraf and $IRAFARCH defined in your unix environment and permission to modify the files:
unix% cd /iraf/iraf/noao/onedspec/ecidentify
unix% vi t_ecreid.x # make the change
unix% cd /iraf/iraf/noao # go to the NOAO package
unix% mkpkg -p noao $IRAFARCH # reset the package architecture
unix% cd onedspec # go to the ONEDSPEC package
unix% mkpkg -p noao update # compile the change
Then test to see whether you get the expected results. Normally you would reset the package architecture to 'generic' but this isn't strictly required, however reconfigureing the package before you do the build IS required. If you have any problems please post the error messages. Hope this helps.
Cheers,
-Mike
Karsten Brogaard wrote on Nov 22, 2006
Thanks for your answer, I will try it out in a moment on my local copy of IRAF. One question though: the task I am using is noao.imred.echelle.ecreidentify and your suggested change is to
noao.onedspec.ecidentify. I asume that you just confused the packages and that I need to make the change to noao.imred.echelle.ecidentify
Please confirm. Thank you.
Karsten :D
noao.onedspec.ecidentify. I asume that you just confused the packages and that I need to make the change to noao.imred.echelle.ecidentify
Please confirm. Thank you.
Karsten :D
Mike Fitzpatrick wrote on Nov 22, 2006
The task is declared in the IMRED.ECHELLE package, but the source is indeed in the ONEDSPEC package tree. Tasks are commonly declared in more than one package but refer to a common source elsewhere (i.e. the ECHELLE package is made up of tasks from a number of other packages, just logically grouped for echelle reductions).
-Mike
-Mike
Karsten Brogaard wrote on Nov 22, 2006
fitz
The task is declared in the IMRED.ECHELLE package, but the source is indeed in the ONEDSPEC package tree. Tasks are commonly declared in more than one package but refer to a common source elsewhere (i.e. the ECHELLE package is made up of tasks from a number of other packages, just logically grouped for echelle reductions).
-Mike
Yes I assumed somthing like that since I could not find the file in the other directory. Sorry for not trusting a superior experience. :oops:
Anyway I just wanted to say that your suggestion solved my problem, the result now comes with 4 decimals like I asked :D Thanks a lot.
Two additional questions:
1) If I want 5 decimals can I just change the %12.4f% to %12.5% ?
2) the network runs pyraf on top of IRAF. Is it still safe to make the change to the network version or are there extra considerations?
Thanks again. You have my greatest respect.
Karsten
Mike Fitzpatrick wrote on Nov 22, 2006
1) If I want 5 decimals can I just change the %12.4f% to %12.5% ?
Yes, the formatting string follows time-honored fortran/C conventions but I would caution you that this doesn't necessarily mean you can trust all the numbers, the rules about floating-point precision still apply.
2) the network runs pyraf on top of IRAF. Is it still safe to make the change to the network version or are there extra considerations?
PyRAF is little more than a replacement for the CL command environment, compiled tasks won't know who/what is calling them and will print the output the same way.
-Mike
Karsten Brogaard wrote on Nov 22, 2006
fitz
1) If I want 5 decimals can I just change the %12.4f% to %12.5% ?
Yes, the formatting string follows time-honored fortran/C conventions but I would caution you that this doesn't necessarily mean you can trust all the numbers, the rules about floating-point precision still apply.
-Mike
What rules about floating-point precision are you refering to?
Karsten
Mike Fitzpatrick wrote on Nov 22, 2006
Only that a single-precision real is still a 32-bit floating-point number, and beyond 5-6 decimals or so you cannot trust the value. Combined with the fact you want to print a number which is a derived fit where the input params will weigh on the final value, just because you might print a bunch of decimals doesn't mean they are all valid in the real world.
Printing more numbers past the decimal point does not mean you're doing better science.
-Mike
Printing more numbers past the decimal point does not mean you're doing better science.
-Mike
Karsten Brogaard wrote on Nov 22, 2006
fitz
Only that a single-precision real is still a 32-bit floating-point number, and beyond 5-6 decimals or so you cannot trust the value. Combined with the fact you want to print a number which is a derived fit where the input params will weigh on the final value, just because you might print a bunch of decimals doesn't mean they are all valid in the real world.
Printing more numbers past the decimal point does not mean you're doing better science.
-Mike
Your stament is of cource true to some point. So I have checked that ecidentify has lineidentifications with 4 decimals. This means that the mean zero point shift should also be correct to 4 decimals and therefore I gain precision and improve my science by including 4 decimals instead of 2. But I see your point that the 5th digit will not improve my results! Do you agree with my statements?
Karsten
Mike Fitzpatrick wrote on Nov 22, 2006
I agree to a point: You still need to prove that the extra decimals in the output actually mean something based on the characteristics of your data and the algorithm used to derive the numbers.
I can tell you how to modify the code to do everything in double-precision and print out even more numbers, but it is still up to you to derive your zero-point to the best of your ability based on the data, not a print statement where the format code can be non-sensical. IRAF tasks can do things like print nano-mag photomtetry values, but nobody would believe it, so the precisions chosen are not alwa arbitrary.
-Mike
I can tell you how to modify the code to do everything in double-precision and print out even more numbers, but it is still up to you to derive your zero-point to the best of your ability based on the data, not a print statement where the format code can be non-sensical. IRAF tasks can do things like print nano-mag photomtetry values, but nobody would believe it, so the precisions chosen are not alwa arbitrary.
-Mike
Karsten Brogaard wrote on Nov 22, 2006
fitz
I agree to a point: You still need to prove that the extra decimals in the output actually mean something based on the characteristics of your data and the algorithm used to derive the numbers.
I can tell you how to modify the code to do everything in double-precision and print out even more numbers, but it is still up to you to derive your zero-point to the best of your ability based on the data, not a print statement where the format code can be non-sensical. IRAF tasks can do things like print nano-mag photomtetry values, but nobody would believe it, so the precisions chosen are not alwa arbitrary.
-Mike
Are you saying that ecreidentify is not calculating the shift better than 2 decimals? That would mean that it is uncertain by more than 3 m/s and therefore not usable for ajusting drifts of stable spectrographs since the shift might introduce more error than it takes away. I guess I will have to test it if you do not know the answer.
Karsten
Mike Fitzpatrick wrote on Nov 22, 2006
I can't say whether more precision would help you, only that we've gotten requests for 6 decimals of precision from the e.g. photometry/RV tasks in the past that had no real basis in science but gave the user a warm fuzzy feeling they were doing better. Be careful you don't fall into that trap.
-Mike
-Mike
Karsten Brogaard wrote on Nov 22, 2006
fitz
I can't say whether more precision would help you, only that we've gotten requests for 6 decimals of precision from the e.g. photometry/RV tasks in the past that had no real basis in science but gave the user a warm fuzzy feeling they were doing better. Be careful you don't fall into that trap.
-Mike
Thank you for your warning. I will make some test to see if more precision helps me or not. My feeling is that it will. You see ecreidentify calculates the shift as a mean of the shift of all the individual orders. If I then round off the shift before I calculate back and apply the shift to the individual orders I will have introduced errors. Whether or not these are important I will see when I calculate the rms of individual observations of a stable star.
You may comment on this if you like but otherwise I think it is time to close this case. I would like to thank you again for your quick and precise help and your comments :D
Karsten
Karsten Brogaard wrote on Nov 22, 2006
Sorry to have to bother you again but when we tried to implement the decimal change on the network version we got error messages. We think is might be connected to the fact the iraf runs on a 64 bit AMD machine. Hope you can help. Below is the errors:
Karsten[/code]
[root@mblade root]# su - iraf
iraf@mblade.phys.au.dk% cd /iraf/iraf/noao
iraf@mblade.phys.au.dk% mkpkg -p noan $IRAFARCH
envinit: cannot open `/ai45/iraf/iraf/noao/noanlib/zzsetenv.def'
Warning, mkpkg line 0: cannot open `noan$lib/mkpkg.inc'
system is already configured for redhat
iraf@mblade.phys.au.dk% cd onedspec
iraf@mblade.phys.au.dk% mkpkg -p noao update
Subdirectory dispcor is up to date
Subdirectory ecidentify/ecffit is up to date
Subdirectory ecidentify is up to date
Subdirectory fortran is up to date
Subdirectory identify/autoid is up to date
Subdirectory identify is up to date
Subdirectory irsiids is up to date
Subdirectory scombine/generic is up to date
Subdirectory scombine is up to date
Subdirectory sensfunc is up to date
Subdirectory splot is up to date
Library libpkg.a is up to date
Object x_onedspec.o is up to date
xc -Nz -p noao x_onedspec.o libpkg.a -lsmw -lxtools -lcurfit -lgsurfit
-liminterp -lllsq -o xx_onedspec.e
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
/usr/bin/ld: libpkg.a(t_ecreid.o): invalid string offset 1700754432 >= 802 for
section `.strtab'
/usr/bin/ld: libpkg.a(t_ecreid.o): invalid string offset 1600323635 >= 802 for
section `.strtab'
libpkg.a(t_ecreid.o)(*ABS*+0x7300315f5f630033): multiple definition of `no
symbol'
Warning, mkpkg line 7: module `relink' not found or returned error
move `xx_onedspec.e' to `noaobin$x_onedspec.e'
$move: file `xx_onedspec.e' not found
Warning, mkpkg line 19: error moving file xx_onedspec.e
Warning, mkpkg line 8: module `install' not found or returned error
iraf@mblade.phys.au.dk%
Karsten[/code]
Mike Fitzpatrick wrote on Nov 22, 2006
Right, compilation isn't supported on 64-bit systems. I've made the change and put a binary at http://iraf.net/ftp/pub/fitz/x_onedspec.e.RHUX for you. Download in binary mode and install it as noaobin$x_onedspec.e, be sure to set the execute permissions and make a backup of the existing binary. Let me know if you have any problems with it .
Cheers,
-Mike
Cheers,
-Mike
Last post on Nov 22, 2006