Series“, è il corso più seguito in Italia sulla modellazione parametrica, giunto al nono anno consecutivo di attivazione. Plug it fornirà ai partecipanti un’effettiva padronanza delle più avanzate tecniche di modellazione digitale, approfondendo le metodologie della modellazione algoritmica e parametrica nel campo dell’architettura e del design del prodotto. Il corso è rivolto a studenti e professionisti dei settori della progettazione architettonica, design, moda e gioielleria, con esperienza minima nel disegno CAD bidimensionale (acquisita su qualsiasi piattaforma software) e si articolerà in lezioni teoriche frontali ed esercitazioni guidate.
_
FORM FINDING STRATEGIES | Livello Intermedio | Analisi ambientale ed ottimizzazione della forma
Form Finding Strategies è il secondo step del percorso formativo in tre fasi “AAD Workshop Series“. Il workshop intende esplorare le possibilità di generazione di forme efficienti in relazione ad influenze esterne ed alle caratteristiche intrinseche della materia stessa. Analisi ambientale (input solari, termici ed acustici) ed analisi/ottimizzazione strutturale FEM saranno le principali metodologie utilizzate per raggiungere gli obiettivi di ricerca della forma. Saranno introdotti numerosi plug-ins tra cui: Weaverbird, Kangaroo, Geco/Ecotect, Ladybug, Millipede. Il corso si rivolge a studenti e professionisti con conoscenza base di Rhino e Grasshopper.
_
PERSPECTIVES | Livello Avanzato | Python coding e modellazione algoritmica avanzata
Il nuovo corso Perspectives proposto per la prima volta nel 2019 (ed ultimo step del percorso formativo in tre fasi “AAD Workshop Series) introdurrà gli studenti alla programmazione Python ed alla sua integrazione con Grasshopper. Verranno inoltre esplorate tecniche avanzate di generazione formale basate su iterazioni. Tra i principali plugins utilizzati: GhPython, Anemone, Hoopsnake, Plankton, MeshMachine, Pufferfish. Pensato come workshop innovativo sulle prospettive e sfide future del design computazionale, è rivolto a studenti e professionisti con esperienza in modellazione algoritmica con Grasshopper.
INFO ED ISCRIZIONI
…
use I don't agree with the practice of using site EUI as a metric to evaluate the thermodynamic performance, environmental impact, or monetary value of a building. I disagree with this practice for the same reason that there are no "totalThermalLoad" and "thermalLoadBalance" for simulations run with full HVAC. I can summarize these reasons in the following way:
When we run a simulation with ideal air loads, the heating/cooling values we get are THERMAL ENERGY that is directly added to or removed from the zone. In this way, we can draw a rough parallel between these two types of energy since they are are generally of a similar type and quality. As such, I am ok with adding them together to get total thermal load or subtracting them to get a sense of thermal load balance.
However, when we run a simulation will full HVAC, the heating/cooling values that we get are usually HEATING FUEL ENERGY and ELECTRICITY respectively. Fuel energy and electricity are fundamentally two different types and qualities of energy. To cite the second law of thermodynamics, the exergy (or the capacity to do work) of electricity is much greater than that of fuel. This is evident in the fact that, to produce a given unit of electricity, I often have to burn at least 3 units of fuel energy (though this can be much more for inefficient plants). With each step in a power plant - making steam, turning a turbine, turning a generator - there are significant energy losses. This difference in exergy is also evident in the fact that there are so many more things that I can do directly with a unit of electricity than I can do with the same unit of fuel energy. I can use electricity to directly refrigerate, produce light energy or power a motor just as easily as I can use to to cook, produce hot water, or heat a space. While I can cook, make hot water, or heat a space directly with fuel energy, refrigeration and lighting are much more difficult. For this reason, I do not feel comfortable adding electricity and fuel together either in the totalThermalLoad output or in a site EUI metric.
Still, the use of site EUI has become so ingrained in the industry that I have to acknowledge it and at least show users how it's calculated. In my view, it's an ad-hoc metric that was invented to deal with previously limited amount of information on energy sources.
Instead of using site EUI, I would recommend using the following metrics depending on what you are trying to evaluate:
Utility Cost / Square Meter - to measure the monetary value of a building to an owner or user
Kg CO2 / Square Meter - to measure the environmental and climatic impact of a building
Emergy / Square Meter - to measure the overall thermodynamic performance of a building
The first two are actually fairly easy to calculate these days just by researching your site's utility rates or grid energy mixture and multiplying the building electricity or fuel by their respective rates. I will add in some capabilities to Honeybee soon to make it even easier for you to get these values from your EPW file and databases of utility rates/grid mixture. Emergy is much harder to calculate as you have to trace all your energy sources all of the way back to the sun but there are a number of experts at work to make this calculation possible (probably in the next few years, we may have much easier ways to calculate it).
Hope this helps explain the current setup.
-Chris…
onents (radiation, sunlight-hours and view analysis) which let you study the effect of the orientation of your building and the analysis result. When you come to a question similar to "what is the orientation that the building receives the most/least amount of radiation?" is probably the right time to use this component.
HOW?
I'll try to explain the steps using a simple example. Here is my design geometries. The building in the center is the building to be designed and the rest of the buildings are context. I want to see the effect of orientation on the amount of the radiation on the test building surfaces from the start of Oct. to the end of Feb. for Chicago.
First I need to set up the normal radiation analysis and run it for the building as it is right now. [I'm not going to explain how you can set up this since you can find it in the sample file (Download the sample file from here)]
Now I need to set up the parameters for orientation study using orientationStudyPar component. You can find it under the Extra tab:
At minimum I need to input the divisionAngle, and the totalAngle and set runTheStudy to True. In this case I put 45 for divisionAngle and 180 for the totalAngle which means I want the study to be run for angles 0, 45, 90, 135 and 180.
[Note1: The divisionAngle should be divisible by totalAngle.]
[Note 2: If you don't provide any point for the basePoint, the component will use the center of the geometry as the center of the rotation.]
[Note 3: You can also rotate the context with the geometry! Normally you don't have the chance to change the context to make your design work but if you got lucky the rotateContext input is for you! Set it to True. The default is set to False.]
You're all set for the orientation study, just connect the orientationStudyPar output to OrientationStudyP input in the component and wait for the result!
The component will run the study for all the orientations and preview the latest geometry. To see the result just grab a quick graph and connect it to totalRadiation. As you can see in the graph 135 is the orientation that I receive the maximum radiation. Dang!
If you want to see all the result geometries set bakeIt to True, and the result will be baked under LadyBug> RadaitionStudy>[projectname]> . The layer name starts with a number which is the totalRadiation.
Mostapha…
her people) a tremendous amount of time creating them by hand. Dog Treat was far from perfect, however it was good enough to use almost daily.
Three years is a long time. Since 2016 my Gh knowledge has expanded and I’ve seen how dodgy some of the scripting is. With this in mind I started work on a new build. Many things have been tweaked and some things have been rebuilt from the ground up.
Everything has been designed to be leaner and be a general solution to the problem of creating dog bone corners on geometry for quick, efficient and safe CNC fabrication.
Some of these things are:
Adding prompts about user geometry to make them aware about open curves, varying curve heights and if their geometry had been altered (mostly removing unnecessary points on curves).
Smooth Transfers. If you’re in a rush and need to speed through cutting, smooth transfers mean that a lead in geometry is now created alongside the actual dog bone arc. This means the router bit doesn’t have to come to a minute stop at every corner. This is turned on by default.
Acute Angle Condition If the angle between the two curves adjacent to a dog bone point is acute, previously the dog bone corner was useless. This was because the distance between the end points of the dog bone arc were less than the diameter of the router bit. There are many ways this condition could be addressed. I chose to circumscribe a larger arc based on the original angle between the adjacent curves. While it removes more material from the corner, it minimises tool wear and any potential for material to burn.
Single Curve A single curve can now be input into Dog Treat. It will be output with both internal and external treatments.
I’ll continue to update Dog Treat as the need arises, it’s become somewhat of a hobby now. Maybe one day it will become part of a Plug-in… once I learn to code it though!
Happy Treating!
Hi Everyone,
Here's a tool I've been working on for the past 4 months or so in my free time. It's a dog bone corner generator, however it's a little different to some of the existing ones. It's designed to be used for large amounts of geometry and as such, it avoids using any curve boolean operations that are computationally taxing. You don't have to split your curves up into internal and external lots either, it works it all out so you can be lazy. I've also incorporated Lunch Box's Object Bake Component for a one click operation that bakes geometry back out to Internal and External profile layers.
Let me know how it goes, will update where necessary.
Best,
Darcy
Change Log
06/11/19 - Version 2.0 SECOND DINNER - Rebuild
29/09/17 - Version 1.3 - Now with smooth corners option, True for smooth default/False for original
18/05/17 - Version 1.2 - Now includes variable angle domain input (defaults at 90°) for angled corners
13/11/16 - slight change to enable acceptance of very large interior curves
…
Added by Darcy Zelenko at 8:44pm on November 9, 2016
he example file to this file so you can give it a try with any version of Honeybee that you're already using. The only requirement is to have OpenStudio installed as the component is using OpenStudio libraries to parse gbXML files. If you're using the latest version available on github the component is also available under WIP tab.
Why?
The main purpose of developing this component is to save time and effort for importing Revit models for energy and daylight analysis. It bothers me to see a lot of smart people spend a lot of time to just come up with solutions just to get the geometry from Revit to Honeybee for analysis. This component is not solving all the issue but is a first step forward. In an ideal world, the future version of Honeybee, which works both under DynamoBIM and Grasshopper should address this issue but that can take some time to be fully ready!
How?
To use this component you need to Export your Revit model as gbXML and then use the file path to load the file into Grasshopper. There are several resources available online on how to prepare the analytical model in Revit and export the gbXML file. Here is an image for importing the Revit 2017 sample model using the default settings. As you can see the model will be just as good as what your original gbXML file from Revit is.
What can be improved?
Well, there are several items that can be improved and they are mostly not on us. To get it started I add what I think are the 3 main shortcomings and my thoughts on how they can be addressed in the future. Feel free to add what you think needs to be added to this list in the comments section.
1. Revit analytical models and as the results gbXML files, by design, are not intended to be clean. Watch this presentation from the Autodesk University to see the logic behind this approach which in short is it doesn't matter for a large scale early stage energy model. Well, This will be quite a problem for studies that you can do with Honeybee. Included but not limited to daylight and comfort analysis.
The best solution that I can think of, until Autodesk fixes their exporter, is to use Revit Rooms and Spaces and generate a clean model from the scratch. We have already tried this approach in Revit but since the Revit API doesn't provide access to Room openings we had a very hard time to get it to work.
That's why that I opened an idea on Revit ideas to get over this issue. With your support we already have 81 votes, but it hasn't been enough to make them to consider the idea for an official review. If you haven't voted already and you think this will be a helpful feature take a moment and vote so we can have it implemented at some point in the future.
2. There is no way (that I know) to export only part of the model. The way export gbXML is set up in Revit is to export the whole model once together. As a result, if you have a huge model with 100 rooms and you want to get one of the rooms into Honeybee using this component you have to export the whole model, which can take some time, and then import them all back into Grasshopper. To partially address this issue I added an input to the component that allows you input a list of names for rooms that you're interested to be loaded into Grasshopper. You can use the name of the room/space in Revit as an input for the component.
3. The component doesn't import adjacencies, loads, schedules and HVAC systems. I wasn't able to export a gbXML file from Revit with any of this data except for the adjacency, but even if you can do that, the component currently can only import geometries and constructions. I hope we get access to 1 and so we don't have to use the xml file approach at all, but if that takes a very long time then we will add these features to the component.
Happy 2017!
Mostapha…
gap as for a 20 meter gap, it's not a good argument.
I fully concede that not every single thing may be backed up by logic. There are simply too many design decisions to make and not enough time to make them rigorously. And I do believe there is place for human intuition and art in architecture, but I also think that artistic (or intuitive, or emotional) considerations should clearly be labelled as such.
When Le Corbusier designed the urban layout of the city of Chandigarh he used his intuition to distribute the buildings and clusters. His intuition however was grounded in European climes and it failed him in India. On hot days it becomes almost impossible to walk the distance between them. Would Chandigarh have been a better place if the maximum distance was defined by the largest walkable distance on the hottest day of the year instead of the unjustifiable intuition of the designer? I suspect it would.
Furthermore, I believe that architects - student and professionals alike - regularly make formal decisions according to their aesthetic judgement. To suggest that students aren't qualified to make a design decision during their studies because they think it's formally successful seems exceedingly stingy;
There are plenty of rational decisions which are made by tacit processes. People can become very good at mimicking rational behaviour using intuition. And -as I said- if you are an architect with a distinguished career; if you've already proven yourself to be capable of good design then there comes a point where your intuitions can be trusted (to an extend).
But students whose every design has always been virtual, who have not been able to evaluate their decisions by a follow-up study, I don't see how anybody can trust their instincts. Instincts aren't just sitting in someone's brain, they are cultivated by relentless exercise and trial-and-error. Until you actually build something there is no error, only trial, and virtual trial at that.
I find architects' attempts to justify what are obviously decisions based on formal taste using other means often taking the same form of obfuscation that makes architects appear to be intellectual charlatans to specialists in other fields.
I fully agree here. If there are non-communicable aspects to a design, just say that. There's no shame in it as long as you're honest about it and have considered -however briefly- the consequences in case you're wrong.
I'm by no means advocating that all architects must master every detail in their work. Rather, that architects have at least a generalist's working knowledge of materials and construction systems. Floors don't levitate, and windows require depth; rules of thumb count as vital knowledge.
I think we're on the same page here. If you want to make a physical building, then there's more to it than pure design. Engineering comes into play. I don't mean to imply that engineering doesn't require creativity or even artistic intellect, but it is a different kind of problem-solving.
I fully agree with your fourth point. I just wasn't sure what performance-driven meant.
--
David Rutten
david@mcneel.com
Tirol, Austria…
Added by David Rutten at 4:19pm on August 14, 2013
si à faire le tri avec Grasshopper et l'outil Points in Brep, comme je pensais. Je suis passé d'environ 400 000 points à uniquement 20 000 points autour de mes 3 rails. C'est très efficace (mais un peu dangereux avec tous ces points).
J'ai interdit au composant CircleFit de faire un cercle, s'il n'y a pas au moins 5 points présents sur la section. Car lorsqu'il y a seulement 3 ou 4 points, il suffit qu'il y en ait un pour que le cercle soit faux, alors qu'au delà, le cercle a plus de chance d'être "bon".
J'ai également créé des "Pipe" (créés à partir de portions de l'axe) au lieu des "Box » de sélection des points pour éviter de sélection trop de points que ne serait pas des points du rail.
J'ai ensuite créé des « panel » pour la moyenne des distances en X et en Y et la moyenne des distances centre à centre.
Tout cela fonctionne bien avec un axe et un tuyau. Mais maintenant j'essaie d'appliquer ça à plusieurs rails en même temps. Je crois avoir compris qu'il faut créer des « path » dans l'imput manager, et faire correspondre le « path » de l'axe et celui du Tuyau.
Dans mon exemple j’ai mis 3 courbes et 21 sections. Au moment où j'utilise les boîtes pour créer les portions des axes, il crée 63 « sous-path » de 1 courbe alors qu'il faudrait qu'il crée 3 "paths" de 21 courbes, enfin si j'ai bien compris.
Car une fois qu’il a créé les points à l’intérieur des « Pipe », il doit les projeter sur les plans correspondant. Et c’est là que le problème se voit. Il ne fait pas correspondre les points à projeter et les plans.
Je vous envoie la version à une courbe et un tuyau (c’est la v5 avec un fichier rhino ou la courbe d'axe est "bakée" pour pouvoir faire un zoom sur la zone plus rapidement) et je vous envoie également, celle avec 3 courbes et 3 tuyaux. Sachant qu’il faudra également attribuer un rayon pour un des tuyaux et un autre rayon pour les deux autres.
Tout ça est bien compliqué, j’espère que je ne vous embête pas trop.
Merci d’avance.…
onsider:
Identify the aspect of calculations that consumes the most amount of time and resources: Based on what I have understood till now about the parametric workflow within the Grasshopper environment I don’t think it is Rhino/Grasshopper that consumes the maximum amount of time/resources (unless you are handling complex geometry and using native rendering). So, if you could identify the part of your iterations that consumes the maximum amount of resources we can look into parallelizing/optimizing that. It could be something like (RhinoModelling-15%, E+-40%,Radiance-45%)… If there is no way to keep track of that right now in Grasshopper, let me know, I might be able to write a custom script that records the timestamp for each part of the calculation.
Parallelizing Grasshopper: I have no idea of how to do this so I think the best resource/forum would the Grasshopper/Honeybee discussion board. I think at the very least, to make Grasshopper run on remote computers, you’d have to install Rhino/Grasshopper on those computers as well.
Parallelizing EnergyPlus/Radiance: Based on what I understand from reading Mostapha’s source code and also talking to him on this issue, Honeybee typically creates batch files ie radiance or e+ instructions which are then used to run EnergyPlus and Radiance. Radiance runs can be parallelized to a great extent, however, owing to the modular nature of how calculations are setup for grid point calculations , image rendering and some of the new matrix based calculations, there is no single answer to parallelizing Radiance calculations. One can look into optimizing a certain type of calculation and then code instructions for implementing those. E+, which I have only been using for the past month or so, doesn’t seem to have a native way of setting up parallel runs. One can, however, set up multiple separate runs of E+ and direct them to separate processors. I think there was some discussion E+ in the Honeybee forum so you might get a better answer from there on this issue.
Clustering computers and GPU based calculations: One way of implementing the kind of parallelizing that you are referring to, ie. utilizing unused desktops is to cluster computers. Penn State has a dedicated, text-only, Linux-based cluster system which I have been tinkering with for the past year or so. A single node of this cluster has 60 parallel cores and close to 300GB or RAM. Each node, in turn, was created by linking a bunch of computers together. Implementing such a cluster would require an active participation from IT systems admins in your firm. Another option is to use Accelerad for Radiance which parallelizes Radiance . Radiance doesn’t have a limitation regarding the number of cores you could use. I think the 8 processors that you mentioned is more a function of the currently available desktop computer configurations than Radiance’s ability to handle more processors(i7 for example, has 8 processors). In the past, I have run parallel renderings with up to 20 processors. Radiance code is optimized to run on Linux systems so the performance on Windows systems is likely to be somewhat slower.
Finally, unless there is a pre-existing platform to handle such parallel processing, some scripting effort would be required to direct calculation files outwards into different systems/processors and then fetch and consolidate results from those calculations into a single location and then visualize those results on an interface like Mostapha’s Design Explorer.
Sarith…
ing ways to leverage simulation results from ladybug and inform design of building envelops with benefits that can be modeled. Given 20 percent of the cost of a project typically goes to the facades, and maybe a half of that goes to the openings, there is a good enough reason to question how to materialize that 10 percent, which can result in 10-30 percent difference in total energy comsumption.
I think ideally radiation analysis, natural ventilation and daylight analysis on floors should all inform opening sizes and placements, as well as the building sections at large. However natural ventilation seems to be the most complicated one because it couples airflow and thermo dynamics. I have a definition setup so that I can batch simulations for radiation analysis and daylight analysis, but natural ventilation is the missing link. So for what I am doing now I will select a handful of design that seem to work the best based on the two available analysis and convert all the geometry into CAD files so that I can run them in an evaluation copy of autodesk simulation CFD. So for now I can do this in 2 stages.
But for the future, given the possibility of actually have that as a part of grasshopper feature, which would be lovely, I want to understand the science behind it and share some links.
(http://www.wbdg.org/resources/naturalventilation.php) In this link the author outlines quite a few general principles and variables to consider for natural ventilated buildings.
For example, how stack effect works.
Qstack = Cd*A*[2gh(Ti-To)/Ti]^1/2, where
Qstack = volume of ventilation rate (m³/s)Cd = 0.65, a discharge coefficient.A = free area of inlet opening (m²), which equals area of outlet opening.g =9.8 (m/s²). the acceleration due to gravityh = vertical distance between inlet and outlet midpoints (m)Ti = average temperature of indoor air (K), note that 27°C = 300 K.To = average temperature of outdoor air (K)
The thing about natural ventilation is that not only the sizes and positioning of openings of the facade facing predominant wind matter, but also the openings on the other side matter. The vertical distance between the inlets and outlets also need to be taken into account. The author suggests that naturally ventilated buildings should be no wider than 45 feet.
and in this pdf presentation it discusses CFD for natural ventilation and illustrates why it is not easy
http://isites.harvard.edu/fs/docs/icb.topic882838.files/L17.6205Airflow-Modeling_Ibarra.pdf
and in this pdf briefly outlines the approach taken by designbuilder
http://isites.harvard.edu/fs/docs/icb.topic472869.files/DesignBuilder%20Simulation%20Training_HSD.pdf
Lastly a wide spectrum of environmental analysis works by e3lab
http://www.e3lab.org/research
http://www.e3lab.org/green-buildings
If I make progress on a way to tie the three analysis together (radiation, daylight and natural ventilation), I wont forget to post it on this thread.
Thanks.…