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
Add background estimation for phase-resolved spectra #1426
@msjacob - Thanks!
Apologies for the late response here!
I think this is a good addition. We can iterate on this a bit here, but basically I think we should get a working pulsar analysis in Gammapy and have a notebook docs example, and then once we see what we have we can still discuss if it can be structured in a better way.
The main thing that's missing here is a test case.
I wanted to suggest that you access something like
ds = DataStore.from_dir('$GAMMAPY_EXTRA/datasets/cta-1dc/index/gps/')
and use one or two obs from there for the test case.
But then I realised that there the
PHASE column is missing.
I also see that you added this:
but I think there the problem is that you don't easily get an
ObservationList object, right?
There's a few options, ranging from preparing a test dataset that works, or changing your code. E.g. you work with
DataStoreObservation objects in your methods, but then only access the
EventList from there. So changing the API to take
EventList objects instead could be possible. On the other hand, at some point for the spectral analysis you will need to correct the livetime for the on phase selection, so then it's not clear to me where that correction factor is best applied.
@msjacob - What do you think? Do you see a way to add a test?
The other suggestion I'd make is concerning the phase selection. Users will wonder how it works exactly and what is / isn't possible. Suggest to add some text or example to the docstring. For now, I think only a single interval is supported, and it can't wrap, i.e. be from 0.8 to 0.3. You don't do any wrapping of phases or support intervals that wrap below 0 or beyond 1. Can you state that in the docstring?
To have a more flexible phase selection API, I'm not sure how to do it. One idea could be to use lists of intervals, so that one can select e.g. an off phase from 0.1 to 0.2 AND from 0.5 to 0.7. Another idea could be to wrap PHASE to always 0 to 1 (or assume it's already wrapped like that), and then to also support wrapped phase selection, e.g. 0.7 to 0.2 would be like 0.7 to 1.0 AND 0.0 to 0.2. Another idea would be to introduce a
PhaseSelection object that's just a few lines long for the default interval selection. But then users could write their own and pass it in to apply the phase selection. It would also have a "fraction" attribute that is then used for the livetime correction factor.
@msjacob - Any of those ideas / additions can come later or never. If you stick with the current implementation, please add two lines to the docstring to document what is done exactly and that there's this limitation that with the current scheme only simple interval phase selection isn't possible.