Hello 
,
In order to use numpy inside grasshopper, I planned to use the Proxy of Compass Package.
Unfortunately, during my test, done outside of grasshopper using Pycharm, to compare the efficiency of my own, pure python, method and numpy’s ones via Proxy, I encountered some freezes …
The code I ran with python 2.7 is the following:
# -*- coding: utf-8 -*-
import numpy as np
import time
from compas.rpc import Proxy
linalg = Proxy('numpy.linalg', url='http://127.0.0.1')
a = np.random.rand(20, 20) * 100.
v = np.random.rand(20)
n_iter = 62
print("via numpy")
t_0 = time.time()
for i in range(n_iter):
print(i)
c = linalg.solve(a,v)
c = 0.
print("via numpy\nNombre d'itérations: {}\nTemps: {}".format(n_iter, time.time() - t_0))
The process always freezes at the 61th iterations … If I lower n_iter everything runs smoothly …
I was wondering if anyone has an idea of why it happens and if there’s any way to solve the problem ?
Thank you very much,
Alexandre
hi,
i can indeed reproduce this problem (however, on my computer it only blocks sometimes and i also have to increase the number of iterations quite significantly).
that said, it is not clear to me what you are trying to investigate with this script. you are sending so many requests to the server in such rapid succession that it basically blocks. it is almost like a DoS attack on your own localhost 
. for example, if i just add a timeout to the loop (time.sleep(0.1)), everything works as expected.
the kind of interaction that you are testing is more the job of a websocket connection where the connection stays open and many requests can be sent and many responses received very quickly. a new “websocket” version of RPC is under development, but it will take a while before it will be released.
anyway, i will have a look what can be done and get back to you. in the meantime, i would suggest to hand off “heavier” calculations to the proxy. for example, to let the proxy handle the entire loop rather than the inner part of the iteration…
hope this helps.
tom
It’s important to understand where the costs of this operation are. An rpc call, by definition, involves serialization back and forth, so the operation you want to do on the remote side (linalg.solve in your case) needs to be more expensive than the serialization/deserialization costs for it to make sense. And I am pretty certain that’s not the case here.
That said, I’m not entirely sure why it freezes, but as Tom points out, it’s not really how the proxy is intended to be used.
it seems to trigger a ConnectionRefusedError which is not handled properly…
Hello,
Thank you for your responses.
As part of a non-linear finite element computation algorithm for my master thesis, I have to solve quite a lot of linear systems. So I wanted to test, how fast numerous solves can be.
But as both of you pointed out, it’s far from efficient … I’d love to be able to run heavier calculations with the proxy but I don’t really know how to do it 
…
Can I open, let’s say, a file tools.py which contains all my methods with the Proxy ? It would be so much helpful !
If computation speed is very important, perhaps you should consider moving out of grasshopper and carry out the analysis directly in numpy? Just weigh the tradeoffs of implementing your geometry-generation logic in compas (or other library). Maybe you can export your very initial geometry from rhino as an .obj / .json and then carry out the geometric modifications / analysis parts outside.
although it sounds like a lot of work, the easiest way to get started with all of this is to make a simple python package with your code (you could use the cookiecutter template for this). if you install this package into your environment and in Rhino, calling its code from Rhino using RPC is quite straightforward.
as @arpastrana has pointed out, you can then still choose to run the analysis in Rhino or just in an editor with some basic geometric inputs.
i f you provide a little bit more detail about what you are trying to achieve i could point you in the right direction…
Creating a package with my methods is the solution I tough I’m glad to hear this suggestion from you ! I don’t know anything about the cookiecutter template but I’m going to check ! Thanks !
The basic idea is to create a package similar to Karamba 3D and made to design and calculate tensegrity structures in a parametric way.
As the non-linear approach is inevitable, and so is Numpy, I had to come up with a solution to do the calculation inside Grasshopper.
I thought of doing the computations externally, the same way you @arpastrana pointed out 
, but after discussing with my master thesis advisor we agreed on the fact that by doing this we loose the dynamic aspect of direct feedback offered by the parametric design 
…
So I think I’ll have to do the all the computation inside Grasshopper. And the quicker, the better
Maybe using the proxy to do all the computation part and doing the “data-creation” with a pure python script in GH_Python would be the best way, or at least a good solution.