ecreidentify - iraf.net

Welcome to iraf.net Friday, April 19 2024 @ 03:12 AM GMT

	Forum Index > Help Desk > Applications	New Topic	Post Reply
ecreidentify

Anonymous: Guest

11/22/2006 07:18PM (Read 14636 times)

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 faithfullyKarsten Brogaard
University of Aarhus, Denmark

fitz

11/22/2006 07:18PM

Admin

Status: offline

Registered: 09/30/2005
Posts: 4040

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

karsten brogaard

11/22/2006 07:18PM

Junior

Status: offline

Registered: 11/22/2006
Posts: 15

[quote:2717a7f568="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[/quote:2717a7f568]The number I am after is the 'user shift'

fitz

11/22/2006 07:18PM

Admin

Status: offline

Registered: 09/30/2005
Posts: 4040

I believe then that you need to change the format on line 158 of noao$onedspec/ecidentify/t_ecreid.x, which now reads[code:1:2dbfe7ce89] call fprintf (fd,
"%20s %3d/%-3d %3d/%-3d %9.3g %10.3g %7.3g %7.3g\n")
[/code:1:2dbfe7ce89]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:[code:1:2dbfe7ce89]
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
[/code:1:2dbfe7ce89]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

11/22/2006 07:18PM

Junior

Status: offline

Registered: 11/22/2006
Posts: 15

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

fitz

11/22/2006 07:18PM

Admin

Status: offline

Registered: 09/30/2005
Posts: 4040

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

karsten brogaard

11/22/2006 07:18PM

Junior

Status: offline

Registered: 11/22/2006
Posts: 15

[quote:230f137864="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[/quote:230f137864]Yes I assumed somthing like that since I could not find the file in the other directory. Sorry for not trusting a superior experience.

Anyway I just wanted to say that your suggestion solved my problem, the result now comes with 4 decimals like I asked

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

fitz

11/22/2006 07:18PM

Admin

Status: offline

Registered: 09/30/2005
Posts: 4040

[quote:b0796c9ccb]1) If I want 5 decimals can I just change the %12.4f% to %12.5% ?[/quote:b0796c9ccb]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.
[quote:b0796c9ccb]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? [/quote:b0796c9ccb]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

11/22/2006 07:18PM

Junior

Status: offline

Registered: 11/22/2006
Posts: 15

[quote:ecc4cd38c4="fitz"][quote:ecc4cd38c4]1) If I want 5 decimals can I just change the %12.4f% to %12.5% ?[/quote:ecc4cd38c4]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[/quote:ecc4cd38c4]What rules about floating-point precision are you refering to?Karsten

fitz

11/22/2006 07:18PM

Admin

Status: offline

Registered: 09/30/2005
Posts: 4040

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

karsten brogaard

11/22/2006 07:18PM

Junior

Status: offline

Registered: 11/22/2006
Posts: 15

[quote:38fca0bf80="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[/quote:38fca0bf80]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

fitz

11/22/2006 07:18PM

Admin

Status: offline

Registered: 09/30/2005
Posts: 4040

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

karsten brogaard

11/22/2006 07:18PM

Junior

Status: offline

Registered: 11/22/2006
Posts: 15

[quote:b0697a98e5="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[/quote:b0697a98e5]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

fitz

11/22/2006 07:18PM

Admin

Status: offline

Registered: 09/30/2005
Posts: 4040

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

karsten brogaard

11/22/2006 07:18PM

Junior

Status: offline

Registered: 11/22/2006
Posts: 15

[quote:612a81f728="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[/quote:612a81f728]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

Karsten

karsten brogaard

11/22/2006 07:18PM

Junior

Status: offline

Registered: 11/22/2006
Posts: 15

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:

1:7583D576CF Formatted Code

&#91;root@mblade root&#93;# su - iraf

iraf@mblade.phys.au.dk% cd /iraf/iraf/noao

iraf@mblade.phys.au.dk% mkpkg -p noan $IRAFARCH

envinit&#58; cannot open `/ai45/iraf/iraf/noao/noanlib/zzsetenv.def'

Warning, mkpkg line 0&#58; 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&#58; ld terminated with signal 11 &#91;Segmentation fault&#93;, core dumped

/usr/bin/ld&#58; libpkg.a&#40;t_ecreid.o&#41;&#58; invalid string offset 1700754432 &gt;= 802 for

section `.strtab'

/usr/bin/ld&#58; libpkg.a&#40;t_ecreid.o&#41;&#58; invalid string offset 1600323635 &gt;= 802 for

section `.strtab'

libpkg.a&#40;t_ecreid.o&#41;&#40;*ABS*+0x7300315f5f630033&#41;&#58; multiple definition of `no

symbol'

Warning, mkpkg line 7&#58; module `relink' not found or returned error

move `xx_onedspec.e' to `noaobin$x_onedspec.e'

$move&#58; file `xx_onedspec.e' not found

Warning, mkpkg line 19&#58; error moving file xx_onedspec.e

Warning, mkpkg line 8&#58; module `install' not found or returned error

iraf@mblade.phys.au.dk% 

[/code:1:7583d576cf]

Karsten

fitz

11/22/2006 07:18PM

Admin

Status: offline

Registered: 09/30/2005
Posts: 4040

Right, compilation isn't supported on 64-bit systems. I've made the change and put a binary at https://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

Content generated in: 0.66 seconds

	Normal Topic
	Sticky Topic
	Locked Topic

	New Post
	Sticky Topic W/ New Post
	Locked Topic W/ New Post

View Anonymous Posts

Anonymous users can post

Filtered HTML Allowed

Censored Content

dog allergies remedies cialis 20 mg chilblain remedies

Search

Privacy Policy
Terms of Use

Forum Menu

User Functions

Topics