Repository navigation
[5.2] imexam test fails with Gaussian2DKernel, Gaussian2DModel #14226
Description
Description
After upgrading Astropy to 5.2, one imexam test fails that takes the array out of a Gaussian2DKernel, tries to fit a Gaussian and compares the result with the original parameters. Specifically the normalization was compared to be equal with an rtol=1e-6; with astropy 5.2 the relative error increased ~1e-3.
This was originally reported to imexam as spacetelescope/imexam#255; however I actually think that this is probably a regression in Astropy: The test takes the Gaussian2DKernel, and the fit is done with the Gaussian2dModel+Polynomial2DModel.
Expected behavior
I would expect that the array of a Gaussian2DKernel would not change between versions, and the fitting with identical data should produce identical results.
Steps to Reproduce
This is from the log, which shows how to reproduce the failure:
______________________________ test_gauss_center _______________________________
def test_gauss_center():
"""Check the gaussian center fitting."""
from astropy.convolution import Gaussian2DKernel
# This creates a 2D normalized gaussian kernal with
# a set amplitude. Guess off-center
amp = 0.0015915494309189533
size = 81.0
sigma = 10.0
gaussian_2D_kernel = Gaussian2DKernel(sigma, x_size=size, y_size=size)
plots = Imexamine()
plots.set_data(gaussian_2D_kernel.array)
a, xx, yy, xs, ys = plots.gauss_center(37, 37)
> assert_allclose(amp, a, 1e-6)
E AssertionError:
E Not equal to tolerance rtol=1e-06, atol=0
E
E Mismatched elements: 1 / 1 (100%)
E Max absolute difference: 1.61872075e-07
E Max relative difference: 0.0001017
E x: array(0.001592)
E y: array(0.001592)
/usr/lib/python3/dist-packages/imexam/tests/test_imexamine.py:128: AssertionError
----------------------------- Captured stdout call -----------------------------
xc=40.0000 yc=40.0000
------------------------------ Captured log call -------------------------------
INFO imexam.util:imexamine.py:1015 xc=40.0000 yc=40.0000
System Details
- System: Debian testing
- Python 3.10.9
- Numpy 1.23.5
- Scipy 1.8.1
- Astropy 5.2
- imexam 0.9.1
Activity
pllim commentedon Dec 23, 2022
cc @keflavich @larrybradley @sosey
dhomeier commentedon Feb 3, 2025
imexam has been unmaintained for some time and not really had an update in 6 years – we should probably take some action on its affiliated status.
dhomeier commentedon Feb 3, 2025
The actual failure is due to the change in normalisation for kernels as described in #13299 (comment); so technically the old behaviour was a bug. I don't see a problem with the actual fitting done in the example above –
amp = 0.0015915494309189533just is the maximum value under the old construction method (which took the normalisation of the untruncated kernel to be 1); for the input data constructed under the new normalisation that is0.0015917113029941471.pllim commentedon Feb 3, 2025
Also imexam issue can go to https://github.com/spacetelescope/imexam
olebole commentedon Feb 3, 2025
@pllim I opened it there: spacetelescope/imexam#255 However I was not sure whether it is really an imexam problem, that's why I made another issue here 😁
dhomeier commentedon Feb 3, 2025
As
imexamfitting is concerned, there seem to be much more serious problems with callingoptimize.leastsqnow –not sure if due tothis is fixed by #17618.astropy.modelingitself or Scipy / Numpy 2.x.github-actions commentedon Feb 4, 2025
Hi humans 👋 - this issue was labeled as Close? approximately 14 hours ago. If you think this issue should not be closed, a maintainer should remove the Close? label - otherwise, I will close this issue in 7 days.
If you believe I commented on this issue incorrectly, please report this here
dhomeier commentedon Feb 10, 2025
@olebole I've marked this as Close? since the change in Gaussian amplitude was done by design in 5.2 (even if perhaps insufficiently documented?).
But the status of imexam certainly brings up the question of re-reviewing affiliated packages as first laid out in APE 22. We don't have a timeline set forth when and how to apply this to the packages from our existing ecosystem, but since Debian provides a metapackage including all those packages by default, this would certainly affect it.
Question is, would packaging generally become easier when affiliated packages are retired sooner once they are no longer properly maintained, or would that rather be counter-productive, since your users expect a stable collection of packages with the same contents?