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
<https://devtalk.nvidia.com/default/topic/969047/cuda-8-vs2015-corecrt-h-error/>
!
Hope this is useful to everyone.
Happy CFDing everyone!
On Saturday, December 10, 2016 at 8:20:58 AM UTC-8, Jonny Hyman wrote:
>
> 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!
>
>
> On Friday, December 9, 2016 at 9:52:49 PM UTC-8, Freddie Witherden wrote:
>>
>> 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.
>>
>>
--
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 [email protected].
To post to this group, send an email to [email protected].
Visit this group at https://groups.google.com/group/pyfrmailinglist.
For more options, visit https://groups.google.com/d/optout.
