Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
PIG 2 - New low-level analysis code #1277
@registerrier - you currently have "PIG 2 - Organization of low-level analysis code" as title for the PIG and "Initial commit for the PIG 002" as title for the PR.
Can you please make them the same?
Do you plan to also outline 1-d spec analysis here, or only map-based analysis?
I saw a mention of "4D EDISP cube". Do we want to have spatially-dependent PSF / EDISP? Or only support spatially constant PSF / EDISP?
So far, in IACT, spatially dependent PSF / EDISP wasn't used. But for CTA with the higher precision it's probably needed at some point. There is no format spec yet, but ctools already has some FITS formats for that that we could probably just use if they are reasonable and in line with the maps formats that Matthew defined in the open spec. See ctpsfcube ctedispcube.
I think PSF / EDISP application in the likelihood fit would in many cases still be for a PSF kernel / EDISP matrix that isn't spatially varying, for simplicity and good speed, no? And spatially-dependent PSF / EDISP is something we would maybe implement separately later?
So @registerrier and all - what should we implement now, in the coming weeks? Is it extensible to the case of spatially-dependent PSF / EDISP in a backwards-compatible way (possibly by just adding new classes and functions for that case)? Or do we have to do the full design now?
This was referenced
Feb 2, 2018
The mention of a 4D object EDISP is mostly because to actually compute exposure in reco energy we need to convolve Expo(X,Y,Etrue) with EDISP(Etrue, Ereco). This is done in practice through a 4D EDISP(X,Y,Etrue, Ereco) which will be transient in memory.
This EDISP would probably dominate memory use. If it's not spatially dependent, then it should be possible to use Numpy broadcasting with a 2D EDISP and avoid the 4D. In the existing cube code from Lea, is it a 2D or 4D array? There's also the question with which maps EDISP works. Maybe just put these as questions in the document for now, and then we look at this in detail later this week?
referenced this pull request
Apr 12, 2018
@registerrier - Could you please finish up this PR?
I'd suggest to remove the code example file here, do minor text updates to reflect the fact that this PIG basically has been implemented in Gammapy in the past months (maybe pointing to the PR where you added the code to Gammapy) and then we merge this to have it on the record for the future.
IMO the goal is to continue the sprint on Gammapy this week and to have v0.8 ready by the end of the week and things cleaned up.