You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe the weighting scheme in cridcalc (for slope fitting calculations) might be erroneous. The code seems to imply that there is an implicit assumption of EQUAL sampling intervals. This is not the case in general for WFC3 up the ramp samples. I believe the error comes from using Mike Regan optimal weighting scheme which was developed for JWST, where the equal intervals assumption is correct, but was ported to WFC3 without paying attention to this detail. But maybe I am wrong.
Tagging a few WFC3 folks. I brought this up a while back, but I see it has not been fixed. I was reminded about it by reading a Tech memo for Roman! @Vb2341@protonchain
instead of k (the read sample index), we need x[k], i.e. the TIME of the k-th read
instead of (ndata-1)/2 (the index of the “central” or middle read, or, for even number of total reads, the mid-point between the two central reads), we want ( x[ndata-1] + x[0] )/2, i.e. the mid-point of the interval IN TIME (not in read-index), i.e. the time of the last read minus the time of the first read in that interval divided by two
So I think the new line should be (you can and should make it in one line, because those variables I am wriritng are not defined, but for clarity in the email I will spell it out):
I think the external fabs could be removed because a positive number to any power stays a positive number, but there might be a numeric reason for that fabs to be there.
Just note that these “intervals” are not necessarily 1:1 w.r.t. the seqeunce of reads, as, at this stage, the pipeline may have already split the full interval in multiple sub-intervals due to cosmic ray identification.
The text was updated successfully, but these errors were encountered:
@mgennaro Does this ticket need further comment from other WFC3 team members?
Aside: I do not see any other ticket discussing this issue in Git. I will note the code associated with this bug was last touched approximately ten years ago.
@mdlpstsci I confirm there is no other git issue taht I know of on this topic. This was part of an old email thread between you, me, Varun and Sylvia. The email I sent is from April 15 2019, and you replied on April 18 2019. You mentioned fixing this into this branch:
Form Sylvia via email on 24 June 2022:
Hi Mario – thank you submitting that ticket. It’s on our wish list of things to do though unfortunately we haven’t had the resources to take it on yet. Thanks for thinking of us! -Sylvia
I believe the weighting scheme in cridcalc (for slope fitting calculations) might be erroneous. The code seems to imply that there is an implicit assumption of EQUAL sampling intervals. This is not the case in general for WFC3 up the ramp samples. I believe the error comes from using Mike Regan optimal weighting scheme which was developed for JWST, where the equal intervals assumption is correct, but was ported to WFC3 without paying attention to this detail. But maybe I am wrong.
Tagging a few WFC3 folks. I brought this up a while back, but I see it has not been fixed. I was reminded about it by reading a Tech memo for Roman!
@Vb2341 @protonchain
Line 1182 under https://github.com/spacetelescope/hstcal/blob/master/pkg/wfc3/calwf3/wf3ir/cridcalc.c
i.e.:
The changes are the following:
instead of k (the read sample index), we need x[k], i.e. the TIME of the k-th read
instead of (ndata-1)/2 (the index of the “central” or middle read, or, for even number of total reads, the mid-point between the two central reads), we want ( x[ndata-1] + x[0] )/2, i.e. the mid-point of the interval IN TIME (not in read-index), i.e. the time of the last read minus the time of the first read in that interval divided by two
So I think the new line should be (you can and should make it in one line, because those variables I am wriritng are not defined, but for clarity in the email I will spell it out):
And deltas can be written in one line as
I think the external fabs could be removed because a positive number to any power stays a positive number, but there might be a numeric reason for that fabs to be there.
Just note that these “intervals” are not necessarily 1:1 w.r.t. the seqeunce of reads, as, at this stage, the pipeline may have already split the full interval in multiple sub-intervals due to cosmic ray identification.
The text was updated successfully, but these errors were encountered: