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

0.52.0 breaks seviri_l2_grib-reader with 'EUML2GribFileHandler' object has no attribute '_ssp_lon' #2942

Closed
fwfichtner opened this issue Oct 21, 2024 · 1 comment · Fixed by #2943

Comments

@fwfichtner
Copy link
Contributor

Describe the bug
0.52.0 breaks seviri_l2_grib-reader

To Reproduce

# Your code here
scene = satpy.Scene(reader='seviri_l2_grib', filenames=files)

Expected behavior
To not crash.

Actual results

Traceback (most recent call last):
  File "/Users/username/PycharmProjects/data-engineering-exchange/MTG_FCI_L1/open_and_read.py", line 23, in <module>
    scene = satpy.Scene(reader='seviri_l2_grib', filenames=files)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/miniforge/base/envs/geo/lib/python3.11/site-packages/satpy/scene.py", line 155, in __init__
    self._readers = self._create_reader_instances(filenames=filenames,
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/miniforge/base/envs/geo/lib/python3.11/site-packages/satpy/scene.py", line 176, in _create_reader_instances
    return load_readers(filenames=filenames,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/miniforge/base/envs/geo/lib/python3.11/site-packages/satpy/readers/__init__.py", line 572, in load_readers
    reader_instance.create_storage_items(
  File "/opt/homebrew/Caskroom/miniforge/base/envs/geo/lib/python3.11/site-packages/satpy/readers/yaml_reader.py", line 617, in create_storage_items
    return self.create_filehandlers(files, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/miniforge/base/envs/geo/lib/python3.11/site-packages/satpy/readers/yaml_reader.py", line 629, in create_filehandlers
    filehandlers = self._new_filehandlers_for_filetype(filetype_info,
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/miniforge/base/envs/geo/lib/python3.11/site-packages/satpy/readers/yaml_reader.py", line 612, in _new_filehandlers_for_filetype
    return list(filtered_iter)
           ^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/miniforge/base/envs/geo/lib/python3.11/site-packages/satpy/readers/yaml_reader.py", line 596, in filter_fh_by_metadata
    filehandler.metadata["end_time"] = filehandler.end_time
                                       ^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/miniforge/base/envs/geo/lib/python3.11/site-packages/satpy/readers/eum_l2_grib.py", line 81, in end_time
    delta = SEVIRI_REPEAT_CYCLE_DURATION_RSS if self._ssp_lon == 9.5 else SEVIRI_REPEAT_CYCLE_DURATION
                                                ^^^^^^^^^^^^^
AttributeError: 'EUML2GribFileHandler' object has no attribute '_ssp_lon'
```

**Environment Info:**
 - OS: all
 - Satpy Version: 0.52.0
 - PyResample Version: independent
 - Readers and writers dependencies (when relevant): [run `from satpy.utils import check_satpy; check_satpy()`]

**Additional context**
Add any other context about the problem here.
@strandgren
Copy link
Collaborator

strandgren commented Oct 21, 2024

Thanks for reporting this and sorry for breaking the reader. This bug was introduced by #2717 which adds support for the FCI L2 CLM GRIB product. As part of the PR, the SEVIRI end_time property was improved in order to identify if the data is from Full Earth Scanning (FES) with a temporal resolution of 15 mins or Rapid Scanning Service (RSS) with a temporal resolution of 5 mins. Before the reader always assumed 15 min temporal resolution, which was incorrect for RSS data.

However, the new solution meant that the end_time property was only available after loading a dataset and its metadata and not after Scene initialization and this was not properly captured by the unit test.

#2943 should fix this bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants