BUG - MAG L1D Gaps

[maxinelasp]

Description of the issue

Alastair is reporting gaps in L1D output data. This seems to be split into two kinds: <5 minutes and >5 minutes, up to multiple hours.

Steps to reproduce the issue

Gaps l1d Normal (and presumably other L1D, just checked one product). We know we have vectors here - Time boundary issues? Needs investigation and fixing
  1. 2026-Jan-01 23:59:57 -- 2026-Jan-02 00:00:00, duration 00:00:02
  2. 2026-Jan-02 23:59:56 -- 2026-Jan-03 00:00:00, duration 00:00:03
  3. 2026-Feb-02 15:03:14 -- 2026-Feb-03 00:00:00, duration 08:56:45
L1D Normal NaNs

There are 73 NaN intervals - yellow ones are a surprisingly long 14h?? And the rest are just repointing?
  1. 2026-Jan-01 10:00:07 -- 2026-Jan-01 10:02:14, duration 00:02:07
  2. 2026-Jan-02 10:00:09 -- 2026-Jan-02 10:02:01, duration 00:01:52
  3. 2026-Jan-03 10:00:01 -- 2026-Jan-03 10:02:09, duration 00:02:08
  4. 2026-Jan-04 10:00:03 -- 2026-Jan-04 10:02:10, duration 00:02:07
  5. 2026-Jan-05 02:00:33 -- 2026-Jan-05 02:06:28, duration 00:05:55
  6. 2026-Jan-05 02:08:07 -- 2026-Jan-05 02:13:54, duration 00:05:47
  7. 2026-Jan-05 02:14:37 -- 2026-Jan-05 02:15:44, duration 00:01:07
 8. 2026-Jan-09 13:40:36 -- 2026-Jan-09 13:41:16, duration 00:00:39
  9. 2026-Jan-09 13:59:33 -- 2026-Jan-09 14:00:44, duration 00:01:10
