-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
muon analysis r0 to dl1 specific function #556
base: main
Are you sure you want to change the base?
Conversation
Codecov Report
@@ Coverage Diff @@
## master #556 +/- ##
==========================================
- Coverage 37.46% 37.43% -0.04%
==========================================
Files 82 82
Lines 7350 7352 +2
==========================================
- Hits 2754 2752 -2
- Misses 4596 4600 +4
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Look ok to me, thanks for this clean-up.
You say "in preparation of stage 1", but if we move to using directly the stage 1 tool (with all low-level calibs in ctapipe_io_lst), the whole muon analysis will have to be inside ctapipe, I think. On the other hand, that will not be the case if we just introduce a DL1 writer "à la ctapipe" in lstchain's r0_to_dl1, which is perhaps a faster path to have ctapipe-compatible LST1 DL1 files.
@moralejo I have not yet come around to doing it, because it is not needed until the rest works, but see cta-observatory/ctapipe#1353 |
Hi, thanks @vuillaut |
Yes, it works, I get the same muon file after processing a real data file. |
# in calculation of muon ring time (peak sample): | ||
min_pe_for_muon_t_calc = 10. | ||
|
||
# FIXME: no need to read telescope characteristics like foclen for every event! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can remove this FIXME comment, it is a pretty old comment in which I misinterpreted that this would imply some re-reading from disk.
|
||
bad_pixels = event.mon.tel[telescope_id].calibration.unusable_pixels[0] | ||
# Set to 0 unreliable pixels: | ||
image = event.dl1.tel[telescope_id].image*(~bad_pixels) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there in ctapipe already some pixel interpolator? Would be interesting to test it. Should be better in case of isolated bad pixels (perhaps a bit dangerous when a whole pixel cluster is unreliable).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there is, but yes, I think it is necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be easy enough to implement approaches like a mean of correct neighbors using the neighbor matrix.
Can we update this? I still think it would be good to separate the large imperative code in r0_to_dl1 |
step by step cleaning of the r0_to_dl1 step
In preparation for stage1: the final goal is to use directly the stage1 but a step by step approach and some code cleaning will make things easier I think and help us understand better the current status.