iraf.net

I would need to change the precision of the magnitudes outputted by the PHOT package, increasing it from three to (ideally) five decimals. This is exactly what was asked here almost eight years ago, where Phillip Warner, along with instructions on how this could be done, warned that:[quote:69aa0d7d3f]The length can be modified fairly easily. However, I should mention a word of caution, of which you are probably aware: the magnitudes calculated are single precision. Although some of the values you used in the calculation are double precision, the result is still single. Hence, you should be aware that anything smaller than millimagnitude results will probably be considered non-scientific.[/quote:69aa0d7d3f]a) Is there any hope that this was changed in these years? Does anybody know whether IRAF still uses single precision? If so, could anybody explain me why this is not as easy as one may be tempted to think? In other words, why isn't that as simple as changing all the variables involved to double precision?b) In any case, how come IRAF is (was?) only reliable up to the millimagnitude? I'm not familiar with the algorithms implemented in the package, but according to Wikipedia the IEEE 754 single-precision binary floating-point format gives "from 6 to 9 significant decimal digits precision".Thanks!

Memory issues were a big problem back then I suspect.Dunno if this will help you, but using the magnitude formula on the flux values from the phot help file gets some of that precision back and is a good work-around when you are probably importing everything into some spreadsheet or code anyway.

[quote:c3b5b7639a="iaa"]I would need to change the precision of the magnitudes outputted by the PHOT package, increasing it from three to (ideally) five decimals....
Thanks![/quote:c3b5b7639a]Would those digits really be significant? I don't know what magnitude you are working at but if they are typical stellar sources, there's a good chance those extra digits would mean nothing.Jason

Exoplanet transits and camera stability tests are two such applications that demand sub-millimag precision, so yes. I'm sure there are more, but I've only needed it for the latter.

We would need them for exoplanet transits.
Thanks for your suggestion, azangari.

The science case for sub-millimag photometry for exoplanets is clear, what is less clear is whether simply printing more digits is really significant. For instance, if even minor differences in the choice of the center position or FWHM value produce changes in the magnitude at the 0.001 level would you continue to trust the numbers to the right of that value anyway? Just because the task prints 6 values to the right of the decimal do you really think you have micro-mag accuracy?Changing the output formatting for the task isn't hard, but likewise doesn't mean those extra digits are significant scientifically. Modifying the task to use double-precision is somewhat harder (lots of code and library interfaces to deal with, then lots of verification to be sure you get the same answers to at least the previous precision) but doable, but then proving that the code is really giving you better than millimag photometry is the really hard part (and a research project unto itself).I believe the original formatting was chosen to fit on an 80-char screen and with known limitations of the algorithm in mind. If you can show me the task is stable at the millimag level and more digits are warranted we can certainly change the format, otherwise I'm happy to tell you how to modify your system to do so with the caveat that printing 6 decimals won't assure your Nobel Prize.

How do you know whether the numbers would be significant or not?About six months ago I finished up a paper on the stability of a camera, and I measured changes in differential photometry of artificial stars as a result of doing things to the camera such as changing the CCD temperature and changing the controller temperature. The project produced about a terabyte of data including 2-s images of the fake field taken for about 14 hours straight. That was the longest data set.I analyzed these data using the apphot package.Because the precision of the "mag" output was not enough, I recalculated instrumental magnitudes using the "flux" output from the .mag.1 file and then converted to instrumental magnitudes using the code that I used to analyze my data and make plots.I could pin most bumps and wiggles in star location and magnitude and correlate them to the same changes in camera temperature at the millimag level. I also calculated where the turnoff of the Allen deviation would be, and even when screwing around with the camera, the maximum average precision came out to be about a part in 10^-4, with the best data set (that long one) not really turning off at all and approaching the ability to be averaged to about 10^-5. Anyway, I wrote a report about all of this for the instrument team with a lot of plots, and I still have all the original .mag. files as well as my code on my laptop. I suspect this might answer the questions about how useful the code is down for sub-millimag precision. What would be useful from this analysis?

[quote:3bef0b4158]How do you know whether the numbers would be significant or not?[/quote:3bef0b4158]Honestly, I don't. However, beyond changing the format statements to print the extra digits, its a lot of work to modify the tasks without some assurance of a payoff. Much of the APPHOT package is already in double precision, DAOPHOT less so.The point is, just because IEEE precision is 6-9 significant digits that does not mean APPHOT/DAOPHOT
algorithms give accuracy at the same level. If there is a consensus in the community (or even a few more comments posted to this thread) we can certainly change the formatting for the next release. If you like I could give you a patched binary for apphot with the change if you want to see whether the increased precision in the mag output gives you the same accuracy as your own code. Otherwise, were the positions you used the known values for the artificial stars or values found from a task like DAOFIND?[/quote]

