-
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
Cubeviz cube fitting: Fix fitted cube all zeroes, allow MP bypass #1333
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1333 +/- ##
==========================================
- Coverage 84.64% 84.58% -0.06%
==========================================
Files 91 91
Lines 7878 7839 -39
==========================================
- Hits 6668 6631 -37
+ Misses 1210 1208 -2
Continue to review full report at Codecov.
|
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
DEV: Allow multiprocessing bypass when n_cpu is 1
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.
@rosteen , please double check the X and Y order. That part always confuses me because of specutils
reordering things and such.
@@ -119,14 +113,16 @@ def test_cube_fitting_backend(): | |||
|
|||
SIGMA = 0.1 # noise in data | |||
TOL = 0.4 # test tolerance | |||
IMAGE_SIZE_X = 15 |
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 purposely made this asymmetric so it is easier to tell if we get the spatial dimension wrong.
assert fitted_spectrum.flux.unit == u.Jy | ||
assert not np.all(fitted_spectrum.flux.value == 0) |
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 there is a better way to test the contents of fitted_spectrum
but maybe we can defer that for the "science verification" campaign.
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 it would be too hard to generate a known shape with some noise on top and check that the result is within tolerance of the expected fit, but I agree that I think we can defer that for now.
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.
Should we add a comment above this to the effect of "if this ever fails, set n_cpu=1 to access the tracebacks from fitting"?
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's a comment to that effect on line 149 # n_cpu = 1 # NOTE: UNCOMMENT TO DEBUG LOCALLY, AS NEEDED
, think there needs to be another one here?
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.
Instead of copy pasting that sentence everywhere in the test, should I just write it up in dev docs? Any suggestion on where?
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 currently the one place that will catch these failures, right? But I guess we may have more in the future - I'm just trying to save us time in the future if/when this returns zeros and trips this test again. I'm not sure I would remember and see the other comment to even know that a debug mode is an option. But I suppose we always have the blame history back to this PR 🤞
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.
Would it help if I expose this in API doc over at RTD as a follow-up PR?
n_cpu : `None` or int | |
**This is only used for spectral cube fitting.** | |
Number of cores to use for multiprocessing. | |
Using all the cores at once is not recommended. | |
If `None`, it will use max cores minus one. | |
Set this to 1 for debugging. |
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 will ping you to review #1346 when it is ready. Thanks!
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.
Works for me, thanks.
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.
Science verification and regression tests still need to be added (as future efforts) to ensure this bug doesn't resurface for various scenarios, but this at least enables us to write those tests and debug when they fail.
This closes #1245 |
Description
This pull request is to address reported bug where a failed cube fit would silently return a cube with all zeroes because multiprocessing swallowed all the exceptions. This PR intents to:
n_cpu
is set to 1 (this feature is for developers only)Fix #1245
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.CHANGES.rst
?