Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Traceback error using Level2File opening a start L2 radar chunk file #3413

Closed
nevets963 opened this issue Feb 27, 2024 · 1 comment · Fixed by #3415
Closed

Traceback error using Level2File opening a start L2 radar chunk file #3413

nevets963 opened this issue Feb 27, 2024 · 1 comment · Fixed by #3415
Labels
Area: IO Pertains to reading data Type: Bug Something is not working like it should
Milestone

Comments

@nevets963
Copy link

nevets963 commented Feb 27, 2024

What went wrong?

I get a traceback error when trying to opening the start file of a L2 chunk of a volume for specific radar towers: KJKL, KCCX, KMBX, KDDC, KTYX and potentially others too.

Most towers work fine and I'm not familiar enough with the msg formats to know why/how these sites are different.

Operating System

Linux

Version

1.6.1

Python Version

3.10.13

Code to Reproduce

# Download: https://unidata-nexrad-level2-chunks.s3.amazonaws.com/KJKL/160/20240227-102059-001-S

from metpy.io import Level2File
l2file = Level2File("20240227-102059-001-S")

Errors, Traceback, and Logs

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/conda/lib/python3.10/site-packages/metpy/io/nexrad.py", line 193, in __init__
    self._read_data()
  File "/opt/conda/lib/python3.10/site-packages/metpy/io/nexrad.py", line 255, in _read_data
    getattr(self, decoder)(msg_hdr)
  File "/opt/conda/lib/python3.10/site-packages/metpy/io/nexrad.py", line 551, in _decode_msg18
    els.append(self.vcp_el_fmt.unpack_from(dat, off))
  File "/opt/conda/lib/python3.10/site-packages/metpy/io/_tools.py", line 97, in unpack_from
    return self._create(super().unpack_from(buff, offset))
struct.error: unpack_from requires a buffer of at least 1218 bytes for unpacking 46 bytes at offset 1172 (actual buffer size is 1172)
@nevets963 nevets963 added the Type: Bug Something is not working like it should label Feb 27, 2024
dopplershift added a commit to dopplershift/MetPy that referenced this issue Feb 27, 2024
At some point the fixed VCP info in message type 18 was converted to a
spare field. This still parses fine when filled with 0's, but apparently
some sites are now sending out some random bytes in this location, which
can break our parser.
@dopplershift
Copy link
Member

Looks like some metadata bytes we were parsing at some point got converted to spares, which is fine...except when those "spares" contain seemingly random bytes that break the parsing.

Thanks for reporting. Fixed in #3415.

@dopplershift dopplershift added the Area: IO Pertains to reading data label Feb 27, 2024
@dopplershift dopplershift added this to the 1.7.0 milestone Feb 27, 2024
dopplershift added a commit to dopplershift/MetPy that referenced this issue Feb 27, 2024
At some point the fixed VCP info in message type 18 was converted to a
spare field. This still parses fine when filled with 0's, but apparently
some sites are now sending out some random bytes in this location, which
can break our parser.
dopplershift added a commit to dopplershift/MetPy that referenced this issue Feb 28, 2024
At some point the fixed VCP info in message type 18 was converted to a
spare field. This still parses fine when filled with 0's, but apparently
some sites are now sending out some random bytes in this location, which
can break our parser.
@dopplershift dopplershift modified the milestones: 1.7.0, 1.6.2 Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: IO Pertains to reading data Type: Bug Something is not working like it should
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants