Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix SkyPointSource evaluation #2367
In #2366 I remove the lon wrapping in sky model init, and noticed that there's one place in the Gammapy code where we do use lon wrapping that might break with that change:
I don't fully understand the implementation, but presumably it's some spherical variant of this:
The only test we have is this:
@adonath or anyone that wants to work on this:
I think in any case, the test for this complex and special model should be improved, e.g. also to put the source at lon = 0 or 180 deg, but also at a pixel center or corner, or to have a WCS where lon / lat pixel diff doesn't give the correct solid angle. (or do we have that kind of test already and I just missed it?). About half of analyses will use point source, so it's really important that we give correct results in those cases.
If we stick with the current implementation, we can probably improve it a bit, e.g. use the
I don't have the answer here, I don't know how other frameworks handle the point source case. Possibly dealing with this in a good way requires changing the spatial model interface completely to
Here's a notebook where I did some checks:
I think the incorrect fluxes at high lat are a real issue that we have to resolve?
I was expecting that the
Still, my recommendation and strong preference would be that we change sky models to work in the local WCS approximation at the source center, and evaluate using pixel coordinates. It's simpler, faster, consistent with how regions are implemented, and consistent with the fact that we do PSF convolution already on cartesian grid and that will remain. Yes, we wouldn't get correct results in images where WCS is extremely distorted, but that's anyways the case because PSF convolution doesn't work properly there (and never will).
@lmohrmann - Did you use
I think with the current implementation, point source fluxes should be incorrect, underestimated by a factor
For Crab at DEC=22deg, that's only 7%, and for PKS at DEC=-30deg, that's only 13%, so the error was by chance within HESS systematics. At higher DEC the effect would be stronger, e.g. 30% at DEC=45deg, so possibly other AGN analyses, or also Galactic analyses if someone used RA/DEC maps could have been incorrect.
There's also inter-pixel variations in the results that I don't fully understand yet, see e.g. the image in cell 22 here: https://nbviewer.jupyter.org/gist/cdeil/c4f978a86f53aef8c49b583d3e830540
It could be that for Gammapy v0.12 the bug wasn't present or smaller, because pixel solid angle was computed incorrectly in the
I discussed this with @adonath at lunch today - the idea is to fix
@adonath and I did some pair coding -- a regression test for the point source, and a fix is now attached, using the
@adonath - I think https://nbviewer.jupyter.org/gist/cdeil/c4f978a86f53aef8c49b583d3e830540 is now giving correct results, but it's slower than a few days ago (started 20 min ago, still running). Was expecting it to be about the same. But I'm not sure how long it ran previously really, maybe it was very slow already.
The test notebook runtimes seem OK:
My suggestion would be to merge this soon and continue, and if there's performance issues somewhere we'll track them down in the next days.