CoDICE: SCI-LUT day boundary refactor

[tech3371]

Change Summary

closes #2697 and #2453

Overview

Refactor to process for days when there are multiple table_id in CoDICE L1A SCI-LUT.

File changes

Testing

I sent locally processed hi-omni file from day 20260403 to Joey and we match data plot for this scope of work.

[lacoak21]

Nice refactor. I think there still may be some todos in imap_processing/codice/utils.py for example in calculate_acq_time_per_step. Which brings up that question for me. How are we treating acq_time_per_esa_step variable here? There may be the case where we get two arrays with different values depending on the sci lut.

[lacoak21]

Do you need these two lines? I think if you pass in processed as a single element list concat will still work.

[tech3371]

good point!

[tech3371]

Nice refactor. I think there still may be some todos in imap_processing/codice/utils.py for example in calculate_acq_time_per_step. Which brings up that question for me. How are we treating acq_time_per_esa_step variable here? There may be the case where we get two arrays with different values depending on the sci lut.

Good find, @lacoak21!

Looks like I didn't remove that TODO. Looks like I updated function to read in dynamic num_steps_data from SCI-LUT's data instead of hard coding but didn't remove the TODO. Now with this PR update, we should be we ok for that as well. Since we are passing in a specified table_id's SCI-LUT data into our previous function steps, we should still map to using correct num_steps_data for calculate_acq_time_per_step calculation. That's my understanding. I can ask Joey to match our acquisition times to be sure.

[lacoak21]

Looks like I didn't remove that TODO. Looks like I updated function to read in dynamic num_steps_data from SCI-LUT's data instead of hard coding but didn't remove the TODO. Now with this PR update, we should be we ok for that as well. Since we are passing in a specified table_id's SCI-LUT data into our previous function steps, we should still map to using correct num_steps_data for calculate_acq_time_per_step calculation. That's my understanding. I can ask Joey to match our acquisition times to be sure.

Oh right! I forgot it was 2d!! Ok great I agree that this is resolved in your PR.

[lacoak21]

Looks good!

[tech3371]

@mstarkey2158 confirmed that calculate_acq_time_per_step is looking good for the file I sent. voltage_table comment from Michael may be outside of this scope of work.