HIT L0 - Fix angle dimension order error#1837
HIT L0 - Fix angle dimension order error#1837vmartinez-cu merged 2 commits intoIMAP-Science-Operations-Center:devfrom
Conversation
…(zenith x azimuth) while decommutating the binary data since that is how the data is specified in the flight software, and then transposed for the data products. This ensures that the correct values end up where expected in the new shape (azimuth x zenith).
There was a problem hiding this comment.
Pull Request Overview
This PR corrects the dimension ordering for raw binary sectorates by reshaping to 8×15 and then transposing to 15×8, and centralizes dimension lengths.
- Updated the sectorates shape in constants to (8, 15) to match flight software output
- Added a transpose in decom_hit to reorder data from (8, 15) → (15, 8)
- Replaced hard-coded 15×8 array sizes in hit_l1a with
len(AZIMUTH_ANGLES)andlen(ZENITH_ANGLES)
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| imap_processing/hit/l1a/hit_l1a.py | Use dynamic dimension lengths for counts array instead of fixed 15×8 |
| imap_processing/hit/l0/decom_hit.py | Reshape sectorates to (8, 15) then transpose to (15, 8) before assigning azimuth/zenith dims |
| imap_processing/hit/l0/constants.py | Changed sectorates shape tuple from (15, 8) to (8, 15) |
Comments suppressed due to low confidence (3)
imap_processing/hit/l0/decom_hit.py:95
- [nitpick] Consider clarifying this comment to explain that data is first reshaped to (num_frames, 8, 15) and then transposed to (num_frames, 15, 8), making the axes mapping explicit.
# Transpose data to 15x8 for azimuth and zenith look directions
imap_processing/hit/l0/constants.py:103
- [nitpick] The inline comment could be expanded to indicate that the tuple represents (azimuth, zenith) dimensions—8 azimuth angles and 15 zenith angles—for greater clarity.
"sectorates": HITPacking(16, 1920, (8, 15)), # sectored rates
imap_processing/hit/l0/decom_hit.py:97
- Add a unit test to verify that reshape and transpose for 'sectorates' produce the expected (num_frames, 15, 8) shape and correct ordering of azimuth and zenith axes, preventing future regressions.
parsed_data = np.transpose(parsed_data, axes=(0, 2, 1))
| # look directions | ||
| parsed_data = np.array(parsed_data).reshape((-1, *field_meta.shape)) | ||
| # Transpose data to (num_frames, 15, 8) for flipped look directions | ||
| parsed_data = np.transpose(parsed_data, axes=(0, 2, 1)) |
There was a problem hiding this comment.
What would happen if you left L0 as (15, 8) and didn't transpose it here? Would that cause any issues?
There was a problem hiding this comment.
The values end up in a different arrangement in the data array which then fails HIT's validation tests. I guess transposing data is different from reshaping data and I didn't realize that before
There was a problem hiding this comment.
I just realized you added the transpose here as part as part of this change, so that was a dumb question
| # look directions | ||
| parsed_data = np.array(parsed_data).reshape((-1, *field_meta.shape)) | ||
| # Transpose data to (num_frames, 15, 8) for flipped look directions | ||
| parsed_data = np.transpose(parsed_data, axes=(0, 2, 1)) |
There was a problem hiding this comment.
I just realized you added the transpose here as part as part of this change, so that was a dumb question
f9687bb
into
IMAP-Science-Operations-Center:dev
This PR updates how the raw binary sectorates data is processed. It needs to be processed with a shape of 8x15 and then transposed to 15x8 to ensure that the data ends up in the correct spots in the data array. I was shaping the data as 15x8 from the start, but since the data comes out of flight software and it has the opposite order defined, this was not producing expected results during validation.
Closes #1836
Updated Files