"Server Busy" error using NumPy

Replies to This Discussion

Permalink Reply by Giulio Piacentino on May 18, 2012 at 4:31pm

Hi Rob,

thanks for posting this here, it's great. Yes, chances are high that you are running out of addressable memory. 32-bit Rhino obviously has to live with the usual 32-bit memory limits.

You could try importing the Rhino module and running this statement:
import Rhino
#Turns off the Server Busy message in Rhino
Rhino.Runtime.HostUtils.DisplayOleAlerts(False)


but it is probable be that the underlying error will still be there.

Are there maybe ways to diminish memory usage to avoid the problem altogether?
Can you post a sample?

- Giulio
________________
giulio@mcneel.com

Permalink Reply by Rob Slater on May 20, 2012 at 1:36pm

Hi Giulio,

 

Thanks for your response. I have tried turning off alerts, but you're right, the problem persists without the messagebox.

 

I could diminish memory usage somewhat, although I'm using almost all the data I create. What I can do is split the analysis into chunks (I'm doing an annual environmental analysis, so I could work things out month by month, say, and only keep the results I need). However this throws up problems too. The issue now boils down to this:

 

If I run the following in Rhino (i.e. not using Grasshopper)...


import clr

clr.AddReference("mtrand")

import numpy

a = numpy.zeros(10000000)

...I have no problem. I don't reach the limit of addressable memory. But if I do the following...


import clr

clr.AddReference("mtrand")

import numpy

for i in range(10):

    a = numpy.zeros(10000000)

...I run out of memory, even though you wouldn't expect more memory usage, as 'a' should be re-written each time. It seems that this isn't the case though, as I hit the memory limit and crash Rhino. It looks as though something's going wrong with the garbage collection?

 

Since posting, I noticed this document on EnThought's release page:http://www.enthought.com/repo/.iron/NumPySciPyforDotNet.pdf ... which on page 7 mentions a memory error IronPython can hit when arrays are created and discarded quickly. This looks like the problem I'm hitting, though I'm struggling to get around it. Re-writing my code to use the while-loop trick isn't practical, though I'm curious to understand the code that "exists in NumpyDotNet which will trigger a garbage collection run and wait for the finaliser queue to empty." Sounds like what I need to do, but I don't really know how to access what they're referring to - could you help me out??

 

Thanks again,

 

Rob

Permalink Reply by Giulio Piacentino on May 20, 2012 at 2:50pm

Yes, this looks like a NumPy on IronPython problem and I hadn't yet encountered, but I'll  try to write this off the top of my head. Tomorrow I could perform a better analysis:


del a

#and then:
import System
System.GC.Collect()
System.GC.WaitForPendingFinalizers()
System.GC.Collect() #collect the revived and finalized elements


I think the combination of the two should work but I havn't tested it,

please let me know how it goes,

- Giulio
________________
giulio@mcneel.com

Permalink Reply by Rob Slater on May 21, 2012 at 5:02am

Hi Giulio,

 

This works great, thanks for you help!

 

Rob