-
Notifications
You must be signed in to change notification settings - Fork 270
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
Fixing core reconstruction #777
Fixing core reconstruction #777
Conversation
Codecov Report
@@ Coverage Diff @@
## master #777 +/- ##
==========================================
+ Coverage 71.54% 71.54% +<.01%
==========================================
Files 199 199
Lines 10824 10826 +2
==========================================
+ Hits 7744 7746 +2
Misses 3080 3080
Continue to review full report at Codecov.
|
Nice one. We should check if thats actually a bigger problem. Maybe connected to #721 |
I don't think this should have been merged, as Kai found the underlying reason which was the azimuth rotation, not a minus sign for y. |
Ah, that wasn't clear from the discussion. I could revert it, or just wait for a general fix. Which would you prefer? |
I think it's better to revert, as #778 fixes the problem at the azimuth level. Even better would be to fix it inside the coordinates module, not outside before using the functions. |
Discussing with @TarekHC, @mackaiver and @moralejo we found that there was a bug in the calculation of the core position. I've tracked this down to being a wrong sign in one component of the norm vector in the HillasPlanes. In order to not break the direction reconstruction I added two lines which only change the y-component's sign of the norm vector in the estimation of the core position and should not affect anything else.
In this plot right here, you can clearly see that the old reconstruction of the position (blue diamond) was nonsense and the fixed estimate in red is clearly getting close to the true position (black).