Depending on the month the data were taken, I used one of two sets of initial coordinates for the artificial stars for each "night" that I grabbed from some random frame using daofind. In any case, I set calgorithm to centroid and re-centered during photometry, so that nullifies daofind's limitation.Actually, I'm not sure if I used daophot or apphot-- I'm thinking it WAS daophot, but I didn't write it down. My mag files all say "apphot" under "package", but so do the mag files from a completely project where I am 100% certain I am using daophot and have never opened apphot at all (apphot does not do 2-order variable PSF fits :-P). It may be that daophot has been using apphot's phot for a while now anyway.#N RAPERT SUM AREA FLUX MAG MERR PIER PERROR \
#U scale counts pixels counts mag mag ## perrors \
#F %-12.2f %-14.7g %-11.7g %-14.7g %-7.3f %-6.3f %-5d %-9s
#Isn't every thing else up to mag a double anyway? That's what the g means, right? (Itime, zmag and msky are "g" variables as well)I'm confused about how running a beta binary on my actual images would help compare the two programs if everything else that went into the "mag" number was already double to begin with. Couldn't you just generate a bunch of random numbers less than 10 million with up to seven decimals, call the variable "flux" and then run them through mag = zmag - 2.5 * log10 (flux) + 2.5 * log10 (itime) in both IRAF and IDL and see if the numbers come out the same? But even that seems a little silly.My flux numbers were 6-7 digits before the decimal with at most 2 decimal places, usually one (I did the experiment with and without overscan correction as the only reduction).Sample output:
txdump *.fits.mag.1 image,id,xcenter,ycenter,xerr,yerr,cier,mag,merr,pier,flux,msky,nsky,nsrej,sier yes
c01r.0002.001.fits 1 232.502 280.540 0.001 0.001 0 11.098 11.096 11.094 0.001 0.001 0.001 0 0 0 723094.9 724315.4 725971.1 9.132444 1870 10 0
c01r.0002.001.fits 2 351.643 289.371 0.001 0.002 0 11.677 11.675 11.672 0.001 0.001 0.001 0 0 0 423976.3 424836.6 426011.2 9.197869 1882 5 0
c01r.0002.002.fits 1 232.502 280.539 0.001 0.001 0 11.088 11.086 11.084 0.001 0.001 0.001 0 0 0 729466.4 730792.4 732519.9 9.110371 1875 5 0
c01r.0002.002.fits 2 351.645 289.366 0.001 0.002 0 11.666 11.663 11.660 0.001 0.001 0.001 0 0 0 428596.7 429538.7 430833.9 8.880352 1877 10 0[/quote]

[quote:5b950ced1e]Isn't every thing else up to mag a double anyway? That's what the g means, right? (Itime, zmag and msky are "g" variables as well) [/quote:5b950ced1e]The 'g' means the argument is a double but should be printed in 'f' or 'e' format as needed. OTOH, use of 'g' with a single-precision argument is common as well.[quote:5b950ced1e]I'm confused about how running a beta binary on my actual images would help compare the two programs if everything else that went into the "mag" number was already double to begin with. Couldn't you just generate a bunch of random numbers less than 10 million with up to seven decimals, call the variable "flux" and then run them through mag = zmag - 2.5 * log10 (flux) + 2.5 * log10 (itime) in both IRAF and IDL and see if the numbers come out the same? But even that seems a little silly. [/quote:5b950ced1e]It wouldn't be a beta, it would simply be a binary that prints the extra digits asked for (you could make the change locally yourself). The point was that if the original file didn't have enough decimals for you to use the mag column directly, would having the extra digits fix that and give you the same results as you got from converting the flux values to mags using your own code. If so, the iraf output is good to the same 10^4 (or 10^5) places you found before.Computing the 'mag' equation to double precision is trivial, but the 'flux' value is not an absolute; It is a value derived from the image as it was reduced through CCDPROC, DAOFIND centering, use choice of FWHM and scaling parameters, fit solutions, and so on. Each of those things creates an error bar, the question is whether that error is at the same 10^5 level.A timely (April 1) example of what I mean is at:http://www.guardian.co.uk/science/life-and-physics/2012/apr/01/1?CMP=twt_gu