Alea library crashes Rhino

Hi all,

The question is quite simple.
I am developing part of a script for grasshopper that makes use of gpu for computing.
I am trying to use the Alea library which is just a wrap around the CUDA C environment.

I tried two ways.
Loading a component build in Visual Studio, grasshopper does not recognize the Alea library, throwing the exception
"Could not load file or assembly 'Alea, Version="
I checked version, public token and if the file was locked and everything seemed to be fine.

Second way, loading the library directly into a C# grasshopper component.
As soon as I write
Rhino crashes.

Is there any known compatibility issue? If so, is there a way work around the issue?

Thanks in advance

Hi @edu_pignatelli

I am not sure about that assembly in particular. In general, Rhino WIP is a 64-bit application and, as such, can only load 64-bit assemblies.

You can check the first answers here:

for suggestions about this issue. This is not directly a Rhinoceros issue.


Giulio Piacentino
for Robert McNeel & Associates

Hi Giulio,
Thanks for the quick answer.
Here is the return from the corflag of the Alea.dll

Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  3.5.30729.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32
CorFlags  : 9
ILONLY    : 1
32BIT     : 0
Signed    : 1

Looking at these returns

PE        : PE32
32BIT     : 0

and according to,
it should be a legal library for both x86 and x64 architectures. Is this correct or am I missing something?

To provide more specs, I am running a Rhino v5 RS12 64-bit on Windows 7,
Intel i7-4770k and nvidia quadro k1100m

I’m interested in this too if you resolve the issue.

// Rolf


I tried with another .NET library to explore the problem and the same exception has been raised.

1. Solution exception:Could not load file or assembly 'Cudafy.NET, Version=1.29.5576.13786, Culture=neutral, PublicKeyToken=63a4c9931616906b' or one of its dependencies. The system cannot find the file specified.

And this is the the return for the Cudafy.Net libary that shows the same compatibility of the Alea.dll library.

Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  3.5.30729.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32
CorFlags  : 9
ILONLY    : 1
32BIT     : 0
Signed    : 1

Have you got any clue to solve the issue?

I don’t know how interested this community is in running GrassHopepr components on GPU… but I am. :slight_smile: So I posted a fairly elaborate description including packadge paths and projects) of my case on Stackoverflow.

And yes, I’m still chasing milliseconds :slight_smile:

// Rolf


Thank you very much for fostering the community approach Rolf.
It seems that this is an old unsolved problem in Grasshopper.

Anyway, I probably have a solution for that, at least it worked for me.

From this discussion:

To summarize, to solve the issue:

  1. Copy the Alea.dll file to thisdirectory
    C:\Program Files\Rhinoceros 5 (64-bit)\System\

  2. In Rhino type the command
    and uncheck the option:
    Memory load *.GHA assemblies using COFF byte arrays

  3. Run Rhino as administrator

  4. Enjoy

It could probably work even without launching Rhino as Admin and with the COFF box checked, but i haven’t tried yet.

Hi @edu_pignatelli, thanks for these hints. I have copied the file, actually all files to Rhino system, and I keep trying with the simplest code possible, like only accessing the default Gpu, but I keep getting similar error message. This time it complains about FSharp.Core which it can’t find. I thought I was working with CSharp though… < scratching head >

I’ll keep trying different variants.

// Rolf

Hi Rolf,

From the Alea manual and from this discussion:

Alea GPU is implemented with F#, so it uses the F# runtime. If you use Alea GPU from C# or VB, you also need version 3.1 or higher of FSharp.Core.dll assembly. If you use Visual Studio, you can locate that assembly by navigating to Add Reference -> Assemblies -> Extensions -> FSharp.Core Alternatively, you can add FSharp.Core NuGet package to your project.

Unfortunately I do not have time to try right now, but have tried to add the FSharp.Core via NuGet in Visual Studio?

Anyway, it could be interesting if the issue of faulty loaded assemblies in Grasshopper could be investigated.

1 Like

I got the error message fixed by adding symlinks under Rhino…\system\ down to the VS compile folder, like so:

Which under the VS project looks like so :

But for some reason my Gpu.For(…) code silently doesn’t seem to do anything (it doesn’t modify any input variables). The following method for example runs without errors but it returns only an “empty” point [0,0,0] although the input list has 47.000 points off from the origin .:

    public static Point3d GPU_SolveInstance(double[,] points)
        // Sum all axis values
        int Cnt = points.GetLength(0);
        double x_tmp = 0;
        double y_tmp = 0;
        double z_tmp = 0;
        gpu.For(0, Cnt, j => {
            x_tmp += points[j, 0];
            y_tmp += points[j, 1];
            z_tmp += points[j, 2];

        // Average axis values
        Point3d cpt = new Point3d();
        cpt.X = x_tmp / Cnt;
        cpt.Y = y_tmp / Cnt;
        cpt.Z = z_tmp / Cnt;

        return cpt;

Any ideas about what to check?

// Rolf

Hi Rolf,
I did not get to that point yet, since I turned to cudafy, but
you can debud the GPU kernel with Nsight

Also have you installed the CUDA Toolkit?

It seem we are out in the wild trying to utilize the GPU… :head_bandage:

At first (quick) glance, CUDAfy seem to be a bit lower level than Alea, or? Is it still developed? Any success with it so far?

I’m not giving much more of my time trying to make Alea say hello, so I’m interested in any useful alternative.

// Rolf

I am glad you guys solved the Alea issue that was related to memory-loading the DLLs! :tada::tada: That option is there to help load assemblies over networks, and allow reloading sometimes, but I think it really sometimes adds more hurdles rather than helping.


Giulio Piacentino
for Robert McNeel & Associates

I believe the problem was not related to assembly reflection, but for some unknown reasons, Grasshopper (Rhino?) was not able to access the file from the usual %AppData%\Roaming\Grasshopper\Libraries. I assume that it is due to lack of admin privileges in that folder. The library is correctly loaded if copied in the C:\Program Files\Rhinoceros 5 (64-bit)\System folder, or better, if installed in the GAC.

Hope this can help others or future development!

Did you unblock all files that are in use? If you don’t you very well can see this exception.

Grasshopper simply won’t be able to load DLLs that haven’t been unblocked. Anecdote: earlier today I recorded a video about how to use GhShaderNodes, Cycles XML material and the custom preview component to raytrace GH geometry. During the recording session I noticed GhShaderNodes wasn’t loaded. I just had downloaded and installed them, turned out I still had to unblock all of the files (fsharp dlls included)

Yes, all files unblocked! I use to forget that, but it is usually the first thing you do after you cannot find the library.
I also believe that if it was blocked, it would not have been loaded even if in the Rhino System library.