he picture (4).
Previously, I had a problem with generating intersections between the two directions of the beams, but a colleague helped me by extending beams, so there was no problem with lines of intersection. But this solution has generated curl (5) at the highest vertex geometry, which I ignored in order to repair it before printing, perhaps this mean my problem with my beam spread properly. Only when the beams is 19, does not jump no problem, but I still can not distribute them properly.
(1)
(2)
(3)
(4)
(5)
I tried to show as simply as possible by removing or signing my code in GHX file.
Thank you in advance for your help
…
as one element.
Thank you
Comment by karamba on October 7, 2014 at 11:27pm
Hello Patricio, divide the beams in such a way that each boundary vertex of the shell becomes an endpoint of a beam segment.
Best, Clemens
Comment by Llordella Patricio on October 8, 2014 at 8:30amDelete Comment
Hi Clemens,
I did what you suggested but now assemble element doesn´t work properly. Could you please tell me how to fix it? Thanks in advance, Patricio
8-10-14losa%20cadena.gh
Comment by karamba on October 8, 2014 at 11:59am
Hi Patricio, if you flatten the 'Elem'-input at the 'Assemble'-component the definition works. The triangular shell elements have linear displacement interpolations whereas the beam deflections are exact. In order to get correct results you should refine the shell mesh.
Best, Clemens
Comment by Llordella Patricio on October 9, 2014 at 8:35amDelete Comment
Hello, succeeds in creating the mesh to the slab, and built the beam segment, but when I see the deformations are not expected because the beam is deformed as the slab.
Thanks for the help
PS: maybe I'm using the program for a type of structure that is not the most appropriate, as I saw in the examples of other structures. But this type of structure is that students taught
best regards
Patricio
9-10-14%20Example%201.gh
Comment by karamba on October 9, 2014 at 10:46am
You could use the 'Mesh Edges'-component to retrieve the naked edges and turn them into beams - see attached file:91014Example1_cp.gh
Best regards,
Clemens
Comment by Llordella Patricio on October 15, 2014 at 3:41pmDelete Comment
Dear clemens
I was doing a rough estimate of the deformation, and I can not achieve the same result with Karamba. When I make a rough estimate of the result with Karamba beams and mine are very similar, I think the problem is when I connect the shell, because there are no similar results.
I sent the GH file, and an image of the calculation
The structure is concrete The result I get is 0.58cm
thank youPatricio
15-10-14%20Example.gh
Comment by karamba yesterday
Dear Patricio,
try to increase the number of shell elements. As mentioned in the manual they are linear elements. A mesh that is too coarse leads to a response which is stiffer than the real structure.
Best,
Clemens
…
rameters, which forces the user to connect all three curve input parameters (even if only 2 are required) to avoid the message 'Input parameter ... failed to collect data'. How can I set up the curve inputs so that null values are valid? I'm currently registering these as curve parameters as below, and suspect the answer lies in using a different method for parameter registration.
protected override void RegisterInputParams(GH_Component.GH_InputParamManagerpManager)
{
pManager.Register_SurfaceParam(
"Reference Surface", "S", "Surface on which laths are to be generated", GH_ParamAccess.item);
pManager.Register_CurveParam(
"Surface curves 1", "Curves 1", "Set of curves across surface in first direction", GH_ParamAccess.list);
pManager.Register_CurveParam(
"Surface curves 2", "Curves 2", "Set of curves across surface in second direction", GH_ParamAccess.list);
pManager.Register_CurveParam(
"Surface Curves 3", "Curves 3", "Set of curves across surface in third direction", GH_ParamAccess.list);
pManager.Register_DoubleParam(
"Lath Offsets 1", "LO1", "Offset from surface to centreline of first layer", 0.0, GH_ParamAccess.item);
pManager.Register_DoubleParam(
"Lath Offsets 2", "LO2", "Offset from surface to centreline of second layer", 0.0, GH_ParamAccess.item);
pManager.Register_DoubleParam(
"Lath Offsets 3", "LO3", "Offset from surface to centreline of third layer", 0.0, GH_ParamAccess.item);
pManager.Register_IntegerParam(
"Seed Value (0, 1, 2)", "Seed", "Seed value for weave offsets (0 for no weave, 1 or 2 for weave)",0, GH_ParamAccess.item);
}
Thanks!
Alex
…
Added by Alex Baalham at 9:48am on October 1, 2012
ion of both Ladybug and Honeybee. Notable among the new components are 51 new Honeybee components for setting up and running energy simulations and 15 new Ladybug components for running detailed comfort analyses. We are also happy to announce the start of comprehensive tutorial series on how to use the components and the first one on getting started with Ladybug can be found here:
https://www.youtube.com/playlist?list=PLruLh1AdY-Sj_XGz3kzHUoWmpWDXNep1O
A second one on how to use the new Ladybug comfort components can be found here:
https://www.youtube.com/playlist?list=PLruLh1AdY-Sho45_D4BV1HKcIz7oVmZ8v
Here is a short list highlighting some of the capabilities of this current Honeybee release:
1) Run EnergyPlus and OpenStudio Simulations - A couple of components to export your HBZones into IDF or OSM files and run energy simulations right from the grasshopper window! Also included are several components for adjusting the parameters of the simulations and requesting a wide range of possible outputs.
2) Assign EnergyPlus Constructions - A set of components that allow you to assign constructions from the OpenStudio library to your Honeybee objects. This also includes components for searching through the OpenStudio construction/material library and components to create your own constructions and materials.
3) Assign EnergyPlus Schedules and Loads - A set of components for assigning schedules and Loads from the Openstudio library to your Honeybee zones. This includes the ability to auto-assign these based on your program or to tweak individual values. You can even create your own schedules from a stream of 8760 values with the new “Create CSV Schedule” component. Lastly, there is a component for converting any E+ schedule to 8760 values, which you can then visualize with the standard Ladybug components
4) Assign HVAC Systems - A set of components for assigning some basic ASHRAE HVAC systems that can be run with the Export to OpenStudio component. You can even adjust the parameters of these systems right in Grasshopper.
Note: The ASHRAE systems are only available for OpenStudio and can’t be used with Honeybee’s EnergyPlus component. Also, only ideal air, VAV and PTHP systems are currently available but more will be on their way soon!
5) Import And Visualize EnergyPlus Results - A set of components to import numerical EnergyPlus simulation results back into grasshopper such that they can be visualized with any of the standard Ladybug components (ie. the 3D chart or Psychrometric chart). Importers are made for zone-level results as well as surface results and surfaces results can be easily separated based on surface type. This also means that E+ results can be analyzed with the new Ladybug comfort calculator components and used in shade or natural ventilation studies. Lastly, there are a set of components for coloring zone/surface geometry with EnergyPlus results and for coloring the shades around zones with shade desirability.
6) Increased Radiance and Daysim Capabilities - Several updates have also been made to the existing Radiance and Daysim components including parallel Radiance Image-based analysis.
7) Visualize HBObject Attributes - A few components have been added to assist with setting up honeybee objects and ensuing the the correct properties have been assigned. These include components to separate surfaces based on boundary condition and components to label surfaces and zones with virtually any of their EnergyPlus or Radiance attributes.
8) WIP Grizzly Bear gbxml Exporter - Lastly, the release includes an WIP version of the Grizzly Bear gbXML exporter, which will continue to be developed over the next few months.
And here’s a list of the new Ladybug capabilities:
1) Comfort Models - Three comfort models that have been translated to python for your use in GH: PMV, Adaptive, and Outdoor (UTCI). Each of these models has a “Comfort Calculator” component for which you can input parameters like temperature and wind speed to get out comfort metrics. These can be used in conjunction with EPW data or EnergyPlus results to calculate comfort for every hour of the year.
2) Ladybug Psychrometric Chart - A new interactive psychrometric chart that was made possible thanks to the releasing of the Berkely Center for the Built Environment Comfort Tool Code (https://github.com/CenterForTheBuiltEnvironment/comfort-tool). The new psychrometric chart allows you to move the comfort polygon around based on PMV comfort metrics, plot EPW or EnergyPlus results on the psych chart, and see how many hours are made comfortable in each case. The component also allows you to plot polygons representing passive building strategies (like internal heat gain or evaporative cooling), which will adjust dynamically with the comfort polygon and are based on the strategies included in Climate Consultant.
3) Solar Adjusted MRT and Outdoor Shade Evaluator - A component has been added to allow you to account for shortwave solar radiation in comfort studies by adjusting Mean Radiant Temperature. This adjusted MRT can then be factored into outdoor comfort studies and used with an new Ladybug Comfort Shade Benefit Evaluator to design outdoor shades and awnings.
4) Wind Speed - Two new components for visualizing wind profile curves and calculating wind speed at particular heights. These allow users to translate EPW wind speed from the meteorological station to the terrain type and height above ground for their site. They will also help inform the CFD simulations that will be coming in later releases.
5) Sky Color Visualizer - A component has been added that allows you to visualize a clear sky for any hour of the year in order to get a sense of the sky qualities and understand light conditions in periods before or after sunset.
Ready to Start?
Here is what you will need to do:
Download Honeybee and Ladybug from the same link here. Make sure that you remove any old version of Ladybug and Honeybee if you have one, as mentioned on the Ladybug group page.
You will also need to install RADIANCE, DAYSIM and ENERGYPLUS on your system. We already sent a video about how to get RADIANCE and Daysim installed (link). You can download EnergyPlus 8.1 for Windows from the DOE website (http://apps1.eere.energy.gov/buildings/energyplus/?utm_source=EnergyPlus&utm_medium=redirect&utm_campaign=EnergyPlus%2Bredirect%2B1).
“EnergyPlus is a whole building energy simulation program that engineers, architects, and researchers use to model energy and water use in buildings.”
“OpenStudio is a cross-platform (Windows, Mac, and Linux) collection of software tools to support whole building energy modeling using EnergyPlus and advanced daylight analysis using Radiance.”
Make sure that you install ENERGYPLUS in a folder with no spaces in the file path (e.g. “C:\Program Files” has a space between “Program” and “Files”). A good option for each is C:\EnergyPlusV8-1-0, which is usually the default locations when you run the downloaded installer.
New Example Files!
We have put together a large number of new updated example files and you should use these to get yourself started. You can download them from the link on the group page.
New Developers:
Since the last release, we have had several new members join the Ladybug + Honeybee developer team:
Chien Si Harriman - Chien Si has contributed a large amount of code and new components in the OpenStudio workflow including components to add ASHRAE HVAC systems into your energy models and adjust their parameters. He is also the author of the Grizzly Bear gbxml exporter and will be continuing work on this in the following months.
Trygve Wastvedt - Trygve has contributed a core set of functions that were used to make the new Ladybug Colored Sky Visualizer and have also helped sync the Ladybug Sunpath to give sun positions for the current year of 2014
Abraham Yezioro - Abraham has contributed an awesome new bioclimatic chart for comfort analyses, which, despite its presence in the WIP tab, is nearly complete!
Djordje Spasic - Djordje has contributed a number of core functions that were used to make the new Ladybug Wind Speed Calculator and Wind Profile Visualizer components and will be assisting with workflows to process CFD results in the future. He also has some more outdoor comfort metrics in the works.
Andrew Heumann - Andrew contributed an endlessly useful list item selector, which can adjust based on the input list, and has multiple applications throughout Ladybug and Honeybee. One of the best is for selecting zone-level programs after selecting an overall building program.
Alex Jacobson - Alex also assisted with the coding of the wind speed components.
And, as always, a special thanks goes to all of our awesome users who tested the new components through their several iterations. Special thanks goes to Daniel, Michal, Francisco, and Agus for their continuous support. Thanks again for all the support, great suggestions and comments. We really cannot thank you enough.
Enjoy!,
Ladybug + Honeybee Development Team
PS: If you want to be updated about the news about Ladybug and Honeybee like Ladybug’s Facebook page (https://www.facebook.com/LadyBugforGrasshopper) or follow ladybug’s twitter account (@ladybug_tool).
…
ails.
Some word about the mesh... (see Image_01)
I took a flat 4 points NURBS surface as imput (very easy, it defines the total area of my pavilion) and some points (that defines the contact with the ground).
Then I extracted a grid of points from the NURBS (Surface_Util_Divide surface) and compared 'em with the contol points, in order to associate to each grid's point its own attractor (Vector_Point_Closest Point).
Than I moved the points down. I used the distance from each point to its attractor (inverted) as amplitude for the vector of the movement, in order to say: the nearer you are to the control point, the more intense your movement will be. During this operation I've passed the distances' data list into a graph mapper (Params_Special_Graph Mapper), in order to regulate in a very intuitive and interactive way the shaping of my canopy.
At the end of the process I asked GH for a simple Delaunay mesh (Mesh_Triangulation_Delaunay Mesh). It's a very cool command, I believe!!!
Ok, now some word about the component, it's design and it's repetition/adaptation to the mesh...
(see Image_02)
I took the mesh and extracted components on first and faces's information on second. Then I selected and separated the vertexes (1°, 2°, 3°) of each triangular face into threee well defined list.
Then I re-created the triangles' edges. Please pay attention because it's not the same if you use output information from Delaunay components, because here we need a justapposition of edges where triangles touches each others.
After this work I joined the edges and found their centroid. At the same time I found the mid point of each edge.
Now the component... (see Image_03)
It' a little bit longer to describe: I'll try to be synthetic.
Substantially it is a loft from a curve to a point, repeated three times for each triangle (Surface_Freeform_Extrude Point). The point is an elevation of the centroid of the triangle (you can choose if the exstrusion has a single height or it's related to an attractor. In my case it was fixed). The curve is combination of things. There's an arch, which starts on the edge (there's an offset from the corner) end terminates on the same edge (on the other side, obviously). While it's generation the arch passes through a third point which belong to another segment. This last connects the mid point of the original edge (base triangle) with the centroid. The result is a kind of polyline, with two segments and an arch. If you go back to the image of the component that I posted probably you'll understand what I'm saying better than with the definition.
The posit…
sophy though, I have a rudimentary grasp of the Ancient Greeks and modern schools of thought such as Existentialism and Pragmatism, but there is certainly no depth in my understanding. However here the same rule applies. You can quote philosophy all you want, but unless you understand that which you're channelling you can be -at best- accidentally correct.
According to you, these are all vital characteristics:
Aesthetic judgement
Intuition about spatial effectiveness
Knowledge of construction materials & assembly systems
Consideration of performance-driven design properties
Mad synthesizing skillz
[1] and [2] are pretty much worthless, especially when we're dealing with students. Aesthetic judgement is not something that can be wrong or right. You can hone your aesthetic skills but you cannot cultivate better tastes. Intuition is also problematic. It's basically a stand-in for argumentation. Instead of saying "these buildings have to have 20 meters apart because of wind/sound/human perception/human psychology/light/shadow/etc. etc" is a far stronger statement than "these buildings have to have 20 meters apart because of my feelings". Who are you to be trusted? If you have a long and distinguished career backing you up, maybe your opinions carry some weight, but until that point you'd better be prepared to justify your decisions with cold hard logic and data.
[3] is certainly important for certain jobs in construction, but it can be argued that implementation details are not necessarily central to a design. One can design a good computer interface without having to be able to program, and certainly without being familiar with all the idiosyncrasies of a particular programming language. Conversely, one can design an excellent space without knowing exactly how strong certain atomic bonds are. If what you design is physically impossible, then obviously something has to change, but it doesn't mean that the design as an abstract idea was bad. Of course on the other hand one can argue that designing impossible things is not doing anyone any favours. I'm not exactly certain where I stand on this issue, probably comfortably in the middle; YES, students need to learn about what can be build in the physical world, but NO that is not part of design training.
I'm not quite sure what [4] means.
[5] is true for a lot of professions, not just Architects. I would concede that architects probably have more to take into account than most designers and that it is indeed an important skill to have.
I would say that -especially for students, who have little experience- an incredibly important skill to be able to ask yourself "why am I doing this?" about pretty much every decision you make. Basically you need to get very comfortable applying the Socratic method to everything you do.
--
David Rutten
david@mcneel.com
Tirol, Austria…
Added by David Rutten at 11:03am on August 14, 2013
ctor. I do not dispose of any IGH_Goo instances, mostly because I have no idea when an instance is truly no longer needed. If any of your fields need to be disposed, you may have to implement a destructor, but I have no experience with this.
2) should I pass those classes to other parameters by DA(0, MotherClass.Duplicate?) or it is already there by GH_Goo ?
IGH_Goo is not duplicated by default. If you use DA.GetData() and ask for IGH_Goo types, you'll get a reference to the same instance as exists. Thus, if you take in an instance of your type, modify and output it, you should duplicate it yourself. But you only need to do this if you change the state of an instance.
MyGooType data = null;
if (!DA.GetData(0, ref data)) return;
data = data.Duplicate() as MyGooType;
data.Property = newValue;
DA.SetData(0, data);
3) should I create ChildClass and MotherClass in SolveInstance, or create it once as a component's field and then change theirs properties and pass it to DA (as duplicate ?)....
It's almost always better to use variables with the lowest possible scope. So method variables are preferred to class variables, class variables are preferred to static variables.
4) if I create those classes in SolveInstance, is it necessary to Dispose them there ?
NO! Do not dispose of instances that are passed on to output parameters. Disposing objects typically makes them invalid, so if you share instances with anyone else, you should not dispose them or the other code may well crash. However I don't think your types need to be disposable so this is a moot point now.
In general, if you're dealing with disposable types, and the instances aren't shared, then you dispose them as quickly as possible. But if they are shared it's a lot more complicated.
5) finally - maybe it would be better if MotherClass inherits the ChildClass ?
Maybe. Not necessarily. Depends on the classes. …
Added by David Rutten at 12:08pm on December 31, 2014
rk and I will just clarify some of the details. I will also note that I do not know what the shadings output of the decomposeByType component is supposed to do as Mostapha put it there a long time ago and I was not sure what his intentions were. Going down a list of clarification points:
1) You are right that you should either connect up the shade breps to the EPContext component or just plug the HBObjwShades into the RunSimulation component (never do both). However, connecting the breps to the EPContext component is greatly undesirable for two reasons: It will make the simulation run much longer and the energyPlus calculation will not account for the surface temperatures of the blinds (it will assume they are the same temperature as the outdoor air, which is very wrong in a lot of cases). When you connect up the HBObjwShades to run the simulation, EnergyPlus will understand the blinds as abstract objects defined only by a numeric parameterization and not as actual geometry. This enables the calculation to run fast and is also enough of a description that E+ can calculate the temperature of the blinds, thereby accounting for the heat that can be re-radiated from the blinds to the indoors when they get hot in the sun. This more desirable way of running the blinds was how I imagined the component being run most of the time and I mostly included the shadeBreps so that you have a visual of what you are simulating.
2) When you use the more desirable HBObjWShades to approximate your blinds, you should use the blindsSchedule input in order to tell E+ when the shades are pulled (this is instead of the transShcedule on the EPContext component).
3) The zoneData inputs on the EPWindowShade component are meant to help in an entirely different workflow, which evaluates shade benefit based on energy simulation results. I apologize if it seems confusing to have two major uses of the component in one but we have so many Honeybee components right now and I did not want to make 2 separate ones when they seemed so similar. See this example file to see how to do energy shade benefit (https://app.box.com/s/oi64zoj5u1slz494grzhgmdkx7yie9jo).
Ok. I think that clears up everything that I know. Now to the part that I do not. As I said, Mostapha put in the shadings input there a long time ago and I do not know what his intentions were. Abraham, as you know, I am about to do a major revision of the EPWindowShade component to make it compatible with OpenStudio, include drapes/generic shades in addition to blinds, and I also should figure out how to do electrochromic glazing. I can easily include all of the visualized shades as output from the decomposeByType component when I do this. However, I do not want to interfere with other intentions Mostapha had when he put the input in. If he could confirm that this was in-line with his vision for the shadings output, I will implement it soon.
-Chris
…
size component supported only ground PV panels and angled roof PV panels.
Download the newest PV SWH system size component from here (Click on "View Raw" to download it. Then move the downloaded .ghuser file to File->Special Folders->User Objects Folder, an confirm to overwrite it with previously located one).
Just a few opinions on the project you are currently working on:This kind of fixed, non-transparent (overhang) PV panels attached to a building facade are vert convenient for locations with higher latitudes.The reason for this is because they (fixed overhang PV panels) are dimensioned according to the sun position at summer solstice. Elevation angles on summer solstice at higher latitude locations are lower, than those of lower latitude locations.Due to Incheon's low latitude (37), you will get rather short length of the PV panels* : less than 10 centimeters (0.097 meters in the attached .gh file below). As you have mentioned, Galapagos needs to be used too.I will just mention some of the good and bad ways in which the upper issue could be somewhat avoided:1) Increasing the vertical distance between PV panels (PV panels appear above every second window).2) Increase the tilt angle. This will increase the length of PV panels also, but will decrease the final annual AC energy output.An example of this solution has been applied at FKI building in Seoul (latitude: 37N):I already did some tests (with tilt angles: 40, 45, 55) and this does not seem like a good solution, though.3) Shrinking the "sun window" by using the minimalSpacingPeriod_ input. In Photovoltaics, a planner is suppose to make the 9h to 15h part of the sun window free of any obstructions. If you try to decrease the "sun window" to 10 to 14h, the length of your PV panels will increase. You can try to experiment a little bit with this (set your minimalSpacingPeriod_ to 21th of June 10 to 14hours). In general, shrinking the sun window on summer solstice is not a good principle during planning.4) Using tracking PV panels, not fixed ones. But Ladybug Photovoltaics components do not support this kind of PV systems. They only support fixed ones.I would personally go with the first option. You can also experiment with the second and third one.Comment back if you have any other questions.-----------------------* By "length of the PV panels" I mean the: tiltedArrayHeight_ input of the PV SWH system size component.…