Really excited to get into the awesome new world of PyFR! So far as I can tell you guys have done a beautiful job! I’m having an issue with dependencies, or running into a bug? Not sure which…
Calling any pyfr run -b cuda mesh.pyfrm init.inicommand spits out the following response.
The issue is of course the pyfr.backends.cuda.cublas.CUBLASNotInitialized Error. This is an error code which is documented in the CUDA documentation.
It hints there that perhaps cublasCreate should be called earlier? Right now in PyFr1.5.0, we load the library, wrap it, and THEN we “Create”:
class CUDACUBLASKernels(object):
def __init__(self, backend):
# Load and wrap CUBLAS
self._wrappers = CUBLASWrappers()
# Init
self._handle = c_void_p()
self._wrappers.cublasCreate(self._handle)
The code ordering is correct. We can not call cublasCreate from
libcublas.so until we have loaded libcublas.so. Thus, the first thing
we do is load it. Next, we make the relevant functions from the library
available to Python. Once cuBLAS is available we proceed to call
cublasCreate.
Thus our first call into the library is one to cublasCreate.
Can you confirm if other cublas applications work with your set-up?
To anyone facing the same dependency struggles I had getting PyFR to run, here’s some tips:
It’s not stated on the PyFR dependency list, but Microsoft Visual Studio is an implicit requirement. VS2015 Community works for this application.
I had to re-install CUDA 8 with drivers. I had done a custom setup before, but the dynamic links must not have all been made.
Be careful to check that all the packages you get on pip are 64bit. I had pip hang or crash many times with weird errors because I needed to get the 64bit wheel!
PyFR 1.50 as of Dec 10, 2016 is NOT ON the Python Package Index (PIP). That is PyFR 1.4. Only two big updates with 1.5 but still!
There seems to be an issue between system variables with CUDA 8 + VS2015 Community in use with PyCuda. It is solved by adding the system variables: