er" logic but it miss when comes the copy or offset.
Here is my following logic
Take the square of 25 m x 12 m ; make it a surface
I divide it in "blades" of 20 cm
I take the edges of the "blades",
I divide this edges in 40 points (or equivalent) (A)
I identify my curves (curves) which are on the floors, which are curves (B)
First i do this "test" :
for each crossroad between A and B, i make a circle of X cm (slider) of diameter and the rule is the following :
* In this circle, the future movement of my A curve must be at Z = 0
Second step :
for each next point, i have to : leave a copy on Z = 0 and rise the second one for a heigh of Y cm (slider) from the ground.
the next (W = slider to chose every each number of point, i decide to do the following point) point, which is a little bit farer from the previous point, must duplicate the same height of Y ; and also be copied to Y + Y cm.
There is a Z number (slider) which is the max height possible for these points, which mean that the next point must be at this very same level except ... The third step scenario.
The purpose is to be able to have flat area, like step in a stairway.
Third step :
The grasshopper must test if the A points are between two or more "area at Z = 0". Why ?
The goal is to obtain something like screen "side view" if there are two starting points at Z = 0.
Which also mean that if there is an odd number of points, the remaining odd number must be at the top of the "stairs"
At this point of the grasshopper, we might be able to obtain, thanks to the sliders the "staircase form" regarding :
- The size of the test circle between A and B curves
- The "footstep" of each points (height)
- The number of points before a "copy of the point + the next footstep rise"
- The max heigh possible for all the point off B curves
And at this moment i have a new problem in my logic. You will get my idea, but it might be wrong as well...
Therefore, and after that, we should be able to link every point by a straight line.
To fillet with P (angle) a line with the following one
To join all the line of a same B curve
To cut it at the center of each circle at Z = 0 (the crossroad of A and B)
To offset it with Q (distance)
To rise a line from the center of each circle at Z = 0
To cut the extra part of each Offset"ed" curve to get an offset curve "aligned in Z" with the original one.
To create loft the original and offset"ed" one
To extrude the surface to a distance of R
And grasshopper "should be done" because, i will duplicate it for the ceiling, reverse the form with a -Z vector to the Y value and modifie my Z in Z' to modify my max height
Could you help me ?
…
hit Commit.
I'm wondering how hard it would be to have an edit box which shows the
number the user could click inside of then type in a new number, then
hit enter. :)
2) How would I go about using one line from a table and assign each
field to a variable? Then, move a slider or something and use the values
from the next row?
background: I'm recreating elbows, Tees, and other fittings using
paramatric scripts, then baking and exporting them. Here's one source
table, http://www.wardfittings.com/Assets/PDFs/0902CatalogColorOld.pdf
page 5, the uniform elbows.
Current Setup: the attached ghx file. Create a point at 0,5,0 in a blank
document with units set to inches, then assign that point to the top
left 'Center Pnt' in the ghx file.
Current workflow:
a) Modify variables A, B, H, and Nominal Dia to match one line from the
table in the linked PDF file, page 5, table of regular elbows.
b) Select the 'Nodes' and 'Surfaces' with a drag box
c) Click 'Bake'
d) Switch to Rhino window, do the 'sellast' command.
e) Drag baked objects along Y axis so the center point is at 0,0,0
f) Run 'Join'
g) Run 'Cap'
h) set the 'node' points to a layer called 'nodes'
i) set the surface to a layer called 'fit-3d'.
j) select the surfaces and nodes
k) export selected
This elbow that I'm doing only has 12 rows, so doing it the above method
doesn't take THAT long. I'm also going to be doing a couple with larger
tables like the Tee on page 8, and in other spec files. As you can
imagine, entering in EACH value into a slider is a bit tedious.
I'd love to take the pdf table, run it through an OCR program to convert
to excel, modify the headers so the ghx script knows what they are, then
paste it into grasshopper, or save it and have grasshopper read it, and
I be able to move a slider or something to to select one line at a time.
Has anyone done something similar? ie: assigned one row in a table to a
predefined set of variables, each variable coming from one field in the row?
Thanks for taking the time to read this message. :)
I'm making a rhino script to do steps d-k, so that part will be much faster.
-Suthern…
deform into rhombic dedocahedrons when they reach equilibrium.
http://mathworld.wolfram.com/CubicClosePacking.html
I was trying to model sphere lattice constrained within a boundary box. When inflated, they would not intersect with each other; they would stay in place; and would be malleable just enough to expand and fill in the gaps in between the spheres.
I started off with the help of this thread here(Thanks for those contributed!). As I understood, there was a bug in Kangaroo2. Solver can't handle more than one item plugged in. So I tried to understand David's Stasiuk's Script and adopted it with a few variations, please see gh file attached.
In the first 5 - I've used David Stasiuk's C# component-variable pressure (posted on June 9, 2015 at 12:25am): 'No. 4.5' being the most successful simulation so far(inflation value is kept very low so that they would not intersect);
although I realised I made some math mistake in setting the close packing grid.(could be checked by plugging voronoi3D to see if the area of the rhombic faces are regular)
No. 6-7 I tried with Kangaroo2 components.
After consulting my tutor(Andrei Jipa)'s help, I realised the following changes could be made:
- The definition posted by David on June 8, 2015 at 4:47pm with constant pressure would've worked better.
- Icosahedrons with WbCatmull(Quad divisions) would result in more even load distribution. With wbloop, vertices more concentrated at poles.
- Load in dir Z could be omitted. Andrei has suggested to use lengths(line) in Kangaroo 2 as 'pressure' instead. And I am trying to improve the grid; and maybe try with David's constant pressure definition. I will keep you guys posted of the progress!
I am new to the parametric world, comments/advice very much appreciated! :) Zhini
…
sinergetici associati alla compresenza simultanea di differenti strumenti di analisi e digital design all'interno di un processo di progettazione in svolgimento. I partecipanti utilizzeranno Grasshopper (modellatore parametrico per Rhino): l'uso di questo editor grafico di algoritmi si integra alla perfezione con gli strumenti di modellazione di Rhinoceros 3D espandendo le possibilità di corstruire modelli parametrici altamente complessi. Per generare una complessità simile saranno utilizzati collegamenti live ai diversi programmi elencati di seguito: . Autodesk Ecotect Analysis via GECO . FEA software GSA via SSI Durante questi intensi 3 giorni, i partecipanti impareranno il workflow dei plug-ins con l'aiuto di esempi esplorando una panoramica dei differenti software, le possibilità di testare le performances di un progetto o l'uso di strumenti addizionali non legati ad un singolo sistema (es. accentuazione, formazione, reazione parametrica) [english text] The focus of the workshop is to integrate and correlate the synergistic effect associated with simultaneous presence of different digital design- and analysis tools in an ongoing design process. The main attention is set on easy to handle interface , which should be used at a early stage of conceptual design to respond to external and internal influences in a intelligent and sustainable way. Participants will use the software Grasshopper as a parametric modeling plug-in for Rhino. The usage of this graphical algorithm editor tightly integrated with Rhino's 3-D modeling tools open up the possibility to construct highly parametrical complex models. To generate this complexity we will use live linkages to several programs listed below: . Autodesk Ecotect Analysis via GECO . FEA software GSA via SSI In this 3 intense days, the participants should learn the workflow of the plug-ins with the help of examples and get an overview of the different software's, there possibilities for evaluating the performance of a design or the usage of additional tools to be not chained to a single system . (e.g. parametrical accentuation, parametrical formation, parametrical reaction) [.] Dettagli : Istruttori: Thomas Grabner & Ursula Frick from [uto]. lingua del corso: inglese (saranno disponibili tutor di supporto ma è richiesta una conoscenza di base della lingua unglese).
Quote d'iscrizione (min 12 max 20 posti): educational* : € 280.00 + iva professional: € 450.00 + iva * studenti, docenti, ricercatori, dottorandi e laureati fino a un anno dalla data di laurea OFFERTA EARLY BIRD SPECIAL: le prime 5 domande di iscrizione pervenute entro il 31 Dicembre 2011 avranno diritto ad una quota di iscrizione scontata del 20% Quote d'iscrizione E.B. SPECIAL: E.B. SPECIAL educational* : € 224.00+ iva E.B. SPECIAL professional: € 360.00+ iva. ulteriori info, dettagli e iscrizioni: http://www.co-de-it.com/wordpress/nexus-advanced-grasshopper-workshop-with-uto.html…
instead of ballooning outwards, just puffing upwards.
THIS WILL WORK! Creating the mesh springs is only three seconds for 200X200 and the Unary Force is still milliseconds. Only Kangaroo takes an initiation time then cycles rapidly (0.5 seconds each) and it only takes a few cycles, maybe a dozen or two.
There is considerable 3D aliasing from the 2D mesh crudeness.
Now, to best Laurent's scheme, let's double down to 400X400. First I disable Kangaroo, and the timer. The preparation takes...FOREVER....and...ever...4.6 minutes to cull the points is all, a trivial step there is likely a better strategy for than finding the ones on the inside then using those to cull duplicates from the whole collection. The springs only took 12 seconds and the forces again milliseconds.
Kangaroo, to initialize takes...after hitting the reset button to start it...over 15 minutes and counting...well 400X400 is 160K vertices and Rhino tends to bog down at 30K points...but it was done in 30 minutes. Then I enable the timer and each cycle takes...uh...it's not in any error mode but nothing is happening past a very faint first automatic cycle that shows in the mesh...yet no CPU power is being used by Rhino...well...it's simply not running...ah, well, there's just a dummy delay of another 5 minutes and then the cycles take 2.7 seconds...what a stupid delay that was not using CPU power.
Now that it's cycling, can I change the stiffness in real time, usually I can...well, no, I seem to be back in the 5 minute delay, but not the 30 minutes interface-locking one...still waiting. Here is a 1/4 scale height model of the above output:
Time's up, life goes on. The aliasing and slow speed make it unworkable except for little logos or something. Some math and parallel processing are needed?
…
Added by Nik Willmore at 5:51pm on February 21, 2016
Meeting Agenda:
1) Discuss what the group would like to learn this term through our regular scheduled meetings. Topics include the priority and sequence of Grasshopper exercises we would like to explore during the winter term from http://www.digitaltoolbox.info/grasshopper_basic.html and Processing tutorials from the Processing Handbook I received from MIT.
2) Watch the Matt Storus Church Machine video and have a discussion about parametric and generative tools in design.
If you have a chance, please read the following article by Tim Love called Between Mission Statement and Parametric Model at:
http://places.designobserver.com/entry.html?entry=10757
3) Discuss a possible design build project over the following winter and spring terms using the skill set this group is developing. Conversation led by Chris Nielson (please see comments below for a brief backstory)
4) Discuss possible applied research and design work for the National Conference on the Beginning Design Student paper, Machine Craft and the Contemporary Designer: exploring parameters and variables through making physical artifacts. I wrote the attached abstract and submitted it for the conference the past fall and it was accepted. To continue with the research I need to assemble a team of students that will help explore the principles I set forth by making physical objects with the cnc router. In exchange for helping with the research I will show participants how to use the cnc router, how to author machine code and provide you with the cnc controller interface software necessary to simulate machine movements. Not to mention, your work will be sited in the research paper I present at the conference at UNC Charlotte in March. More tomorrow night, of course.
Thank you for your interest and I hope to see you there.
Sincerely,
Erik Hegre
Chris Nielson Reply by Eugene Parametric Society on January 7, 2010 at 12:02pm
All,
In response to Erik, who requested that I describe my intentions in a design-build project and to the article posted (definitely required reading for this group) I propose that we begin development of a project that spans the realm of "sustainable social" architecture and parametric design. The particulars of such a design do need to be made concrete, and it will be important to define the goals of such a project.
Therefore, I would suggest that this serve as a forum for the next few weeks for those interested in producing a built project. I agree with Nico that it may not be feasible to create the built piece, whatever it may be, this term; however we should have the groundwork and a plan in place by the end of the next 10 weeks.
Either way, I would ask that everyone who is interested to please provide as many concepts to this forum to begin a discussion. If you are indeed interested, please submit goals that this project could achieve (energy, socially, aesthetically, economically, related) and perhaps what you envision the project to physically be (shading device, public bench, water catchment, interactive thermal contraption, etc . . . )
I look forward to hearing your thoughts!
Cheers,
Christopher…
d of interpenetrating surfaces somewhere:
Now all links (except a possible single ball on the very end of odd numbered ball series) are four balls long, including the jostled ones. Without that step, those items simply don't appear in the output, leaving way too big of gaps to ignore, eventually leaving huge gaps at later stages of segment doubling:
So if I turn the jostling multiplication factor way down it should work imperceptibly:
Ta-dah! The jostling strategy WORKS! Granted, only in this special case where I know I'm dealing with adjacent pairs of worms along a curve, not generic objects arranged in space by some artist.
Now I just need to wrap the multiple Python script components I'm stringing together into one script.
How long does the full 2400 balls take, finally? It took 12 Python scripts that merge pairs, to achieve this breakdown: 2400 -> 1200 -> 600 -> 300 -> 150 -> 75 -> 38 -> 19 -> 9 -> 5 -> 3 -> 2 -> 1. Time was 2 minutes 50 seconds, so there is some extra struggle for 2X as many balls as 1200 that took 1 minute 20 seconds, but only ten more seconds.
…
Added by Nik Willmore at 9:06pm on February 17, 2016
he "return" is comment out as shown below?
After restarting Rhino and Grasshopper, I opened the outdoors_airflow demo file, and the first step of creating the case file is ok:
Then the blockMesh component gives the following error: seems I have to manually start OF first..
so, as the error message suggested, I open OF by Start_OF.bat:
Then come back to the blockMesh component, now it can be executed while the OF command line window is also openning:
... and the blockMesh finished successfully:
... so I proceeded to run snappyHexMesh, checkMesh and update fvScheme:
... up to the simpleFoam component, I got the error again:
The warning message is:
1. Solution exception: --> OpenFOAM command Failed!#0 Foam::error::printStack(Foam::Ostream&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #1 Foam::sigFpe::sigHandler(int) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #2 ? in "/lib64/libc.so.6" #3 double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #4 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #5 Foam::GAMGSolver::solveCoarsestLevel(Foam::Field<double>&, Foam::Field<double> const&) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #6 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #7 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #8 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so" #9 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #10 Foam::fvMatrix<double>::solve() in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #11 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #12 __libc_start_main in "/lib64/libc.so.6" #13 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"
... and the command lines in the readMe! output are pretty long and it is saved in the text file attached here.
So, my questions are:
1. why I have to manually start OF first before I can use the blockMesh component? Should butterfly automatically start OF?
2. what might be the cause of the unsuccessful run of simpleFoam in the end?
Hope you can kindly advise! Thank you!
- Ji
…
ahams's question about how shades are accounted for in the simulation/thermal map and Theodore's thought that just accounting for shades in the E+ run was sufficient. I think that it may be clearest to explain what is going on with this infographic:
As the graphic shows, the thermal maps are made from 4 key types of inputs. The radiant temperature map is formed through a consideration of both the temperature of the surfaces surrounding the occupants and the direct solar radiation that might fall onto the occupants through un-shaded windows. The first surface temperature effect is easily computable from your Energy simulation results and the HBZone geometry. However, the second is calculated by seeing how sun vectors pass through the windows of the zones and uses the SolarCal method of the CBE team (http://escholarship.org/uc/item/89m1h2dg) to compute an MRT delta resulting from solar radiation. This delta is then added to the initial values computed through surface temperature view factor. When you do not connect up your shading brep geometry, internal furniture breps, or outdoor context geometry that might block sun to the additionalShading input, the thermal map will assume that sun can pass unobstructed through the window or through indoor furniture to fall onto occupants. It is important to stress that the EnergyPlus simulation does not count for blind geometry or internal furniture as actual geometry. Just as numerical abstractions of surface area and material properties. So we need you to plug in the actual geometry of these things when we compute the MRT delta resulting from sun falling directly onto people.
Next, to clear up the definition of window transmissivity. The important thing to clarify here is that, whether it refers to the tranmittance of glass or to the amount of sun coming through a fine screen of blinds, the value is multiplied by the radiation falling on the occupant and thus has a direct correlation to the MRT Delta from sun falling on occupants. So, if you set transmissivity to zero, the sun falling on the occupants will not be considered in the calculation and, if you set the transmissivity to 1, the assumption is that there is no window (or the window glass is 100% clear). So, Abraham, your definition of it as a coefficient is appropriate.
Normally, I would just recommend that you leave this value at the default 0.7, which corresponds to the transmittance of the default glass material in Honeybee. However, there are 4 cases in which you might consider changing it:
1) You are not using the default Honeybee glazing material, in which case, you should change the transmissivity to be equal to this new value.
2) You have a lot of really small blind/shade geometries and you do not want the view factor component to take several minutes to trace sun vectors through the detailed shade geometry and so you are ok with using just a simple abstraction instead of plugging shade breps into the additionaShading. In this case, you might try to estimate the average percentage of radiation coming through the blind geometry (maybe with some simple Ladybug radiation studies or with your intuition about the amount of sun blocked by the shades). You will then multiply this by the tranmissivity of your glass and this will be the value that you input to the component.
3) Your blinds for your Honeybee simulation are dynamic, in which case, plugging shade breps into additionalShading is not going to work because the component will assume that those shades are always there. In this case, you should be plugging a list of 8760 values into the transmissivity that correspond to when the shades are pulled. When the blinds are completely up, the value should be the tranmittance of your window and, when they are down, the value should be the window tranmittance multiplied by the fraction of light coming through the shades.
4) You have shades/blinds but they are transparent or are not completely opaque. The additionalShading_ input assumes that all shade geometry is opaque and so you cannot use it to account for such shades. Accordingly, you will need to account for it through the tranmissivity.
In the future, I may try to pull more information about blinds and glass properties off of the HBzones inside the view factor component but, for now and for the next few months, the above describes how it works.
Theodore, for curved geometry, I think that your safest bet is going to be planarizing the Rhino geometry before you turn it into a HBZone (so you just divide the curved surface into a few vertical planar panes of glass that approximate the curve well enough). This is essentially what the runSimulation component does for you automatically (it meshes the geometry as you see here: https://www.youtube.com/watch?v=nMQ2Pau4q6c&index=12&list=PLruLh1AdY-SgW4uDtNSMLeiUmA8YXEHT_). If I were to figure out a way to incorporate shades in this automatic meshing workflow, your EnergyPlus simulation would take a very long time to run and I am not even sure if the result will be that accurate with the way E+ abstracts shades. So I don't think that it's really worth it over just planarizing the geometry yourself.
Lastly, I won't be able to figure out the problem with your current run Theodore, unless I get the GH file from you. Make sure that you are using all up-to-date components.
-Chris…