Skip to content
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

Reconstruction fix (also for Divergent Pointing) #946

Merged
merged 55 commits into from
Jul 17, 2019
Merged

Reconstruction fix (also for Divergent Pointing) #946

merged 55 commits into from
Jul 17, 2019

Conversation

thomasgas
Copy link

I'm trying to analyze some MC in divergent pointing mode.
The reconstruction was not working out of the box due to few fixes needed to the HillasIntersection class after the coordinates refactoring in #896: seems to be working correctly now...I'm still working on this.
I've not checked the HillasReconstructor in divergent mode (see #873) yet. I just know that divergent pointing is not allowed now with HillasReconstructor.

@thomasgas thomasgas changed the title first attempt for Divergent Pointing Reconstruction fix for Divergent Pointing Feb 1, 2019
@codecov
Copy link

codecov bot commented Feb 1, 2019

Codecov Report

Merging #946 into master will increase coverage by 1.28%.
The diff coverage is 92.57%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #946      +/-   ##
==========================================
+ Coverage   84.25%   85.53%   +1.28%     
==========================================
  Files         181      183       +2     
  Lines       10979    11235     +256     
==========================================
+ Hits         9250     9610     +360     
+ Misses       1729     1625     -104
Impacted Files Coverage Δ
ctapipe/reco/reco_algorithms.py 90% <100%> (+6.66%) ⬆️
ctapipe/reco/HillasReconstructor.py 98.38% <100%> (+0.92%) ⬆️
ctapipe/reco/tests/test_ImPACT.py 63.51% <100%> (+1.54%) ⬆️
ctapipe/reco/tests/test_HillasReconstructor.py 94.78% <100%> (+0.33%) ⬆️
ctapipe/utils/unstructured_interpolator.py 62.85% <25%> (-1.85%) ⬇️
ctapipe/reco/ImPACT.py 44.25% <50%> (+1.44%) ⬆️
ctapipe/utils/template_network_interpolator.py 42.85% <50%> (+0.54%) ⬆️
ctapipe/reco/tests/test_reconstruction_methods.py 90.9% <90.9%> (ø)
ctapipe/reco/hillas_intersection.py 96.53% <94.73%> (+70.21%) ⬆️
ctapipe/reco/tests/test_hillas_intersection.py 96.72% <95.83%> (-3.28%) ⬇️
... and 11 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c154718...f5c847f. Read the comment docs.

@vuillaut vuillaut changed the title Reconstruction fix for Divergent Pointing WIP: Reconstruction fix for Divergent Pointing Feb 1, 2019
@maxnoe
Copy link
Member

maxnoe commented Feb 2, 2019

Can you create Test cases for the issues you fixed so this does not happen again?

@thomasgas
Copy link
Author

Can you create Test cases for the issues you fixed so this does not happen again?

The HillasIntersector class is not very well tested, so I think I can add some tests.

@kosack
Copy link
Contributor

kosack commented Feb 4, 2019

divergent pointing is not allowed now with HillasReconstructor

What do you mean by not allowed? It used to work (in a very old version, before coordinates were implemented anyhow). In principle, the methodology in HillasReconstructor should be better for divergent pointing, since no Nominal system is needed. The HillasIntersection one was just a copy of the HESS implementation, I think, and is not used anywhere. We should probably decide on a single method.

@maxnoe
Copy link
Member

maxnoe commented Feb 4, 2019

divergent pointing is not allowed now with HillasReconstructor

Multiple code path in the HillasReconstructor as it is now assume a common pointing position.
I found this out when debugging the diffuse reconstruction issue and added an exception for divergent pointing.

It it is possible to support divergent pointing in principle, then these code paths must be changed.
For me, there was no obvious, simple fix, so I just added the exception to make it clear that it currently does not support divergent pointing.

@ParsonsRD
Copy link
Member

Hi, I agree Karl the HillasReconstructor should work better here where the assumption of a flat nominal system starts to become a bad assumption. I created the HillasIntersection code as a baseline comparison as this is (as far as I know) the way all current instruments do their Hillas reconstruction (and also HillasReconstructor gave weird results at the time). I also agree that we should move towards removing HillasIntersection, but we should probably show the HillasReconstructor gives similar or better results at some point.

