-
Notifications
You must be signed in to change notification settings - Fork 28
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
Rcal 406 science array quantities #613
Rcal 406 science array quantities #613
Conversation
…o ArrayQuanitites
Codecov ReportBase: 81.70% // Head: 75.99% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #613 +/- ##
==========================================
- Coverage 81.70% 75.99% -5.72%
==========================================
Files 39 39
Lines 1170 1283 +113
==========================================
+ Hits 956 975 +19
- Misses 214 308 +94
*This pull request uses carry forward flags. Click here to find out more.
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. |
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.
LGTM
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 good to me, with some comments.
My biggest concern is that the value of having units is that they prevent you from doing things that don't make sense, e.g., 1u.DN + 1u.electron triggers an exception. For the most part this PR avoids this feature by working primarily with quantity.value, and just treating things as ordinary numpy arrays. I see that as a last resort and think we should be trying to avoid ".value" and Quantity(...) when possible.
Of course, it's not always possible---stcal will want just the plan numpy arrays, and we'll need to redecorate them with units when we get them back from stcal. But I noted a number of cases in the code where I think we could be treating the units more naturally.
@@ -109,21 +111,21 @@ def apply_flat_field(science, flat): | |||
flat_data[np.where(flat_bad)] = 1.0 | |||
# Now let's apply the correction to science data and error arrays. Rely | |||
# on array broadcasting to handle the cubes | |||
science.data /= flat_data | |||
science.data = u.Quantity((science.data.value / flat_data), ru.electron / u.s, dtype=science.data.dtype) |
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.
What units does science.data start with We already forced it to have e/s in the schema? flat_data is probably dimensionless, so I would have guessed that science.data /= flat_data would just work? Am I missing something?
ru.electron ** 2 / u.s ** 2, dtype=science.data.value.dtype) | ||
|
||
err_sqrt = np.sqrt(science.var_poisson.value + science.var_rnoise.value + science.var_flat) | ||
science.err = u.Quantity(err_sqrt, ru.electron / u.s, dtype=err_sqrt.dtype) |
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.
Likewise, I think my expectation throughout here is that the old code would be fine
e.g. science.var_poisson /= flat_data_squared should preserve the units?
Same for science.var_rnoise, science.var_flat, and only the exception should require explicit quantities?
@@ -142,7 +144,7 @@ def test_one_CR(generate_wfi_reffiles, max_cores, setup_inputs): | |||
deltatime=grouptime) | |||
|
|||
for i in range(ngroups): | |||
model1.data[i, :, :] = deltaDN * i | |||
model1.data.value[i, :, :] = deltaDN * i |
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 would have said it's more idiomatic to change deltaDN -> deltaDN * u.DN that it is to have all the data.values.
model1.data[CR_group:, CR_y_locs[i], CR_x_locs[i]] = \ | ||
model1.data[CR_group:, CR_y_locs[i], CR_x_locs[i]] + 500. | ||
model1.data.value[CR_group:, CR_y_locs[i], CR_x_locs[i]] = \ | ||
model1.data.value[CR_group:, CR_y_locs[i], CR_x_locs[i]] + 500. |
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.
Likewise my default here would have been 500 -> 500 * u.DN rather than working directly with the values.
Resolves RCAL-406
Closes #
This PR adds support for Quantities for data arrays.
Checklist
CHANGES.rst
under the corresponding subsection