me in 19 different pipeline components. Marginally better, but I'll still need to do this operation approx. 80 times...gulp.
Here's a wishlist request for David: expose string inputs in the Geometry Pipeline for Layer and Name. If I had that, I could change one string to swap my whole geometry set! (My layers have names like "B1 red rail", "B1 blue rail" etc., then the next time I'll want "B2 red rail", "B2 blue rail" etc.)
BTW, I'm happy to script something in C# if it will help: maybe I could write something like the Geometry Pipeline that takes a string input for layer name? Hmmm...
…
g these times itself). If it works on selection alone, it would probably implement faster.
Theoretically, does this mean the total solving time of the definition is the 'chain of components' that takes the longest time? In the picture above, it would be the chain consisting 'point-curve-divideDistance'?
Because that still adds up only to 97%, I am assuming the Point and Slider component start solving in parallel, and the two Divide components also start solving in parallel?…
am doing the paneling tutorial from the first primer..pg 88. i baked it but while selecting the multiple geometries i cannot select individual ones, they are selected as surfaces..is that ok or .....?
Added by SHILPA PANDE at 6:25am on February 16, 2013
est of the best)
Crucial DDR4 2133 ECC (what else?)
4* WD RE 500 in Raid combo (not shown)
Some stupid 2.5'' HD thingy (avoid 2.5'' disks)
No SSD thingy
Corsair CPU cooler (Tequila replaced the OEM liquid: it works)
…
CA, DA, DC)Two of those diagonal lengths are obviously redundant but they allow you to simply shift the array to get at different rotational permutations. This makes the search for the nearest mean a bit more straightforward since, in the context of panel clustering, you'd need to consider all rotational permutations of each one.…
Added by David Reeves at 5:26am on November 9, 2014
blinds be (B1,B2..B5). Then the geometry for the five iterations will be ((A+B1), (A+B2)...(A+B5)).
And assume that you are measuring illuminance at four points inside the room (x1,x2,x3,x4) and one point outside the room(y1).
The way Daysim works ( and should work as per the best of my understanding) is that for each setting of the blind (ie. B1,B2,..B5), a separate value of (x1,x2,x3,x4) gets calculated through the Daylight Coefficient Method. So let's say you have illuminance thresholds of (p,q,r,s,t) corresponding to (B1,B2,..B5). What the shade-control algorithm does is that it compares the illuminance at y1 with your threshold of (p,q,..t) and then chooses a value of (x1,x,2,x3,x4) on basis of that. So, when we repeat this process for (365x24=)8760 hours , we end up with a value of a shade setting for each hour which was set on basis of your threshold illuminance values.
I would have gladly answered your question on HB itself, however, I usually work with Daysim directly through commandline.
(BTW, if you are interested in reading more about Daysim google Christoph Reinhart's dissertation on the subject, along with some papers by Zack Rogers).…
hreads where Thread I solves object A1 and Thread II solves object A2. As soon as A1 is completed, Thread I can move on to object B1 and as soon as A2 completes, Thread II can move on to object B3 (whichever comes first). When both A1 and A2 are complete, we can spawn a new thread (III) to take care of object B2.
If B2 completes before B3, then Thread III will terminate. If B3 completes before B2, then Thread II terminates. Whichever thread is last will pick up execution of object C3. And so on and so forth.
This sort of threading is actually not guaranteed to help much though, as it is likely that the bottleneck components in the network will still need to be handled by a single thread.
A more efficient solution would be to divvy up the execution per component to multiple threads. If you're trying to compute the Curve Closest Point for 10,000 points and your machine contains 4 cores, then we can assign 2,500 points to the first core, 2,500 points to the second core etc.
This approach will actually work when there's only a few bottleneck components and it also means the order in which components are solved is no longer important.
An even more fine-grained approach to threading would be to make the Curve Closest Point function in the Rhino SDK threaded. There's a lot of looping going on in any given Curve CP computation so the curve could be broken up into loose spans where each span is solved by a different core. Then the partial results get consolidated once all threads finish.
The benefit here is that it would be multi-core for everyone, not just Grasshopper components.
The bad news: Some functions in Rhino are not thread-safe. Meaning that data structures such as NurbsCurves cannot be modified from multiple threads at once as it will compromise their validity. You might well end up with invalid curves and quite possible weird crashes. In very bad cases it might even be that a specific function in our SDK can only be running once, so even if you were to duplicate the curve it would still not work.
Until our SDK is thread-safe there can be no global threading in Grasshopper. I don't know where we're headed with this, but I do know that we've started using some threaded algorithms in the display as of Rhino5, so it seems we're at least getting our feet wet.
--
David Rutten
david@mcneel.com
Seattle, WA…
Added by David Rutten at 5:47pm on November 17, 2010
I don't think I know what you mean. If it is that you want the curve numbers written out as text tags, use the reworked example below and adjust it to your needs.
/Ola