10. 2026-Jan-09 15:22:59 -- 2026-Jan-09 15:23:07, duration 00:00:07
11. 2026-Jan-09 15:42:05 -- 2026-Jan-09 15:42:45, duration 00:00:39
12. 2026-Jan-09 17:05:29 -- 2026-Jan-09 17:06:25, duration 00:00:55
13. 2026-Jan-09 17:24:29 -- 2026-Jan-09 17:25:24, duration 00:00:54
14. 2026-Jan-09 18:48:05 -- 2026-Jan-09 18:49:48, duration 00:01:42
15. 2026-Jan-09 19:07:05 -- 2026-Jan-09 19:08:01, duration 00:00:55
16. 2026-Jan-09 20:30:33 -- 2026-Jan-09 20:33:03, duration 00:02:29
17. 2026-Jan-09 20:49:33 -- 2026-Jan-09 20:50:44, duration 00:01:10
18. 2026-Jan-09 22:13:00 -- 2026-Jan-09 22:16:17, duration 00:03:16
19. 2026-Jan-09 22:32:00 -- 2026-Jan-09 22:33:11, duration 00:01:10
20. 2026-Jan-09 23:55:33 -- 2026-Jan-09 23:59:22, duration 00:03:48
21. 2026-Jan-10 00:14:34 -- 2026-Jan-10 00:15:45, duration 00:01:10
22. 2026-Jan-10 01:38:00 -- 2026-Jan-10 01:42:20, duration 00:04:19
23. 2026-Jan-10 01:57:00 -- 2026-Jan-10 01:58:12, duration 00:01:11
24. 2026-Jan-10 03:20:29 -- 2026-Jan-10 03:25:21, duration 00:04:51
25. 2026-Jan-10 03:39:30 -- 2026-Jan-10 03:40:57, duration 00:01:26
26. 2026-Jan-10 05:03:02 -- 2026-Jan-10 05:08:25, duration 00:05:22
27. 2026-Jan-10 05:22:03 -- 2026-Jan-10 05:23:30, duration 00:01:26
28. 2026-Jan-10 05:57:11 -- 2026-Jan-10 05:57:34, duration 00:00:22
29. 2026-Jan-10 06:16:15 -- 2026-Jan-10 06:16:53, duration 00:00:37
30. 2026-Jan-13 10:00:05 -- 2026-Jan-13 10:01:28, duration 00:01:22
31. 2026-Jan-14 10:00:07 -- 2026-Jan-14 10:03:58, duration 00:03:51
32. 2026-Jan-15 10:00:05 -- 2026-Jan-15 10:03:11, duration 00:03:06
33. 2026-Jan-16 10:00:01 -- 2026-Jan-16 10:03:23, duration 00:03:22
34. 2026-Jan-17 10:00:06 -- 2026-Jan-17 10:03:13, duration 00:03:07
35. 2026-Jan-18 10:00:03 -- 2026-Jan-18 10:03:10, duration 00:03:07
36. 2026-Jan-19 10:00:01 -- 2026-Jan-19 10:03:23, duration 00:03:22
37. 2026-Jan-20 10:00:06 -- 2026-Jan-20 10:03:43, duration 00:03:37
38. 2026-Jan-21 10:00:03 -- 2026-Jan-21 10:02:56, duration 00:02:52
39. 2026-Jan-22 10:00:02 -- 2026-Jan-22 10:03:39, duration 00:03:36
40. 2026-Jan-23 10:00:00 -- 2026-Jan-23 10:03:08, duration 00:03:07
41. 2026-Jan-24 10:00:07 -- 2026-Jan-24 23:59:59, duration 13:59:52
42. 2026-Jan-25 10:00:03 -- 2026-Jan-25 23:59:59, duration 13:59:56
43. 2026-Jan-26 10:00:02 -- 2026-Jan-26 10:03:23, duration 00:03:20
44. 2026-Jan-27 10:00:07 -- 2026-Jan-27 10:03:28, duration 00:03:21
45. 2026-Jan-28 10:00:05 -- 2026-Jan-28 10:03:11, duration 00:03:06
46. 2026-Jan-29 10:00:04 -- 2026-Jan-29 10:03:25, duration 00:03:21
47. 2026-Jan-30 10:00:04 -- 2026-Jan-30 10:03:25, duration 00:03:21
48. 2026-Jan-31 10:00:07 -- 2026-Jan-31 23:59:59, duration 13:59:52
49. 2026-Feb-01 10:00:01 -- 2026-Feb-01 10:03:07, duration 00:03:06
50. 2026-Feb-02 10:00:05 -- 2026-Feb-02 15:03:14, duration 05:03:09
51. 2026-Feb-03 10:00:00 -- 2026-Feb-03 10:03:22, duration 00:03:21
52. 2026-Feb-04 10:00:05 -- 2026-Feb-04 10:03:26, duration 00:03:20
53. 2026-Feb-05 10:00:00 -- 2026-Feb-05 10:03:22, duration 00:03:21
54. 2026-Feb-06 10:00:06 -- 2026-Feb-06 10:03:13, duration 00:03:06
55. 2026-Feb-07 10:00:05 -- 2026-Feb-07 10:03:41, duration 00:03:35
56. 2026-Feb-08 10:00:03 -- 2026-Feb-08 23:59:59, duration 13:59:56
57. 2026-Feb-09 10:00:06 -- 2026-Feb-09 10:04:26, duration 00:04:20
58. 2026-Feb-10 10:00:06 -- 2026-Feb-10 10:03:11, duration 00:03:05
59. 2026-Feb-11 10:00:03 -- 2026-Feb-11 10:03:23, duration 00:03:20
60. 2026-Feb-12 10:00:02 -- 2026-Feb-12 10:03:22, duration 00:03:20
61. 2026-Feb-13 10:00:07 -- 2026-Feb-13 10:03:27, duration 00:03:20
62. 2026-Feb-14 10:00:07 -- 2026-Feb-14 10:03:12, duration 00:03:05
63. 2026-Feb-15 10:00:07 -- 2026-Feb-15 10:03:27, duration 00:03:20
64. 2026-Feb-17 09:59:59 -- 2026-Feb-17 10:03:20, duration 00:03:20
65. 2026-Feb-18 10:00:01 -- 2026-Feb-18 23:59:59, duration 13:59:58
66. 2026-Feb-19 10:00:03 -- 2026-Feb-19 10:03:24, duration 00:03:20
67. 2026-Feb-20 10:00:06 -- 2026-Feb-20 10:03:27, duration 00:03:20
68. 2026-Feb-21 10:00:01 -- 2026-Feb-21 10:03:22, duration 00:03:20
69. 2026-Feb-22 10:00:04 -- 2026-Feb-22 23:59:59, duration 13:59:55
70. 2026-Feb-23 10:00:02 -- 2026-Feb-23 10:03:07, duration 00:03:05
71. 2026-Feb-24 10:00:05 -- 2026-Feb-24 10:03:10, duration 00:03:05
72. 2026-Feb-25 10:00:01 -- 2026-Feb-25 10:03:21, duration 00:03:20
73. 2026-Feb-26 10:00:06 -- 2026-Feb-26 10:03:26, duration 00:03:20

