Details
-
Type:
Improvement
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: ip_isr
-
Labels:
-
Story Points:6
-
Epic Link:
-
Sprint:DRP S19-6b
-
Team:Data Release Production
Description
Some of the current implementation assumes only a single fringe frame. Several places in FringeTask and/or IsrTask may need to be updated to support fringe correction with multiple fringe frames.
Attachments
Issue Links
Activity
I just mean that we have no data to test this on. I know there is a unit test, but it will not be exercised in CI, so has potential for bitrot. Unless there is a significant driver (i.e. it's algorithmically difficult) I would prefer not to spend time trying to implement a scenario we don't actually use.
I understand that desire, but I also worry about what's going to happen when we see first light and need additional capability quickly. The unit test (which is exercised every time the package is built) will help prevent bitrot. I think the multiple fringe frames are a natural part of the algorithm which will also help prevent bitrot.
Paul Price
added a comment - I understand that desire, but I also worry about what's going to happen when we see first light and need additional capability quickly. The unit test (which is exercised every time the package is built) will help prevent bitrot. I think the multiple fringe frames are a natural part of the algorithm which will also help prevent bitrot. Sophie Reed and I worked on this problem for pair programming, using the to-be-reviewed and merged ISR mock code for testing. It does appear that multiple fringe frames do work with the fringe code as it current exists, and although this will need to be formalized after that ticket clears, no major algorithmic code needs to be added.
Done as pair-programming with Sophie Reed.
I don't see how that would "make things more tractable". Why not add a front end API that is explicitly single frame, and retain the capability in the back-end?