CUBLAS not Initializing

512 views
Skip to first unread message

Jonny Hyman

unread,
Dec 10, 2016, 12:14:53 AM12/10/16
to PyFR Mailing List
Hi there!

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.ini" command 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)

Is this a bug or am I doing something wrong?

Sincerely confused,
Jonny Hyman
:)

Freddie Witherden

unread,
Dec 10, 2016, 12:52:49 AM12/10/16
to pyfrmai...@googlegroups.com
On 09/12/2016 21:14, Jonny Hyman wrote:
> *pyfr.backends.cuda.cublas.CUBLASNotInitialized* Error. This is an error
> code which is documented in the CUDA documentation
> <http://docs.nvidia.com/cuda/cublas/#cublasstatus_t>.
>
> 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)
> |
>
> Is this a bug or am I doing something wrong?

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?

Regards, Freddie.

signature.asc

Jonny Hyman

unread,
Dec 10, 2016, 11:20:58 AM12/10/16
to PyFR Mailing List
Ah! Of course. That makes sense now. Thanks!

This is the first application I've (knowingly) encountered which uses cublas. Not sure what other apps would utilize it. Open to suggestions!

Thanks for the prompt reply!

Jonny Hyman

unread,
Dec 12, 2016, 1:24:51 PM12/12/16
to PyFR Mailing List
Solved!

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:
  1. INCLUDE="C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt"
  2. LIB="C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\um\x64;C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\ucrt\x64"
    - Try this if you get the error :
  1. fatal error C1083: Cannot open include file: 'corecrt.h': No such file or directory
  2. mod.cu

The thread I found the solution in even mentions PyFR 1.50

Hope this is useful to everyone.

Happy CFDing everyone!

Vincent, Peter E

unread,
Dec 12, 2016, 4:38:48 PM12/12/16
to PyFR Mailing List, Jonny Hyman
Many thanks for your interest in the project and the info you have posted.

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!

This was my fault - should be up to date now! Thanks!

Cheers

Peter

Dr Peter Vincent MSci ARCS DIC PhD
Reader in Aeronautics and EPSRC Fellow
Department of Aeronautics
Imperial College London
South Kensington
London
SW7 2AZ
UK

web: www.imperial.ac.uk/aeronautics/research/vincentlab
twitter: @Vincent_Lab





--
You received this message because you are subscribed to the Google Groups "PyFR Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyfrmailingli...@googlegroups.com.
To post to this group, send email to pyfrmai...@googlegroups.com.
Visit this group at https://groups.google.com/group/pyfrmailinglist.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages