Join GitHub today
Add create fixed time interval method for light curves #1339
Added a simple function which create a light curve with a given time binning called create_fixed_time_bin_lc
Added a security in compute_flux_point which returned an error if the condition line 407 was always true for a given interval. This might happen for example if the interval is fully between two observations.
Added the use of the previous change in light_curve to save only the valid lc point in the final light curve object.
@gabemery - Thank you for the PR!
I've left a few inline comments. Two more thoughts:
- please add a test executing your new function once, and asserting something about the return value that shows that the function does what the docstring says.
- your use of
useintervalthat introduces if statements and more complex function return values in the code seems sub-optimal. Would it be possible to simplify this, by introducing a new function which takes a list or table of time intervals, and filters out the ones with zero observations? Would that be better or worse than what you put?
Generally, I'm not sure how complex of time interval handling code we need in Gammapy. Either we develop our own little set of functionality, or if it's nontrivial, we could also copy some existing code like https://github.com/chaimleib/intervaltree into
gammapy/extern and import and use that, re-exposing it in a simple way to end-users to get the common methods to compute time intervals or intersect desired time intervals with available observation intervals. Just a thought for a possible long-term solution for Gammapy.
Thanks for your review,
About the useinterval usage, it is the only solution I found as counting the number of events in each intervals and filtering the empty ones didn't work (for unknown reasons). An other solution might be found but I'm not sure I will be the one to find it.
The change to only give the interval with the new function has been done as well as the test and a re-writing of the docstring. if all of this seems ok my proposition is to merge as it is for the "useinterval" in order to have a fix. Optimization for the execution time can then be done in another pull request
Small follow-up commit: 241944a