Expected vs Actual behavior

Why are there so many NaNs?

Code Snippet (If applicable)

Additional notes, affected areas, and suggested fixes

The short gaps are likely related to repointing.

Per this slack thread:

Slack Thread: IMAP_DPS Frame Gaps

Bryan Harter [12:48 PM]
I've got a question — when using the IMAP_DPS frame, what happens when your code calls something like spice.geometry.imap_state() for times where we have no IMAP_DPS frame data? It looks like there are at least 2–3 minutes every day just after 10am UTC where no data exists, and I don't see any interpolation code in imap_processing.

Bryan Harter [12:51 PM]
I'm working on optimizations to the metakernel API. One route was making sure all "gaps" listed in a file are actually gaps that would cause errors in processing. If you already have a workaround for that gap, we could remove them and significantly reduce the metakernel search time.

Tenzin Choedon [1:00 PM]
We were just talking about gaps this morning. Would it help to separate that part out or query from the DB? What did EMM do?

Bryan Harter [1:02 PM]
EMM just had far fewer gaps. After all the data came down we almost always had everything filled in.

Tenzin Choedon [1:05 PM]
Right now, are we looking for gaps by opening files or reading from the DB? It looks like IMAP does fill those gaps in new files.

Bryan Harter [1:08 PM]
Files are opened in the spice_indexer when they come in, and the gaps are inserted into the database.

Bryan Harter [1:15 PM]
The gaps just after 10am in the imap_dps CK files don't appear to ever get filled in — all files have them missing, at least for the last 2 months.

Tenzin Choedon [3:58 PM]
So all DPS kernels have a gap after 10am? Why is the gap causing the metakernel issue?

Bryan Harter [4:03 PM]
Yeah, all DPS kernels have gaps. It's slowing things down because most DPS files span ~30 days, so each file has ~30 gaps. For each gap, the metakernel tries to find a new file to fill it — which also has 30 gaps — so it needs to fill those too, and so on. A lot of recursion.

Timothy Plummer [4:04 PM]
There is no way to fill those gaps.

Tenzin Choedon [4:04 PM]
Is the require_coverage flag related to filling gaps? If we set it to False, will it still look for gaps?

Timothy Plummer [4:06 PM]
The DPS kernel is the average spin axis during a "fixed" pointing. We don't compute it during repointing maneuvers when the spin axis is moving. Each pointing is quasi-inertial — close to fixed spin-axis pointing.

Bryan Harter [4:06 PM]
It always looks for gaps regardless of require_coverage. If require_coverage=True, the metakernel API returns an error if gaps cannot be filled.

Tenzin Choedon [4:07 PM]
So Tim — we will never fill those gaps and it's expected?

Bryan Harter [4:07 PM]
So is data collected during a repointing maneuver that needs the DPS frame discarded?

Timothy Plummer [4:07 PM]
Correct. During those gaps, the spin axis is moving and there is no fixed pointing axis.

Timothy Plummer [4:08 PM]
Maybe not discarded, but we shouldn't be computing geometry using that frame during those gaps. If we are, the correct thing is to raise a SpiceyPy error. I don't know if there's a way to turn off recursion for the DPS kernels (pointing_attitude is the other name) while still getting the full requested coverage with expected gaps.

Bryan Harter [4:11 PM]
Got it — so those gaps are real and you definitely shouldn't be computing DPS frame geometry during those periods. The modifications I'm making might make the large number of identical gaps a non-issue anyway.

Timothy Plummer [4:12 PM]
Just a thought — maybe for those kernels the algorithm could use the global min/max times and totally ignore gaps within the file?

Bryan Harter [4:12 PM]
Yeah, that can be the last resort if the current changes don't speed things up enough.

---

Summary: During spacecraft repointing maneuvers (~2–3 minutes daily just after 10am UTC), the spin axis is moving and no DPS kernel data is computed, leaving permanent unfillable gaps. Geometry should never be computed using the DPS frame during these intervals; doing so should raise a SpiceyPy error.