I am trying to use SurfaceSplit grasshopper function and divide the execution between my two processor cores. But for some reason, I am getting unexpected result when using parallel.run function. Using just plain “ghcomp.SurfaceSplit(srf,crvs)” returns expected result.
Why is that so?
import ghpythonlib.components as ghcomp
import ghpythonlib.parallel
def srfSplit(curves2):
result = ghcomp.SurfaceSplit(srf,curves2)
if result:
return result
else:
return
if run:
a = ghpythonlib.parallel.run(srfSplit, crvs, True)
else:
a = ghcomp.SurfaceSplit(srf,crvs)
I might be wrong but I believe that you wont be able to do this as the trimming that you are trying to do modifies the original geometry. Hence, if you multithread the trimming will occur on the original surface several times, thats is why when you use multithreding you get more surfaces that if you dont.
Hope this helps. There might be a work around but I’m not sure.
-Miguel
Ah, I see what’s going on. Everything is actually working correct. The SurfaceSplit component will produce different results if you just call it once for every curve than once with all of the curves.
If you run SurfaceSplit and pass in two circles on the surface, you will get three results back.
If you run SurfaceSplit twice, once for each circle, you will get four results.
Thank you for the reply Steve.
But not sure I understand you.
I did understand Miguel’s reply though - for example: it’s one thing to take a list of mutually independent surfaces and cap them. And completely another thing trying to split a single surface with a list of curves. Is that because each time one of cpus takes a brep and splits it with a curve, it takes an original brep, not the one previous cpu already processed? Or furthermore - can he (that current cpu) even take a brep which previous cpu processed, when they are in fact working simultaneously on part by part of the list of curves?
Does all this make sense, or maybe I’m still a bit confused, because today my football club got last year’s winners as next opponents in Champions League?
I find this a real interesting question.
Although I think you are correct in your assumptions, I wonder if there is a workaround.
if you split a mesh with one curve, it will result in either two (if the curve is on the brep) or one (if it is not) brep(s).
this is obviously done by one core.
when it results in one brep the next task of checking the brep with the next curve the task stays on one core, but when it results in two the multiple cores could become interesting. Instead of one core checking if the following curve is on either one of the resulting breps, this task could be split over multiple cores that do the same task.
As soon as the line results in a hit or total miss, it should be removed from the lines to test. Whenever a brep splits it should be removed as well only to be replaced by two new breps!
So instead of the list of curves being tested on a single brep, the single brep grows into a list of breps that are tested to single lines!
At least, this is what I think.
For I to have to come over the fact that a damaged old team beat our young guys past week. Good luck, Ibra should do the trick
What you could do is check the length of the list(breprs) first and if it has more than one object you could multithread. I didn’t try it but I’m assuming you will have a small increase in performance as the amount of cutters(curves) increases. I’ll give it a try tomorrow.
The parallel library is meant for independent calculations. Calling SplitSurface one passing in two curves will have different results than calling SplitSurface twice each time passing in a single curve.
Hopefully this sample helps illustrate the difference. Notice that there are four outputs in one case and three outputs in the other. surface_split.gh (10.9 KB)
SplitSurface appears to work just fine with multiple threads. You are just calling it in different ways than the single threaded version and expecting the same results. If you had a component that had multiple surfaces as input and called SplitSurface of each surface in a different thread but using all of the curves as input eah time you would get good results.
Ah, sorry.
Then my question formulation was not correct:
Is there a way to call the multithread version on a single surface and a list of curves, and return the same result as if it was done on single threaded version?
