-
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
Update Outlier Detection to use stcal #1357
Update Outlier Detection to use stcal #1357
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1357 +/- ##
==========================================
- Coverage 78.66% 78.38% -0.28%
==========================================
Files 117 118 +1
Lines 7724 7680 -44
==========================================
- Hits 6076 6020 -56
- Misses 1648 1660 +12
*This pull request uses carry forward flags. Click here to find out more. ☔ View full report in Codecov by Sentry. |
CHANGES.rst
Outdated
- Remove unused arguments to outlier detection. [#1357] | ||
|
||
- Update input handling to raise an exception on an invalid input instead | ||
of issuing a warning and skipping the step. [#1357] | ||
|
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.
- Remove unused arguments to outlier detection. [#1357] | |
- Update input handling to raise an exception on an invalid input instead | |
of issuing a warning and skipping the step. [#1357] |
now that #1375 is merged (switching change log handling to towncrier
) this change log entry should be a file in changes/
instead:
echo "Remove unused arguments to outlier detection. \n\n Update input handling to raise an exception on an invalid input instead of issuing a warning and skipping the step." > changes/1357.outlier_detection.rst
(this is just because #1375 was merged while active PRs existed; new PRs will have these instructions in their checklist)
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.
Changelog updated to new format. Let me know if this looks good to you.
ef64ed3
to
b9d65f3
Compare
b9d65f3
to
37520f1
Compare
71a76c2
to
f0edcaa
Compare
pyproject.toml
Outdated
"stcal @ git+https://github.com/spacetelescope/stcal.git@main", | ||
# "stcal>=1.8.0,<1.9.0", | ||
# "stcal @ git+https://github.com/spacetelescope/stcal.git@main", | ||
"stcal @ git+https://github.com/emolter/stcal.git@JP-3768", |
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.
Temporarily set to source branch for spacetelescope/stcal#292 for testing that (and this) PR.
For the small (3 input) association described in more detail https://innerspace.stsci.edu/display/SCSB/Romancal+ModelLibrary+Performance the memory profile of a run of the mosaic pipeline with this PR is:
|
Pinging @emolter since I can't request you as a reviewer. If you have a chance to look over this PR that would be greatly appreciated! |
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 great aside from some minor questions and comments Brett!
Are there any regression tests that save intermediate files from the OutlierDetectionStep? I don't see any regtest updates here, and I know in JWST we kept running into problems with intermediate filenames partially because those lacked test coverage
log.info(f"{np.count_nonzero(cr_mask)} pixels marked as outliers") | ||
|
||
|
||
def detect_outliers( |
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.
probably a nitpick, but is the detect_outliers
function really a utility that belongs in utils
?
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 struggled to come up with a way to organize/name this so suggestions are welcome. Putting it in "imaging" (like in jwst) doesn't make sense here (as there's no non-imaging modes). Putting it in another "outlier_detection" submodule is overly redundant ("romancal.outlier_detection.outlier_detection.detect_outliers"). So I gave up and went with the standard "utils".
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.
It's not that many lines. Is there a reason why it needs to be its own function, given that there is only one outlier detection mode for romancal? That is, can you just embed the code into OutlierDetectionStep
?
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 considered that. I believe the convention for romancal (as described by @mairanteodoro ) is to have the steps handle the stpipe-specific stuff and s much of the "meat" of the processing occur in a separate function/class/utility. If it's ok with you let's see what he thinks.
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.
sounds good it's definitely nbd either way as far as I'm concerned
|
||
Used for outlier detection | ||
indices : list |
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.
Consider adding a one-line description of what the indices correspond to (I realize I didn't do any of these docstring updates for the jwst code either...)
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.
How does b8ba8af look?
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 except (nitpick) the second instance of "and will not" could be changed to "nor"
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'm going to leave this as-is in part because I can't think of a good way to fit in a "nor". I know it's considered a universal gate so it should be able to do anything (bad joke)!
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.
sounds good
e6ca79e
to
e3f7956
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.
All of my comments have been answered. I'm still wondering though whether there is test coverage of the intermediate files somewhere in the regtests.
Thanks for taking a look and for the reminder on that point. There's a unit test that saves intermediate results: |
b8ba8af
to
cc89fa6
Compare
Co-authored-by: Ned Molter <[email protected]>
cc89fa6
to
9a2df83
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.
This looks good to me. A few questions, though:
- FWIW, either accepting weight_type as ivm with a default of IVM or passing it through correctly works fine for me. We do want to be using that but we don't need to do that through hard coding. This is especially true for the _median_without_resampling case, which we don't expect to use much in production.
- It's great to move the common code to stcal and to improve performance. It looks to me like it's the case that the new outlier_detection.utils module contains no Roman-specific code, except maybe through the ModelLibrary infrastructure. Is that a target of future stcal common code consolidation?
Thanks!
Sorting out the weight handling sounds great. I opened an issue to track that #1428 but I think it would be a little more involved. I don't expect we'll see regtest differences but I do think adding some unit tests (to verify that changing the weight type has the intended effect) is useful.
Good point! I think there is more that could be done here once resample is moved to stcal. At the moment the link between outlier detection and resample puts some limitations on what can be pulled out of jwst/romancal. |
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.
more abstraction! the changelog looks good to me
Closes #1302
Closes #1423
Fixes RCAL-926
This PR updates outlier detection to use common code in stcal. It largely mirrors the code in spacetelescope/jwst#8840
This PR also removes a few unused items from the outlier detection step spec:
And updates the input handling to raise an exception (instead of issuing a warning) for invalid input (as described in #1302).
The docs updates in this PR reference the step spec rather than specifying defaults in the docs (which are currently out of sync with the code).
Link to page which has most of the docs updates: https://roman-pipeline--1357.org.readthedocs.build/en/1357/roman/outlier_detection/arguments.html
Regression tests all pass https://github.com/spacetelescope/RegressionTests/actions/runs/11114749475
Checklist
CHANGES.rst
under the corresponding subsection