Skip to content
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

JP-3242: Proper Handling of Timing for Final Slope Computation for only 0th Good Group Ramps #173

Merged
merged 13 commits into from
Jun 22, 2023

Conversation

kmacdonald-stsci
Copy link
Collaborator

@kmacdonald-stsci kmacdonald-stsci commented Jun 14, 2023

Resolves JP-3242

This PR addresses special handling of timing for ramps that have only good 0th group in a ramp. The addition of this special case only properly computed the variances. The timing division for the final slope computation still used the group time, which is not correct for certain special cases. All timing divisions have been pushed back to the segment calculations, so there is no longer one final divide. There is also the further subset special case for only 0th good group with the use of ZEROFRAME.

Checklist

  • added entry in CHANGES.rst (either in Bug Fixes or Changes to API)
  • updated relevant tests
  • updated relevant documentation
  • updated relevant milestone(s)
  • added relevant label(s)

@codecov
Copy link

codecov bot commented Jun 14, 2023

Codecov Report

Patch coverage: 98.61% and project coverage change: +0.13 🎉

Comparison is base (cc1edfd) 75.28% compared to head (2f2b9cf) 75.42%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #173      +/-   ##
==========================================
+ Coverage   75.28%   75.42%   +0.13%     
==========================================
  Files          29       29              
  Lines        5706     5714       +8     
==========================================
+ Hits         4296     4310      +14     
+ Misses       1410     1404       -6     
Impacted Files Coverage Δ
tests/test_ramp_fitting.py 89.34% <97.29%> (+0.66%) ⬆️
src/stcal/ramp_fitting/ols_fit.py 80.13% <100.00%> (+0.23%) ⬆️
src/stcal/ramp_fitting/ramp_fit_class.py 55.91% <100.00%> (+0.47%) ⬆️
src/stcal/ramp_fitting/utils.py 90.61% <100.00%> (+0.04%) ⬆️

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

Copy link
Collaborator

@hbushouse hbushouse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs a change log entry.

src/stcal/ramp_fitting/ols_fit.py Show resolved Hide resolved
Copy link
Collaborator

@hbushouse hbushouse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this all looks reasonable to me. The real test will be in ... the tests, to see if we get the right answers in real images. If any unit tests use combinations of params (e.g. nframes, frame-time, group-time, etc.) that are nonsensical, I would update them to make them sensical.

@hbushouse
Copy link
Collaborator

Still needs a change log entry and converted out of Draft form.

@kmacdonald-stsci kmacdonald-stsci marked this pull request as ready for review June 21, 2023 12:51
@kmacdonald-stsci kmacdonald-stsci requested a review from a team as a code owner June 21, 2023 12:51
@kmacdonald-stsci
Copy link
Collaborator Author

Still needs a change log entry and converted out of Draft form.

The tests have been updated. The change log has been updated. And the PR is out of draft form.

Copy link
Collaborator

@hbushouse hbushouse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

@hbushouse
Copy link
Collaborator

Need another stcal maintainer to approve. Also probably needs a regtest against Roman. @PaulHuwe @mairanteodoro bueller? Who can do this for us?

@kmacdonald-stsci
Copy link
Collaborator Author

Need another stcal maintainer to approve. Also probably needs a regtest against Roman. @PaulHuwe @mairanteodoro bueller? Who can do this for us?

Paul is no longer to be tagged on STCAL PR's. I tagged Jon Eisenhamer and Dave Davis.

@ddavis-stsci
Copy link
Collaborator

It looks like we'll have to update some of our truth files in artifactory before these will pass,

>           return func(*args, **kwds)
E           AssertionError: 
E           Not equal to tolerance rtol=1e-06, atol=0
E           
E           Mismatched elements: 1 / 1 (100%)
E           Max absolute difference: 10.00001
E           Max relative difference: 1.000001
E            x: array(-1.000001e-05, dtype=float32)
E            y: array(10.)

I'll look at this in more detail unless you have some input. You can see the test results at
https://plwishmaster.stsci.edu:8081/job/RT/job/Roman-devdeps/322/

Copy link
Collaborator

@ddavis-stsci ddavis-stsci left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, The changes I see are at the 10E-5 level and are just above our 10E-6 level for tolerance so even with the tests formally failing I don't see an issue with the code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants