CoDICE telemetry or SCI LUT boundary day handling

[lacoak21]

good. Can we capture this note in this ticket for day spanning work?

Originally posted by @tech3371 in #2679

We need to fix l1a and l2 code to handle days where either the sci lut changed mid day or the telemetry changed mid day.

[lacoak21]

Solution is to write a new sci lut that contains both table id dictionaries. The code then needs some updates to use the right table IDS for each event.

[mstarkey2158]

CoDICE Team comments: This should be fixed before data release. If unable to fix before data release, then don't release data files for those days.

[mmshaw]

I am marking this as a Release Blocker by Jon's definition, which is "we have to deal with this before the public release" - so as @mstarkey2158 commented, it should be fixed or those data files should be excluded.

[tech3371]

Solution for this:

• when new upload of SCI-LUT happens, on that day, we have two version for half and half data. For that, in SDC json file, we put both table id's information into that file, imap_codice_l1a-sci-lut___v001.json.
• From next day onward until next SCI-LUT, imap_codice_l1a-sci-lut__v001.json. In that file, it contains the new SCI data only.
• In processing, code, we need to refactor processing code to use right table-id for days when we have both table id.

Be aware of how imap-data-access queries for latest version for ancillary.
Way to capture this note and plan.

• Release notes or
• update here - https://imap-processing.readthedocs.io/en/latest/filename-convention/calibration-files.html

[tech3371]

imap_codice_l1a-sci-lut_20260403_v002.json
imap_codice_l1a-sci-lut_20260129_v002.json
Going to use these two files and day 20260403 data as use case for this work.

[tech3371]

Days when new SCI-LUTs were upload since launch and has this unique situations are:

• 20260403
• 20260129
• 20251124

(Edit: I updated that after email input from Michael. Thanks Michael!)

Are those all the days that are effected @mstarkey2158?