hsergi
commented
1 month ago Summary slides with the decision of using the data-based method and next steps:
•Write the sorting algorithm as a stand-alone function in DRP. Keep the CAR team involved in the development of the sorting algorithm. Make sure the algorithm is consistent with the observer’s choices (See https://github.com/roman-corgi/corgidrp/issues/231) •Write unit tests that cover the file diversity that mat happen when collecting calibration data for EM-gain, k-gain and non-linearity (https://github.com/roman-corgi/corgidrp/issues/232) •Include an alternative way to directly parse a sorted list of frames for each calibration type (https://github.com/roman-corgi/corgidrp/issues/233) •Internal to DRP: how to gather L1 input data from more than one visit file into a single Dataset? https://github.com/roman-corgi/corgidrp/issues/228
Describe the bug The current version of DRP assumed the use of different values of the Keyword OBSTYPE to sort L1 calibration data for EM-gain, k-gain and non-linearity, although that's not possible because the data will be collected using a single value of OBSTYPE
Expected behavior Given a set of L1 calibration data for EM-gain, k-gain and non-linearity, the DRP has to be able to define the subset of frames that goes into each calibration type and into the generation of a mean frame (used by the three cal types)
Additional context There's a meeting planned on 10/24 to discuss the different approaches. Once there's a decision, one may work on the actual implementaion.
Indirectly related is the current use of OBSTYPE in the DRP to decide which cal function to call (e.g. in e2e tests). @juliamilton is dealing with how to handle the same functionality with perhaps a different Keyword name that would be internal to DRP only. That is, not expexted from SSC L1 headers.