le with you.
I am trying to achieve the minimal path algorithm of Steiners tree in Python using the minimal path algorithm.The syntax would be as followsFirst I need to create a cube of any dimension.
Then I need to specify one origin say point A and destination point say B.
Now for this point A,B I need to create a machine based network which will automatically enroute A to B.
Where the angle will be constant i.e 120, length can be a variable, triangular node(steiners tree)using these constraints it will create a network.
Now, I should iterate the program in such a way that I should specify the further points say like A1 and B1 so on.The program will contain a limit constraint where it will come out of iteration loop and start a new loop,forming the network.
By this I will get a dense network of 120 deg branches.
The branching gets denser the moment I add source and destination points.
There can be 100 iterations to reach from A to B but the algorithm chooses the one following the minimal path.
I would be highly thankful to you if you would please share the python syntax and grasshopper definitionCapture.JPG for the same
Thank you for your time in advance
I would be highly grateful if you help me through
warm regards
Arya
12.gifShortest%20path%20algorithm.gh
min-paths.jpgcc.henn.studyimagesminimalpaths.jpg …
oo culm and the web is mad of bamboo slats connected to the culms on either side of the attachment points. To make things clearer (extracted from the above paper):
The authors of the paper did a numerical beam-model in ANSYS to see if they could replicate their theoretical results, and it is fairly correct (some differences due to the non-linear behavior of the semi-ring joints that they use, they remain of an order of 5-10% difference in maximum deflection).
My problem is that I am not able to obtain the same deflection values that the authors did (11.4 mm for a total service load of 7.063 kN applied punctually on the upper chord where the truss elements meet, or even replicate the load/deflection curve). Using an orthotropic material, with the engineering constants taken from (ResearchGate - A bamboo Beam-Column Connection Capable to Transmit Moment), my model is too flexible and I get a maximum deflection of 24.28 mm. I tried other orthotropic mechanical characterizations from other sources (Kathry & Mishra, 2012, Finite element analysis of bamboo and joints using steel members under various loading conditions for design study and Chand , Shukla & Sharma, 2008, Analysis of Mechanical Behaviour of Bamboo (Dendrocalamus strictus) by Using FEM), to no avail.
Of course, the problem could be with the material properties I inputted but I am trying to contact the research team to see directly with them. In the meantime, I am looking to make sure the model itself is not flawed.
It also seems to me that gravity was not accounted for in the numerical of the paper, but it seemed to much of an oversight to be possible (still, the deflection curve of their paper goes through 0).
There are several points I am not quite sure about: after all I am still fairly new to Karamba3D and may still have some things to learn about the inner mechanics of the plugin.
The very first is: should I put eccentricities of the slat-elements of the truss in the definition of their cross-section (directly with the Cross Section box) or as an offset of the beam element (with the ModifyElem box)? I tried both approaches and they seem to yield similar results (max. deflection change by 0.65mm in my latest model).
Second is: is it good practice to subdivide the beam elements in more than one element (and connecting the pieces rigidly) in order to get better results? I imagine some meshing or subdivision is performed when the analysis is run but there is no way of visualizing it (that I found in any case). Subdividing the chord elements seems to give smoother deformation results (though I did not check stress I have to admit). My issue on this topic is that the subdivision of the slat-elements of the web is problematic. On the screenshot below, where the elements are divided in two, lets take the example of node 18. It seems to me that all elements of the diagonal element (28, 29, 34 & 35) are all rigidly connected to the node 18. 28 & 29 are not connected together, independently from 34 & 35. The added rigidity may not be a bad thing for my model, but it is not correct I think? Is there a way of solving the problem?
Element tags:
Node tags:
And here is my GH file (clean enough hopefully): verification-model-V04.gh
Thank you all in advance for any insight (even on the inner logics of Karamba)!
…
artes y Jueves 18:00 a 22:00 Sábado 10:00 a 14:00
Durante el curso el participante conocerá y entenderá los fundamentos de programación y sus aplicaciones usando Processing: una plataforma de desarrollo en lenguaje java, que surgió en MIT, creada por investigadores enfocados a procesos numéricos y/o generativos para arte y diseño. Se realizarán ejercicios programados para generar gráficas, volúmenes o situaciones kinéticas en tiempo real, basado en algoritmos o reglas complejas y en el procesamiento de datos, soluciones que permitirán comprender temas esenciales como datos primitivos y datos compuestos, algoritmos generativos, geometría 2D y 3D paramétrica, programación estructurada y programación orientada a objetos, control de flujo, variables y ámbito de variable, entre otros temas.
NOTA: Es requisito para cursar los talleres del Bloque 1 y Bloque 2 que los alumnos inscritos tegan bases sobre programación. Este taller forma parte del propedéutico para el Diplomado.…
Added by Alberto Lara at 9:37pm on February 12, 2012
he installation folder, Drag & drop SYNTACTIC(green one) over your grasshopper canvas.3. Close your rhino and reopen it. 4. Type GrasshopperDeveloperSettings5. Tick the Memory load *.GHA assemblies using COFF byte arrays option6. Run grasshopper and enjoy plugin…
ra' nella finestra di Grasshopper, in alto, insieme agli altri set di componenti come 'Params', 'Maths', ecc.
Si tratta di un esperimento per cercare di ampliare in qualche modo l'ambito di utilizzo di Grasshopper.
Come sappiamo Grasshopper e' nato per consentire l'utilizzo parametrico di Rhino. Le definizioni di Grasshopper permettono di registrare i passi necessari per costruire gli oggetti, nonche' di variare i dati utilizzati dalla definizione, ad esempio oggetti geometrici, lunghezze, angoli, ecc.
Quando modifichiamo i valori utilizzati dalla definizione Grasshopper automaticamente ricalcola il tutto e ci mostra la preview del risultato.
A questo punto, se il risultato e' soddisfacente, possiamo dire a Grasshopper di inserire gli oggetti in questione nel documento di Rhino, cosicche' li vedremo apparire nelle viste come veri e proprii oggetti Rhino.
Questo modo di lavorare ha avuto un grande successo tra gli utilizzatoti di Rhino, rendendo molto piu' agevole la costruzione di oggetti nel caso in cui sia necessario procedere per tentativi, verificando il risultato prima di stabilire la forma finale da ottenere.
Il successo di Grasshopper pero' ha anche mostrato quanto sia comodo poter definire graficamente le procedure di costruzione, e in generale poter utilizzare Rhino tramite i componenti, ad esempio gli slider, che tutti noi, suppongo, vorremmo avere a disposizione anche quando usiamo Rhino nel modo classico tramite pulsanti e comandi.
Quindi col passare del tempo sono apparsi sempre piu' Add-on per Grasshopper che permettono di eseguire operazioni particolari o anche di utilizzare Grasshopper in ambiti diversi dal concetto originale di 'History programmabile'. Accodandosi a questa tendenza, edoc prova a costruire dei componenti che permettano di operare direttamente sugli oggetti Rhino, cioe' curve, superfici, layer ecc. appartenenti al documento Rhino su cui stiamo lavorando. L'idea e' permettere di utilizzare la comoda interfaccia utente di Grasshopper anche per operazioni che solitamente sono eseguite in modo tradizionale con pulsanti e comandi, o anche tramite script.
Come gia' detto, e' un esperimento. I componenti nascono, muoioni e cambiano molto spesso, nel tentativo di capire cosa puo' essere utile e cosa puo' fuzionare o meno.
Segnalazioni di bug, suggerimenti, considerazioni ecc. sono benvenuti.
se qualche anima pia volesse tradurre questa presentazione gli faremo un monumento equestre!
grazie e scusate
gg
…
nza dal centro delle facce ad un punto fisso per determinare quant'è il valore dell'offset per quella faccia.
Prova questa soluzione per ora:
- abilita il componente disattivato all'inizio;
- il componente curve offset non funziona bene, domani vedo se riesco a crearne uno migliore;
- inforna (bake) la brep risultante e convertila in mesh da rhino;
- per dargli spessore, fai l'offset solido della mesh in rhino per l'ultima fase, funziona meglio.
I've used the distance from the center of the faces to a fixed point to determine the value of the offset.
Try like this:
- enable the first component disabled;
- offset curve don't work perfectly, I'll try to fix it maybe...
- bake the brep and convert it into mesh in rhino;
- for the thickness, do a solid offset of the mesh in rhino for last phase, it just works better.…
n account of the position of the sun and weather cannot be expressed in terms of a single set of luminous intensity values (which is what IES files do).
With regards to your example files, I agree with Chris. The primary reason for the low illuminance levels is that the light bounces are getting lost in the tube. Have you checked with the manufacturer/distributor if the location of the IES file should be inside the tube and not flush with the ceiling? Physically modelling such tubes in lighting software like Radiance (which is what HB uses) or AGI32 is a fairly expensive proposition. This is one of the reasons why manufacturers provide photometric data for such devices (however simplistic that data might be).
The candelamultiplier increases or decreases the luminous intensity values. So it will have a direct impact on the calculation. The primary reason for having that input was to enable users to do some testing with different lamp types and environmental factors such as dirt depreciation. You need not change them for your simulation. Assuming that the IES file is inside the tube, in order to make this calculation work inside HB you'd have to crank up the calculation settings to a very high level (start with -ab 10 -ad 4096).
Finally, due to shortcomings in the annual simulation software (Daysim), IES files will not work directly work with annual calculations. However, there is a fairly easy workaround for that issue. In case you are planning to run annual calculations with IES files, please let us know here.
Sarith…
me research involving shades and and solar radiation and I need the sun's path through the entire year to fully optimize the design. This far I've been able to simulate what I want by having my shadders following a mock solar orbit around them, what I need to know is to use a model that simulates solar paths, use it as an attractor point and have my shadding surfaces follow it, pretty much like that I am doing right now (or so I think)
Here's where my questions come around:
I remember finding somewhere on the internet a definiton that simulates the sun's path through the year; I think I can find it again and use it for my purposes. I think that I could just run the GH definition, bake the geometry and then upload it to Ecotect and have it run so I can get the data and keep working over that, then feed the geometry again to Ecotect, ad nauseam. However I think that is a very slow process.
Is there a way that I can run an Ecotect plug in of sorts within GH, that way I can get my data IN grasshopper and model accordingly?
Does that make sense?
Thanks a lot for any input.…
Added by Antonio Tamez at 3:40am on October 24, 2011
s for the sunlight hours analysis.
I'm producing BRE Annual Probable Sunlight Hours calculations and so to match the BRE approach, I'm using 100 sun vectors, each representing 1% of probable sunlight hours. I could use the Sunpath and Analysis Period components to produce sun positions for the whole year, but this gives results that do not fully reflect the BRE methodology - which is important here. I'm detailing this just to clarify that this isn't a full annual calc of 8760 hours for 350 surfaces.
Anyway, when I run the calc, it takes about an hour to run, but the Sunlight Hours Component itself reports a calculation time of 3 seconds! Does this mean that the rest of the time is all about prepping the brep geometry? If so, is there a reason why this is much slower than when using a view of sky recipe and exporting to radiance. For the same project, I completed a view of sky calculations and based on the number of test points and -ad setting, this was completing about 5.25 billions rays so I understand why that took an hour.
Any thoughts as to why the sunlight hours calc seems to take so long?
thanks
Nick
…