Closed dmfay closed 3 years ago
How bizarre. During the OSX build we install libpng-1.6.37:
libpng: 1.6.37-h2573ce8_0 conda-forge
but cmake finds v1.4.12
-- Found PNG: $PREFIX/lib/libpng.dylib (found version "1.4.12")
Compare this with the build on Linux, which installs and finds v1.6.37 correctly:
libpng: 1.6.37-hed695b0_0 conda-forge
...
-- Found PNG: $PREFIX/lib/libpng.so (found version "1.6.37")
It's not obvious at all to me how this could happen. Possibly a problem in the libpng feedstock? Possible an ecCodes build issue. I'll ping someone at ECMWF to see if they can shed any light on it.
@dtip
PNG 1.4.12
-- includes : [/Library/Frameworks/Mono.framework/Headers;$PREFIX/include]
-- libs : [$PREFIX/lib/libpng.dylib;$PREFIX/lib/libz.dylib]
There is some issue with this Mono-Framework. We have this in every MacOSX build on azure, right from the beginning (at least as far as azure keeps the logs). In the last travis builds this Mono-Framework is not there. So maybe we need to do some cleanup of the azure environment.
Xref: https://github.com/conda-forge/libitk-feedstock/pull/37 for similar problem with JPEG.
Looks like they're having our exact problem with libpng on that thread you linked: https://github.com/conda-forge/libitk-feedstock/pull/37#issuecomment-532261626
Lets see if this works: https://github.com/conda-forge/eccodes-feedstock/pull/96
@dmfay I've pushed another build. Please try re-installing ecCodes from conda-forge in a couple of hours and see if it's fixed your problem.
That does look like it helped! I'm getting a different traceback after a couple seconds' wait now:
$ cfgrib to_netcdf MRMS_MergedReflectivityQCComposite_00.50_20191209-210032.grib2
/Users/dian/work/anaconda/envs/mypy3env/lib/python3.8/site-packages/cfgrib/__main__.py:56: FutureWarning: In xarray version 0.15 the default behaviour of `open_mfdataset`
will change. To retain the existing behavior, pass
combine='nested'. To use future default behavior, pass
combine='by_coords'. See
http://xarray.pydata.org/en/stable/combining.html#combining-multi
ds = xr.open_mfdataset(inpaths, engine=engine)
/Users/dian/work/anaconda/envs/mypy3env/lib/python3.8/site-packages/xarray/backends/api.py:926: FutureWarning: The datasets supplied have global dimension coordinates. You may want
to use the new `combine_by_coords` function (or the
`combine='by_coords'` option to `open_mfdataset`) to order the datasets
before concatenation. Alternatively, to continue concatenating based
on the order the datasets are supplied in future, please use the new
`combine_nested` function (or the `combine='nested'` option to
open_mfdataset).
combined = auto_combine(
Exception ignored in: <function Pool.__del__ at 0x119206ee0>
Traceback (most recent call last):
File "/Users/dian/work/anaconda/envs/mypy3env/lib/python3.8/multiprocessing/pool.py", line 268, in __del__
File "/Users/dian/work/anaconda/envs/mypy3env/lib/python3.8/multiprocessing/queues.py", line 362, in put
AttributeError: 'NoneType' object has no attribute 'dumps'
Not the most helpful call stack I've ever seen, but I don't see ecCodes in there anywhere. Should I take this back to the cfgrib issue?
Yes please. I seems like the ecCodes side of things is fixed now. It looks like a problem in the cfgrib python code. But I could be wrong!
Looks like this was resolved.
(from https://github.com/ecmwf/cfgrib/issues/116 )
I'm on OSX, trying to work with NCEP MultiRadar MultiSensor grib2s such as in https://mrms.ncep.noaa.gov/data/2D/MergedReflectivityQCComposite/ , and always getting the following output/traceback reading files in:
Environment (
conda list
):Details about
conda
and system (conda info
):