matplotlib 3.8.0 is unable to create a basic plot #1276
Comments
|
Thanks! I was just creating an issue, but you were faster ;-) |
|
I haven't looked into this at all, but I will note that there are many more |
|
I will try installing 3.8.4 via pip3 with the dependent libraries from the spack-stack build and see if that resolves the issue. If not, I will try bumping other versions (e.g. numpy) to see if that resolves it. |
|
It not, I'll see if I can reopen the matplotlib GitHub issue. |
|
The issue appears to be with numpy, and specifically when compiled with Intel. It's a little tricky to replicate as well: module use /scratch1/NCEPDEV/nems/Alexander.Richert/spack-stack-py311-aug24/envs/test/install/modulefiles/Core
module load stack-intel stack-python py-matplotlib
python simple_plot.py # returns an error
module unload py-numpy/1.25.2
module load py-pip
python -m venv venv
. venv/bin/activate
pip install py-numpy==1.25.2
python simple_plot.py # success! |
|
I should mention that upgrading to matplotlib==3.8.4 did not resolve the issue. |
|
Thanks for looking into this. Just to confirm, this works fine if py-numpy is compiled with GNU? And this is on Hera, right? I'll try to build a GNU and Intel environment on another system at NRL to reproduce this. |
|
@climbfuji I'm not sure if this works with GNU or not, but probably. All I have confirmed is that it works when pip installs the binaries, which are almost certainly GNU-compiled. |
|
We always compiled numpy with openblas, with both GNU and Intel, for many releases of spack-stack. That hasn't changed on Hera as far as I know. |
|
@DavidHuber-NOAA Unfortunately I cannot reproduce this on Nautilus. The machine uses
|
|
I built a basic gcc environment on Hera with the following spack.yaml: # spack-stack hash: ac43a4c
# spack hash: d8de455f35
spack:
concretizer:
unify: when_possible
view: false
include:
- site
- common
definitions:
- compilers: ['%gcc']
- packages:
- python@3.11.7
- py-matplotlib@3.8.0
specs:
- matrix:
- [$packages]
- [$compilers]
packages:
all:
prefer: ['%gcc']Numpy built with openblas and I was able to generate the plot. I then built this same environment with Intel and was unable to make the plot, receiving the same > module use /scratch1/NCEPDEV/global/David.Huber/SPACK/ss_matplotlib/envs/matplotlib_intel/install/modulefiles/Core
> module load stack-intel stack-python py-matplotlib
> module list
Currently Loaded Modules:
1) intel/2022.1.2 6) libxcrypt/4.4.35 11) stack-python/3.11.7 16) py-numpy/1.25.2 21) py-kiwisolver/1.4.5 26) py-six/1.16.0
2) stack-intel/2021.5.0 7) zlib-ng/2.1.6 12) libpng/1.6.37 17) py-pybind11/2.11.0 22) py-packaging/23.1 27) py-python-dateutil/2.8.2
3) glibc/2.28 8) sqlite/3.43.2 13) openblas/0.3.24 18) py-contourpy/1.0.7 23) libjpeg/2.1.0 28) qhull/2020.2
4) tar/1.26 9) util-linux-uuid/2.38.1 14) python-venv/1.0 19) py-cycler/0.11.0 24) py-pillow/9.5.0 29) py-matplotlib/3.8.0
5) gettext/0.21.1 10) python/3.11.7 15) py-setuptools/63.4.3 20) py-fonttools/4.39.4 25) py-pyparsing/3.1.2 |
|
Besides the openblas/mkl difference between Nautilus and Hera, the only other difference I see is |
|
@climbfuji I tried rebuilding the environment with I have two more ideas: 1) try building again with |
|
external gettext? |
|
Building the environment with intel-MKL instead of openblas did not fix the issue. @climbfuji Good suggestion. I'll try an external gettext package. |
|
I'm also going to open a matplotlib issue. |
|
@climbfuji I'm unable to concretize with the system gettext:
buildable: false
externals:
- spec: gettext@0.19.8.1
prefix: /usrAnd here is the output of ==> Error: concretization failed for the following reasons:
1. cannot satisfy a requirement for package 'py-setuptools'.Any suggestions? |
Not really, but what I would try is to unpin py-setuptools or pin it to a different version if you get duplicates |
|
@climbfuji I wasn't able to unpin py-setuptools as I got duplicates and attempting to pin it to something newer caused conflicts with py-numpy@1.25.2, so I updated py-numpy to 1.26.4 instead. This did not solve the issue. I then used the system gettext (0.19.8.1), but that also did not solve the issue. I accidentally installed this last round with openblas instead of Intel-MKL, but I doubt that is the issue given that the problem occurred previously with Intel-MKL/py-numpy@1.25.2. I'm not sure where to go from here, but would gladly take suggestions for you and/or @AlexanderRichert-NOAA. |
|
I'm going to try rebuilding the environment but pointing at the gcc-compiled version of py-numpy. |
|
@DavidHuber-NOAA I installed the spack-stack-1.8.0 release candidate on S4 for testing, and I was able to create simple plots with matplotlib. S4 uses intel@2021.5.0. |
|
Building with the gcc-compiled py-numpy was successful. I will wait for an official release candidate installation on Hera then try the test again. |
@DavidHuber-NOAA I need to correct my previous statement. I was able to plot a different, simple plot on S4. Your simple_plot.py fails in the same way on S4 as it does on Hera. |
|
OK, good to know. Thanks for the correction. I'll keep working with my installation on Hera, then. The matplotlib developers may have an idea on how to fix the issue 🤞 |
|
That would be great. I am changing py-numpy versions back by one major number at a time, in the hope that it will work with a somewhat more recent version than what we had in spack-stack-1.7.0. I am also checking on the oneapi compilers, and there are no problems with py-numpy@1.25.2 and py-matplotlib@3.8.0. |
|
@DavidHuber-NOAA I got it to work with After all, Intel classic will be going away soon ... and there is no problem with the LLVM-based compilers with 1.25.2 / 3.8.0. |
|
Fantastic! Alright, that sounds like a plan to me. |
|
I'll keep working with the matplotlib folks and let them know of this workaround. |
|
We have a workaround in place for spack-stack-1.8.0: use We need to keep this issue open until the issue is fixed upstream (matplotlib/matplotlib#28762), or until we switch to the Intel LLVM compilers for C/C++. Whichever solution, hopefully it is in time for spack-stack-1.9.0. |
|
The issue is with the numpy import numpy as np
rows = np.asarray([0, 0])
val = np.asarray([0.11])
print(val[rows].min()) # Returns 0.11 with GNU and LLVM, NaN with Intel ClassicOpened Numpy issue numpy/numpy#27840. |
|
@climbfuji It seems that the issue can be mitigated by disabling some of the |
|
@DavidHuber-NOAA Can you try this locally first and then open a PR? There shouldn't be any issues turning off these features. |
|
Sure, I'd be happy to. I'm just not sure where to make changes to the module files. Could you point me there? |
|
We could either change it in config/common/modules_{lmod,tcl}.yaml (in the main section with the rest of the packages): 'py-numpy%intel target=x86_64_v4:':
environment:
set:
NPY_DISABLE_CPU_FEATURES: AVX512For add it to the py-numpy recipe, assuming we are pretty sure that this is always a problem for numpy+intel classic+avx512 and could convince the Spack devs to incorporate it: def setup_run_environment(self, env):
if self.spec.satisfies("target=x86_64_v4: %intel"):
env.set("NPY_DISABLE_CPU_FEATURES", "AVX512F") |
|
I would prefer the latter. Is |
|
@climbfuji I agree. And no, it may not be sufficient for all systems. I have been working on Hera, but Hercules will likely have newer AVX512 flags. I will build a simple numpy installation over there and see what flags would be required. |
|
I believe it is sufficient, yes. The key there is the colon-- see for example the openblas recipe where we disable AVX512 features for non- |
|
There are a few exotic CPU types that aren't covered, I think. Essentially those that have |
|
Ah dang, yep. Well, how about def setup_run_environment(self, env):
archs = ("x86_64_v4:", "cannonlake:", "mic_knl")
if any([self.spec.satisfies(f"target={arch} %intel") for arch in archs]):
env.set("NPY_DISABLE_CPU_FEATURES", "AVX512F")which covers cannonlake->icelake->sapphirerapids 🙃 |
|
Thanks @AlexanderRichert-NOAA, the second option worked on Hercules. One question, though. Should archs = ("x86_64_v4:", "cannonlake:", "mic_knl:") # Colon after mic_knlI built a minimal stack to build py-matplotlib@3.8.4 and py-numpy@1.26.4 and was able to generate these plots: simple plot and 3D surface. I'll go ahead and make these changes in spack. Should I also open a spack-stack PR to increment matplotlib and numpy? |
|
I think Intel's MIC architecture is a dead horse and we won't be seeing anything that builds on it. Therefore, we don't need the |
Describe the bug
The matplotlib python library is unable to generate a basic plot, i.e. https://matplotlib.org/stable/gallery/lines_bars_and_markers/simple_plot.html. There may be a bug between the version of matplotlib and another python library. Another user reported the same bug, though it was never resolved: matplotlib/matplotlib#23923.
To Reproduce
Expected behavior
A basic sine-wave plot would be generated.
System:
At least Hera
Additional context
Found while testing Python 3.11.7 upgrade #1217.
The text was updated successfully, but these errors were encountered: