-
Notifications
You must be signed in to change notification settings - Fork 266
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
add Taubin fit #1154
add Taubin fit #1154
Conversation
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.
This looks like it could be a single function, nothing here is really statefull.
Codecov Report
@@ Coverage Diff @@
## master #1154 +/- ##
==========================================
+ Coverage 86.15% 86.24% +0.09%
==========================================
Files 182 185 +3
Lines 11546 11600 +54
==========================================
+ Hits 9947 10004 +57
+ Misses 1599 1596 -3
Continue to review full report at Codecov.
|
Hello, thanks for the first review @maxnoe and @kosack. At the moment the problem is, that what do you think? |
I'm confused. The kundu chauduri is a simple function: ctapipe/ctapipe/image/muon/fitting.py Line 23 in f34624a
|
I would also say that starting values are normally guessable. E.g. a weighted average for center x, y (or even just 0, 0) and the most common value (1.2 deg * focal length / fov) for the radius |
Ah ... I think we were confused as well. You are looking at Thanks for the hint, we'll have a closer look and come back later (after the weekend :-D) |
There is a lot of refactoring to do in the Muon module, so i wouldn't worry too much about its current design - let's try to simplify it as much as possible. I would suggest doing what we did in other modules: define everything as either a simple function, or as a class with That way both the ChaudhuriKundu and Taubin fits are identical. The final design should support user configuration like the EventSource and CameraCalibrator classes, but if the algorithms are really simple, they don't need to be subclasses, we can just have a "MuonReconstructor" or whatever that calls the right function depending on the user's choice (e.g. an attribute called |
Hi - does anyone know why "fitting.py" exists ? There is a version of the Chaudhuri-Kundu fit in there as a function, but it is never used. We should move the Taubin fit test from test_muon_fitting into test_muon_ring_finder. |
I implemented the kundu chauduri function in fitting.py before the other classes were there. I don't know why code review did not spot the duplication when the other things were merged. |
Just checked the history and it seems both versions were created in October 2016. For this pull request - what needs to change to the Taubin Fit ? |
Like we said, just implement it as a simple function for now! |
Can we just remove the non-used one? That sounds like a confusion that will cause problems soon! |
(and sorry @momorning that this is becoming a discussion on re-factoring the muon module, but I think this PR can be a catalyst for that! - we can divide the work though) |
Maybe we could quickly move the muon refactoring discussion into an issue... |
Weirdly, I'm not sure that any of the functions in fitting.py are used. Many seem to be duplicated in e.g. muon_integrator.py (which is called by the muon chain) but structured differently. Doesn't mean they are wrong, just we should work out what we want to keep. |
I think the question is just if it needs configuration or state between calls, if yes, it should be a class, if not, just a function (which we can wrap in a class later if we need to). For example, if those fits don't need any special state stored, you could define both as a function, but then just modify your MuonRingFinder class to call the right function depending on a user-configuration variable called "fit_method" or something (which is just a traits.CaselessStrEnum matching "taubin" or "chaudhury-kundu"). |
You should think about how a user would use it at the high level. I'd guess something like: muonfit = MuonFitter(fit_method="taubin")
result = muonfit(x,y,weights,times) and you want the user to be able to specify this in a config file, like:
which could be achieved with something like: def taubin(x, y, w, t):
...
def chaudhury_kundu(x, y, w, t)
...
class MuonFitter(Component):
fit_method = traits.CaselessStrEnum(
['taubin', 'chaudhury-kundu'],
default_value='taubin'
).tag(config=True)
def __init__(self, config=None, parent=None, **kwargs):
super().__init__(config, parent, **kwargs)
fit_map = {'taubin': taubin, 'chaudhury-kundu': chaudhury_kundu}
self.__call__ = fit_map[self.fit_method] (well you'd actually have to specify call better than that, since it needs the self argument, but you get the idea) And presumably you'd make MuonFitter do all of the analysis, and the parameterization, etc, rather than just call the fit function, but the idea is the same |
Code restructured, specify fit_method and tel_type when calling RingFitter |
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 are getting there! Let's restructure this more to separate the different implementations from the component and simplify things for testing and interpretation of the single methods.
One big problem is the telescope specfic starting values, that needs to be dealt with differently.
E.g. by using the newly introduced TelescopeParameter
traitlet option. Or by just calculating decent values from focal length or what ever you need from the Instrument description.
It may be good to split thjis into 2 PRs:
That will be more simple than doing it all at once, perhaps (but it's up to @momorning and @AMWMitchell ) |
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.
This is a large improvement!
I think we should not merge until some other core dev looked at this, maybe also @AMWMitchell wants to give a statement? |
Hm tests are failing for the conda build .. .but I don't get why |
Ah wait, it is also failing for the master .. so this is unrelated. |
@kosack can we merge this one? The hough stuff is critical, I see ... but this one here should be fine, no? |
Hello, I am working with Alison Mitchell at UZH this semester.
Adding a new muon ring fit algorithm, called Taubin fit.
The fit was referred to: https://www.zeuthen.desy.de/students/2018/Summerstudents2018/Reports/Pillera.pdf (eqn 9).
I will be working on adding a test file to show how it works.