I want to alert people that there is a bug in version 2.1.24 of cmunipack, the computational back-end of MuniWin. In a nutshell, the apertures actually used in the photometric processing are likely smaller than the ones the user specifies. For a given CCD frame, the diameter of any aperture will be limited to about 0.7 times that of the largest aperture. The munipack project has confirmed the problem, but I have no information as to long it has been present or when it will be fixed. From a practical standpoint, this will cause a loss of star counts and an over-estimate of sky counts. If all apertures are the same size, the consequences will at least be consistent for all stars in the frame. One could work around this problem by placing a honking-big dummy aperture somewhere.
Tom
Hi Tom,
Some of your description raised a flag in my mind. As long as you use the same aperture size for all objects in your frame, there should be little affect in the photometry. If, for example, you took measures with different aperture sizes to get a curve of growth, you'd just end up selecting an aperture a little bigger than you thought you needed. Of course, you should get the aperture size that you select, so this is a real bug.
However, you imply that you use different apertures for different objects in your image. This is normally considered something to avoid. Can you clarify this for me? Thanks!
Arne
Arne
I have never used MuniWin myself - I was pawing through the munipack source code in an attempt to understand something that looked strange in another observer's photometry. Exactly how and why different size apertures would be used I do not know, but the code supports them.
I'm advised that the bug fix is now available on SourceForge
I use Munipack in my photometry pipeline so I was keen to find out if this has affected my results.
The bottom line is no. There are some situations where apertures are actually smaller than the radius you think you are using, but because within a time-series the same radius aperture is applied to all stars, and frames, the results are valid.
The details:
This is from David Motl, the project manager for the package: Quote##########
the bug was in fotometr.c, line 68
The original code was:
apmxsq = (apmax+0.5)*(apmax*0.5);
while the correct formula is:
apmxsq = (apmax+0.5)*(apmax+0.5);
The apmax is the radius of the largest aperture. In the default setting, the largest aperture is of 30.0 pixels. The original code gives apmxsq = 457.5, the correct value shall be 930.25. The only usage of the apmxsq is to pre-filters pixels that are checked later to size of individual apertures. Simple Euklidean distance r^2 = dx^2 + dy^2 <= A^2, where A is radius of the largest aperture. Speed optimization to speed up the computation by skipping pixels that do not fit even to the largest aperture.
The original code has the same effect as if the largest apeture was 20.89 (if the largest aperture is set to 30.0). If you don't use apertures above 20.89, you won't see any difference. In the standard settings the apertures #10, #11 and #12 are affected. For the aperture #10 and above, the new software gives different magnitudes and error estimations, for apertures up to #9, the results from both versions are the same.
#############Unquote.
So the 'some situations' I talked about above, are where you have changed the default size of the largest of the set of apertures that Munipack applies on each time-series (internally, a separate time-series is done for each of these apertures but the user picks one to be output), and you choose to actually output using an aperture that is larger than ~0.7 of the largest aperture.
In any case, the bug has now been fixed.
Hope this helps.
TG