@kosack
Copy link
Contributor

kosack commented Feb 4, 2019

We should probably add a cross-check test between the two implementations, at least for some simple case (non-divergent for now I guess until both support it).

@kosack
Copy link
Contributor

kosack commented Feb 4, 2019

Also: I think we should just drop HorizonFrame and replace it by just using AltAz directly from astropy.coordinates

Agreed - if I recall correctly in HESS, there was a difference between AltAz and Horizon, but it was just related to the refraction correction (it was applied when going from Horizon to AltAz). I think in Astropy, that correction is applied when going from AltAz to ICRS (but we should verify), so there is no difference between Horizon and AltAz

@kosack
Copy link
Contributor

kosack commented Feb 4, 2019

yes, it looks like AltAz has an optional temperature and pressure option, which implies refraction gets corrected later. (http://docs.astropy.org/en/stable/api/astropy.coordinates.AltAz.html)

@thomasgas
Copy link
Author

thomasgas commented Feb 4, 2019

I run the analysis (to produce some angular resolution) on some point gamma produced with MSTs in divergent pointing and it seems it's working well with the 2D reconstruction method.

@@ -82,7 +82,7 @@ def predict(self, hillas_parameters, tel_x, tel_y, array_direction):
sky_pos = SkyCoord(
az=src_x * u.deg,
alt=src_y * u.deg,
frame=HorizonFrame()
frame=HorizonFrame(location=array_direction.location, obstime=array_direction.obstime)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't it then SkyCoord(az=..., alt=..., frame=array_direction.frame)?

Copy link
Author

@thomasgas thomasgas Feb 4, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes! in this way all the information in the frame should be passed.

@maxnoe
Copy link
Member

maxnoe commented Feb 7, 2019

So the tests are passing, but diff coverage is zero. So there are no tests covering HillasIntersection.

@kosack
Copy link
Contributor

kosack commented Feb 7, 2019

Yes, there need to be some unit tests if we want to keep this class - it's one of the reasons it has not been used. At least similar ones to those in HillasReconstuctor. Ideally, we could have common tests for all reconstructors, but so far the interfaces are not quite uniform.

@thomasgas
Copy link
Author

So the tests are passing, but diff coverage is zero. So there are no tests covering HillasIntersection.

Yes I know...I have in my to-do list to add some tests to this class...if someone wants to help, that would be great!
Plus we need some tests to compare the output of the two reconstruction methods.

@thomasgas
Copy link
Author

thomasgas commented Feb 12, 2019

I'm testing the output of the two reconstructors and it seems that the 3d gives better results that the 2d one (which is what is expected).
I'm ok for dropping the 2d as soon as we are sure about this and if I find a way of implementing the reconstruction for divergent pointing with the 3d method.
It's also easier to use the 3D method than the 2D one, since in the 3d method there's no need to use particular coordinate frames.

@ParsonsRD
Copy link
Member

Great! So does it give a significantly better angular resolution or just small improvements? Either way is good, but if it's much better it might be nice to make a plot of this to show to consortium to show that we are able to improve on "standard method" even with a fast Hillas based analysis.

@thomasgas
Copy link
Author

Great! So does it give a significantly better angular resolution or just small improvements? Either way is good, but if it's much better it might be nice to make a plot of this to show to consortium to show that we are able to improve on "standard method" even with a fast Hillas based analysis.

I tested it on few data and the 3D one is 50% to 100% better :D but i need more data and different pointings in order to be sure about this. And if someone else could do the same check, it would be great.

@ParsonsRD
Copy link
Member

tested it on few data and the 3D one is 50% to 100% better

Wow! That is impressive, if that holds for all events we should definitely show this somewhere, as I'm not sure that this method has been used by IACTs before.

@kosack
Copy link
Contributor

kosack commented Jun 19, 2019

Is divergent_mode really needed as an option? I would guess that in the general case where telescope have a pointing error, the correction you make is the same as what you would do for divergent pointing, so perhaps you want to do the divergent correction always? We only ever have the case where the array_pointing == telescope_pointings in an ideal monte-Carlo, and there may soon be MCs with real pointing-errors included, so perhaps that special case should not be the main one? You could then even get rid of array_pointing and calculate it from some barycenter of the telescope pointings.

@thomasgas
Copy link
Author

Is divergent_mode really needed as an option? I would guess that in the general case where telescope have a pointing error, the correction you make is the same as what you would do for divergent pointing, so perhaps you want to do the divergent correction always? We only ever have the case where the array_pointing == telescope_pointings in an ideal monte-Carlo, and there may soon be MCs with real pointing-errors included, so perhaps that special case should not be the main one? You could then even get rid of array_pointing and calculate it from some barycenter of the telescope pointings.

Yes I can remove the flag...it makes more sense to always do the divergent correction when the pointing is not exactly parallel (pointing corrections or divergent mode): I can just check that if the telescope_pointings is provided, the correction is applied.
Concerning the array_pointing I also thought at some point to get rid of that and use a barycenter of the telescope pointings, but it needs a bit of investigation. Having another reconstructor which also does the reconstruction of the impact point and of the position in the sky in one shot (and in 3D) would naturally remove the need for an array_pointing. That's material for separate PR.

@thomasgas
Copy link
Author

thomasgas commented Jun 19, 2019

More details on the fix for the divergent mode with the HillasReconstructor can be found here (slide 15): https://indico.cta-observatory.org/event/2114/contributions/19047/attachments/15148/19178/ASWG_Divergent_Montpellier.pdf

maxnoe
maxnoe previously requested changes Jun 19, 2019
ctapipe/reco/HillasReconstructor.py Outdated Show resolved Hide resolved
ctapipe/reco/HillasReconstructor.py Outdated Show resolved Hide resolved
Copy link
Contributor

@kosack kosack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While you're at it, it would be nice to change all the user-configurable parameters to be Traits and ensure Reconstructors are all sub-classes of Component (just changing the base class should work). Then we would be able to store and retrieve the options like weighting method, etc.

ctapipe/reco/HillasReconstructor.py Show resolved Hide resolved
@thomasgas
Copy link
Author

I implemented the suggested modifications (a part for the predict method which I think deserves some discussion).
I added some the warnings also to hillas_intersection and moved the warnings to the common reco_algorithms. Now both reconstructors import the warnings from there.
There is a test which loops over both reconstructors. We might clean a bit the duplicate tests and just keep the common one, moving the common tests there.

@thomasgas thomasgas requested review from maxnoe and kosack June 21, 2019 14:47
@thomasgas
Copy link
Author

A part from codacy complaining, is there any other problem in merging this PR? could someone review it? Should I merge the master into this branch again before merging the PR?

@kosack
Copy link
Contributor

kosack commented Jul 15, 2019

I think we're just waiting for @maxnoe (who's probably quite busy) or @ParsonsRD to give an ok. I Don't see any major issues. merging in master shouldn't be necessary since it doesn't touch any other changed files, but you could do it if you like.

The codacy issues look ok - it's mainly complaining about missing docstrings in the tests, which aren't really critical, so I'm ok ignoring that.

@ParsonsRD
Copy link
Member

OK I'll try to take a look today

Copy link
Member

@ParsonsRD ParsonsRD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the ImPACT changes look good to me

@kosack
Copy link
Contributor

kosack commented Jul 17, 2019

Ok, since we have 2 reviews and Max's requests seem to be addressed, I'll merge this.

@kosack kosack dismissed maxnoe’s stale review July 17, 2019 09:43

seems to be addressed

@kosack kosack merged commit 63fe206 into cta-observatory:master Jul 17, 2019
@thomasgas thomasgas deleted the small_coords_fix branch July 30, 2019 12:38
watsonjj added a commit to watsonjj/ctapipe that referenced this pull request Aug 12, 2019
* upstream/master:
  Reduce numba signatures to improve import time (cta-observatory#1108)
  Remove unused utils (cta-observatory#1112)
  Add method to read bright star catalog and find bright stars in sky region (cta-observatory#1105)
  Add Fields to calibration containers (cta-observatory#1111)
  Reconstruction fix (also for Divergent Pointing)  (cta-observatory#946)
  updated AUTHORS with latest mailmap
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants