-
Notifications
You must be signed in to change notification settings - Fork 76
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
Model fitting: re-estimate model parameters #1952
Conversation
8ebc617
to
0eeb211
Compare
Codecov ReportBase: 91.79% // Head: 91.79% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #1952 +/- ##
=======================================
Coverage 91.79% 91.79%
=======================================
Files 140 140
Lines 14941 14978 +37
=======================================
+ Hits 13715 13749 +34
- Misses 1226 1229 +3
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
49059a6
to
a63c2c7
Compare
jdaviz/configs/default/plugins/model_fitting/tests/test_plugin.py
Outdated
Show resolved
Hide resolved
9c8228a
to
d952c40
Compare
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.
Code looks like code and the video is very convincing. Thanks!
new_model['parameters'] = [fixed_params.get(p['name'], p) for p in new_model['parameters']] | ||
|
||
# reset traitlet so vue picks up on changes by adding (and then removing) an empty entry, | ||
# this avoids resetting the open state of the accordion in the UI. |
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.
🤯
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'd love to know of a better way to do this... or requesting/implementing traitlet.force_update()
upstream...
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.
Maybe @mariobuikhuizen can advise but this shouldn't block merge. Just amazed you figured out this is how you make it do what you want. To me, it is like eating pizza with chopsticks. 😸
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.
Traitlets can't discover in-place changes to a list or dict, so you always need to use methods that produce a new instance. You could consider using:
self.component_models = self.component_models[:model_index] + [new_model] + self.component_models[model_index + 1:]
Or you could use self.send_state("component_models")
, which is similar to the envisioned .force_update()
function.
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 didn't know about send_state
, that seems to do the trick and reads more clearly to me than always rebuilding from scratch, thanks!
Although, do you want to explain this new feature in the user doc? |
The model fitting docs already says "Model Parameters are automatically initialized with a guess. These starting values can be edited by the user. They may also be fixed by selecting the checkbox, so that they are not fit or changed by the model fitting." We could add a little here ("... with a guess from the selected data/subsets. These starting values can be edited by the user or re-estimated by clicking a button..."), but I also am always weary of going in tangents for advanced functionality that is self-discoverable in the UI. |
If I click "re-estimate" under one of the model components it works, but if I click the button above the component list I get an error (this is in Cubeviz):
|
46c2c49
to
ee8b240
Compare
@rosteen - should be fixed now, thanks! |
Is it known that this doesn't respect spatial subsets in Cubeviz? You can select a small spatial subset such that the collapsed spectrum's flux is much smaller than that for the full cube, and see that, for example, a constant component's estimate is based on the full cube collapse even if you select that spatial subset. |
This seems to have been broken by #1947... @bmorris3 and I are investigating now and I'll see if we can get the fix in this PR or if it makes more sense to address separately. Thanks for testing that case! 😬 EDIT: fixed in #1954. Hopefully we can get that tested/reviewed/merged and then I'll rebase this PR. |
Well, sorry I didn't catch it there, but good we caught it now I guess! |
c9b6525
to
efdae47
Compare
Re-estimation now works with spatial subsets in cubeviz (note that the estimation is done on the 1d spectrum even if doing a cube fit, which I think is the expected behavior): Screen.Recording.2023-01-03.at.10.12.31.AM.mov |
|
||
self.component_models[model_index] = new_model | ||
# length hasn't changed, so we need to force the traitlet to update | ||
self.send_state("component_models") |
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.
Ooh, that's good to know about. There might be a few other places we can simplify things with this.
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.
Looks good now, all subset combinations are working like I'd expect. Thanks!
Description
This pull request implements a plugin API and UI to re-estimate the initial values of free model parameters for individual or all model components.
Screen.Recording.2022-12-29.at.8.53.51.AM.mov
TODO:
Change log entry
CHANGES.rst
? If you want to avoid merge conflicts,list the proposed change log here for review and add to
CHANGES.rst
before merge. If no, maintainershould add a
no-changelog-entry-needed
label.Checklist for package maintainer(s)
This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive.
trivial
label.