PyFR 1.13.0: scotch mesh decomposition error


I am trying to test the Scotch mesh partitioner as a validation step for the PyFR Spack package, but unfortunately I am unable to use Scotch.
Is Scotch successfully used by anyone currently?

Nature of bug

Unable to use Scotch for mesh decomposition. " RuntimeError: No partitions available" received.

Error print out (if applicable)

Raise RuntimeError('No partitioners available')
RuntimeError: No partitioners available

PyFR information

  • PyFR version: 1.13.0
  • OS: Ubuntu 20.04/Manjaro Linux
  • Compiler and version: Tried package manager Scotch as well as Spack built Scotch. Scotch version 6.1.1 tried in Spack.

Is it possible to update to PyFR version 1.14 and confirm if the error is still observed?

Hi, @WillT, from what I can see the latest PyFR is 1.13.0 and at this moment it is even with the Github Develop branch. If I am mistaken, please point me to the updated version.


My mistake, I thought we were on 1.14 not 1.13.


❯ time pyfr partition -pscotch 2 euler_vortex_2d.pyfrm .
pyfr partition -pscotch 2 euler_vortex_2d.pyfrm .  0.24s user 0.03s system 99% cpu 0.270 total

Please make sure that the Scotch library is available in your library path. On my system it is /usr/lib64/ Alternatively, you can explicitly set the precise path (in case the library has a non-standard name) via the PYFR_SCOTCH_LIBRARY_PATH environment variable.

Regards, Freddie.

Thanks @fdw, i was indeed not requesting scotch specifically with the -pscotch flag.
BUT now another error has arisen on my Arch machine:

OSError: /usr/lib/ undefined symbol: SCOTCH_errorPrint

How was your copy of Scotch installed/compiled? What OS?

Obtained via:

on my Linux system and from MacPorts on my Macs.

Regards, Freddie.

Thanks @fdw, moving back to my Ubuntu machine, it was successful.

But it seems that the scotch error symbols are located in a separate library which is not linked to the library by default but seems to be linked against during the packaging process with the gentoo, macports, and Ubuntu packages, but is not linked against in Arch AUR package or Spack package. So it does appear to be system specific, albeit an edge use case.

I will try to solve the problem at the Spack level.
Closing for now.

Quick update:
I checked the RHEL RPM package and they indeed patch Scotch to avoid this error. I will implement a similar patch in the Scotch spack package.