ature. By investigating the process of decay across various scales, we will formulate rules of generating decomposition as our design research area. These rules will evolve into design strategies for the creation and fabrication of a large-scale prototype. The design and fabrication process will be informed by the use of robotic fabrication techniques.
The three-week long programme is formulated as a two-phase process. During the two-week initial phase, participants benefit from the unique atmosphere and facilities of AA’s London home. The second phase, lasting for a week, shifts to AA’s woodland site in Hooke Park and revolves around the fabrication and assembly of a full-scale architectural intervention.
Prominent Features of the programme:
• Teaching team: Participants engage in an active learning environment where the large tutor to student ratio (5:1) allows for personalized tutorials and debates.
• Facilities: AA Digital Prototyping Lab (DPL) offers laser cutting, CNC milling, and 3d printing facilities. The facilities at AA Hooke Park allow for the fabrication of one-to-one scale prototypes with a 3-axis CNC router, various woodworking power tools, and robotic fabrication.
• Computational skills: The toolset of Summer DLAB includes but is not limited to Rhinoceros, Processing, Grasshopper, and various analysis tools.
• Theoretical understanding: The dissemination of fundamental design techniques and relevant critical thinking methodologies through theoretical sessions and seminars forms one of the major goals of Summer DLAB.
• Professional awareness: Participants ranging from 2nd year students to PhD candidates and full-time professionals experience a highly-focused collaborative educational model which promotes research-based design and making.
• Fabrication: According to the specific agenda of each year, a one-to-one scale prototype is fabricated and assembled by design teams.
• Lecture series: Taking advantage of its unique location, London, Summer DLAB creates a vibrant atmosphere with its intense lecture programme.
Eligibility: The workshop is open to architecture and design students and professionals worldwide.
Accreditation: Participants receive the AA Visiting School Certificate with the completion of the Programme.
Applications: The AA Visiting School requires a fee of £1964 per participant, which includes a £60 Visiting Membership fee. A deposit of £381 is required when registering with the online form. The deadline for applications is 20 July 2015. No portfolio or CV is required. Online application link:
https://www.aaschool.ac.uk/STUDY/ONLINEAPPLICATION/visitingApplication.php?schoolID=325
Return train tickets between London-Hooke Park, accommodation & food in Hooke Park, and materials from Digital Prototyping Lab (DPL) are included in the fees.
Programme Directors:
Elif Erdine (AA Summer DLAB Director): elif.erdine@aaschool.ac.uk
Alexandros Kallegias (AA Summer DLAB Director): alexandros.Kallegias@aaschool.ac.uk
…
ange’ for its 2016 cycle, as a starting point to investigate principles of natural formation processes and interpret them as innovative architectonic spaces. These concepts are carefully interwoven with spatial, performance-based, and structural criteria in order to create full-scale working prototypes.
The three-week long programme is formulated as a two-phase process. During the two-week initial phase, participants benefit from the unique atmosphere and facilities of AA’s London home. The second phase, lasting for a week, shifts to AA’s woodland site in Hooke Park and revolves around the robotic fabrication and assembly of a full-scale architectural intervention.
Prominent Features of the programme:
• Teaching team: Participants engage in an active learning environment where the large tutor to student ratio (5:1) allows for personalized tutorials and debates.
• Facilities: AA Digital Prototyping Lab (DPL) offers laser cutting, CNC milling, and 3d printing facilities. The facilities at AA Hooke Park allow for the fabrication of one-to-one scale prototypes with a 3-axis CNC router, various woodworking power tools, and robotic fabrication.
• Computational skills: The toolset of Summer DLAB includes but is not limited to Rhinoceros, Processing, Grasshopper, and various analysis tools.
• Theoretical understanding: The dissemination of fundamental design techniques and relevant critical thinking methodologies through theoretical sessions and seminars forms one of the major goals of Summer DLAB.
• Professional awareness: Participants ranging from 2nd year students to PhD candidates and full-time professionals experience a highly-focused collaborative educational model which promotes research-based design and making.
• Robotic Fabrication: According to the specific agenda of each year, scaled working models are produced via advanced digital machining tools, followed by the fabrication of a one-to-one scale prototype with the Kuka KR150 robot.
• Lecture series: Taking advantage of its unique location, London, Summer DLAB creates a vibrant atmosphere with its intense lecture programme.
Eligibility: The workshop is open to architecture and design students and professionals worldwide.
Accreditation: Participants receive the AA Visiting School Certificate with the completion of the Programme.
Applications: The AA Visiting School requires a fee of £1900 per participant, which includes a £60 Visiting Membership fee. A deposit of £381 is required when registering with the online form. The deadline for applications is 11 July 2016. No portfolio or CV is required. Online application link:
https://www.aaschool.ac.uk/STUDY/ONLINEAPPLICATION/visitingApplication.php?schoolID=392
Return train tickets between London-Hooke Park, accommodation & food in Hooke Park, and materials from Digital Prototyping Lab (DPL) are included in the fees.
For inquiries, please contact:
elif.erdine@aaschool.ac.uk (Programme Director)
alexandros.kallegias@aaschool.ac.uk (Programme Director)
…
occur more than once in the same list, and different elements with identical values can occur more than once. Also, a list may contain lack of elements, referred to as "nulls".
Sets. Strictly speaking a Set is a mathematical construct which adheres to a strict collection of rules and limitations. Basically, a Set is the same as a List, with the exception that it cannot contain the same element more than once, or indeed two or more different elements with the same values. You see, in mathematics there is no difference between a value and an instance of that value, they are the same thing. In programming however it is possible to store the number 7 in more than one spot in the RAM. Grasshopper does not enforce this rule very strongly though, you can use a lot of Set components on lists that have multiple occurrences of the same value. The big difference between Lists and Sets in Grasshopper is that Sets are only defined for simple data types that have trivial equality comparisons. Basically: booleans, integers, numbers, complex numbers, strings, points, vectors, colours and intervals. Lists can contain all kinds of data.
Strings. Strings are text. There's nothing more to it. I don't know why early programmers chose to call them strings, but I suppose it's a better description of the memory representation of them. Strings are essentially sequences of individual characters.
Trees. Trees are the way all data is stored in Grasshopper. Even when you only have a single item, it will still be stored in a tree. A tree is a sorted collection of lists, where each list is identified by a path. A specific path can only occur once in a tree, when you merge two trees together, lists with identical paths are appended to each other. Trees are an attempt to losslessly represent not just the data itself, but also the history of that data. Imagine you have 4 curves {A,B,C,D} and you divide each into 3 points {X,Y,Z}. Then, for each of those points you create a new line segment {X',Y',Z'} and then divide each of those line segments again into 5 points each {K,L,M,N,O}. The way data is stored in trees, it should be possible to figure out whether a point M belongs to X' or to Z', and whether that X' or Z' came from A, B, C or D. This is why paths are often quite long after a while, because they encode a lot of history.
Paths. A Path is nothing more than a list of integers. It's denoted using curly brackets and semi-colons: {A;B;...;Z}. A Path should never be empty {} or have negative integers {0;-1}, but it is certainly possible to create a path like this and it probably won't even crash Grasshopper. Paths are 'grown' by components that (potentially) create more than one output value for a single input value. For example Divide Curve. It creates N points for every single input curve. In cases like this a new integer is appended to the end of the path.
In the next release the Path logic in Grasshopper is somewhat different. I fixed a number of obscure bugs (hopefully without introducing new fresh bugs) and special cased certain operations to somewhat reduce the speed at which paths grow. This may well break files that rely on a specific tree layout, but I hope the temporary sacrifice will be worth the long-term benefits.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
). It deals with the potential possibility to port GH into AEC fields (real-life AEC fields, nothing to do with academic thinking). The bad news are that the smart AEC sector is occupied solely by Bentley/GenComp – expect soon Revit/Dynamo as well (not to mention CATIA). The good news are that there’s millions of designers/engineers/industrial designers out there who could be interested for a 3rd alternative.
Intro: Well, in the old days (when men had mustache and muttonchops) AEC design performed in a nice top-to-bottom sequence (kinda like a vector) : the Big Man (aka The Brain) did some sketches (with crayons) and the rest (known as the “others”) struggled to make The Idea a reality. Today things are different, mind. Or they should be different. Or may be different. Or whatever. The big easy:For a zillion o reasons (AEC matures, PLM, cost, outsourcing, sustainable engineering…add several more) this vector like process of the past is like a Brown motion these days: Right down the moment that you (or your team) “sketch” The Big Idea … another team design simultaneously (i.e. in parallel) the components (parts) that compose the whole. This is the so called bottom-to-top design mentality. So the whole and the parts meet in some "middle point" instead the later being dictated by the former. In quite a few occasions parts dictate the whole (cost, cost and cost being the main reasons). The more a design is contemporary the more this bottom-to-top thing plays a critical role. Ignore it and have a very big time (sooner or later).The bad news:If you accept the above…well GH – at present phase - is not ready for contemporary AEC work. At.All.3 Main reasons for that:1.You can’t use parametric parts (i.e. nested blocks to speak Rhino language) into a given definition (in this case attached : truss nodes, connection flanges, mount plates, cable tensioners, planar glazing components, roof skin components…etc etc). This is obviously a Rhino domain.2.You can’t bake a given solution in such a way that the Rhino file is structured (i.e. assemblies of nested blocks). Or you can do it theoretically writing some VB/C code – but the core of the matter is that corresponding components are MIA. That means that you can’t export anything useful actually into established AEC oriented apps and/or established MCAD apps (for doing/calculating the parts for real-life production).3.The GH process can’t being interrupted. Imagine defining, say, a building “envelope” in GH and then …er…use Evolute tools in order to optimize things (say quad planarization and the likes). Then …continue in GH for more detailed work. Then design the parts as in 1 above. Then back to Evolute. Then back to GH.So…if anyone is interested I would be glad to start the mother of all debates and/or some kind of crusade (GH for President, that is).PS: This definition is a WIP thing – more refined stuff to follow (in particular a complex canopy tubes pre-stress system).
PS: Tree8 components are used sporadically.
PS: Use Saved Views
May the Dark Force be with us.Best, Peter …
shopper later uses but for the life of me cannot see the problem.
Component
using System;using System.Collections.Generic;using Grasshopper.Kernel;using Rhino.Geometry;namespace Load_Take_Down_Tool.Components{ // This componenet takes care of creating ordered lists to pass to the column component // Searches for points within tributary areas public class Column_Organiser : GH_Component { /// <summary> /// Initializes a new instance of the Column_Organiser class. /// </summary> public Column_Organiser() : base("Column Organiser", "CO", "Orders lists of points and areas", "Load Take Down Tool", "Pre-Processing") { } /// <summary> /// Registers all the input parameters for this component. /// </summary> protected override void RegisterInputParams(GH_Component.GH_InputParamManager pManager) { pManager.AddPointParameter("Column", "C", "Unsorted points at location of column (required)", GH_ParamAccess.list); pManager.AddBrepParameter("Tributary Area", "T", "Unsorted tributary areas for column (required)", GH_ParamAccess.list); } /// <summary> /// Registers all the output parameters for this component. /// </summary> protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager) { pManager.AddPointParameter("Column", "C", "Sorted points at location of column", GH_ParamAccess.list); pManager.AddBrepParameter("Tributary Area", "T", "Sorted tributary areas for column", GH_ParamAccess.list); pManager.AddPointParameter("Failing Points", "FP", "Points that are not within any tributary area", GH_ParamAccess.list); } /// <summary> /// This is the method that actually does the work. /// </summary> /// <param name="DA">The DA object is used to retrieve from inputs and store in outputs.</param> protected override void SolveInstance(IGH_DataAccess DA) { //Declare lists to hold data //uo = un-ordered //o = ordered List<Point3d> uocolumnpoints = new List<Point3d>(); List<Brep> uotribareas = new List<Brep>(); List<Point3d> failpoints = new List<Point3d>(); //Get data from inputs if (!DA.GetDataList(0, uocolumnpoints)) return; if (!DA.GetDataList(1, uotribareas)) return; //Error if number of points and areas are not equal if (uocolumnpoints.Count != uotribareas.Count) { AddRuntimeMessage(GH_RuntimeMessageLevel.Warning, "Unequal number of columns and tributary areas"); return; } List<Point3d> ocolumnpoints = new List<Point3d>(); List<Curve> ocurves = new List<Curve>(); List<Brep> otribareas = new List<Brep>(); double m_tol = 0.001; string unitSystem = Rhino.RhinoDoc.ActiveDoc.GetUnitSystemName(true, true, true, true); if (unitSystem == "m") m_tol = 0.000001; if (unitSystem == "mm") m_tol = 0.011; PointsInsideCurves pic = new PointsInsideCurves(); try { pic = new PointsInsideCurves(uocolumnpoints, uotribareas, m_tol); } catch (Exception ex) { AddRuntimeMessage(GH_RuntimeMessageLevel.Remark, ex.Message); } failpoints = pic.FailedPoints; ocurves = pic.OrganisedCurves; if (failpoints.Count > 0) AddRuntimeMessage(GH_RuntimeMessageLevel.Remark, "Some point(s) did not lie within a tributary area, were on the boundary/tolerance limit of of a tributary area, or multiple points were within the same tributary area. See output FP for the points that have failed"); foreach (Curve c in ocurves) { Brep b = Brep.TryConvertBrep(c); otribareas.Add(b); } //Pass data to outputs DA.SetDataList(0, ocolumnpoints); DA.SetDataList(1, otribareas); DA.SetDataList(2, failpoints); } //Grasshopper icon for component protected override System.Drawing.Bitmap Icon { get { return Properties.Resources.ColumnOrganiser; } } /// <summary> /// Gets the unique ID for this component. Do not change this ID after release. /// </summary> public override Guid ComponentGuid { get { return new Guid("{3259e465-5400-48e3-907b-fcb7455b12aa}"); } } }}
Helper class
using System;using System.Collections.Generic;using System.Linq;using System.Text;using Rhino.Geometry;namespace Load_Take_Down_Tool{ class PointsInsideCurves { private List<Point3d> Points { get; set; } private List<Curve> ClosedCurves { get; set; } private double Tolerance { get; set; } public List<Point3d> FailedPoints { get; set; } public List<Curve> OrganisedCurves { get; set; } public PointsInsideCurves() { } public PointsInsideCurves(List<Point3d> Points, List<Curve> ClosedCurves, double Tolerance) { this.Points = Points; this.ClosedCurves = ClosedCurves; this.Tolerance = Tolerance; Evaluate(); } public PointsInsideCurves(List<Point3d> Points, List<Brep> ClosedBreps, double Tolerance) { this.Points = Points; this.Tolerance = Tolerance; List<Curve> Curves = new List<Curve>(); foreach (Brep b in ClosedBreps) { Curve[] c = b.DuplicateEdgeCurves(); c = Curve.JoinCurves(c, Tolerance); Curves.Add(c[0]); } this.ClosedCurves = Curves; Evaluate(); } private void Evaluate() { //Sorts in order of points //Naive implementation //Can update to KD tree if necessary List<Curve> OrderedCurves = new List<Curve>(); List<Point3d> fPoints = new List<Point3d>(); //Have to duplicate the input list of curves to modify as we go List<Curve> CCDup = this.ClosedCurves; foreach (Point3d Point in this.Points) { //Backwards loop to allow removal bool assigned = false; for (int i = CCDup.Count - 1; i >= 0; i--) { if (CCDup[i].IsClosed == false) { throw new Exception("Curve is not closed"); } if (CCDup[i].Contains(Point) == PointContainment.Inside) { OrderedCurves.Add(CCDup[i]); CCDup.RemoveAt(i); assigned = true; break; } } //If point not within any of the given breps put null in the list if (assigned == false) { OrderedCurves.Add(null); fPoints.Add(Point); } } this.FailedPoints = fPoints; this.OrganisedCurves = OrderedCurves; } }}
…
Added by Hugh Groves at 3:43am on September 30, 2014
looked at autodesk simulation cfd 2015 and was optimistic because it had an export plugin from revit, which i use anyway for material takeoffs and etc, but found that it did not take solar radiation into account. This was a downer because I have heard that solar radiation could effect indoor airflow - convection - as much as 50 percent at a time.
Then I searched again and found that Hyperworks, a software by altair technology can be coupled with a radiation software. So I went through the trouble of obtaining an educational license of Hyperworks. However, though some email exchange I have found that the coupling is a one-way. The radiation analysis software was used, I think, for understanding the solar loading for a SOM project called church of light.
The support guy said : "Unfortunately our coupling with Hyperworks is really a one way coupling. We can accept H coefficients from their software in RadTherm, but they will not read in our wall temps. That said, it still can be a useful coupling in the sense that you can run the analysis in Hyperworks, send H coefficients to RadTherm, and run the analysis to better understand radiation and conduction. Most importantly, that analysis can be done for longer transient analysis, but will require much less compute time and resources."
Not only did I not understand what he means by the H coefficients, my wanting to get a CFD understanding coupled with solar radiation was again, unsatisfied. In the mean while I had to finish a presentation so I haven't had the time to try to get some result on the natural ventilation. I would probably need to look into how their solutions work before I can understand if their software would "do the job"
Thank you for letting me know about your work on this. I downloaded the Honeybee_Set EP Natural Ventilation component and made sure that it is allowed, but it does not show up in grasshopper.
You pointed out that "The component (and the corresponding equation) is mostly meant for cases where you have zones with windows that are NOT connected by an air wall (or a larger airflow network)." I wondered if you are suggesting it would be a code violation for zones to be connected by an air wall for fire safety reasons. It would be a violation I guess, like not putting an fiber insulation or some kind of smoke stop between Spandrel panels and the edge of a floor plate would be a code violation for a typical office building.
There is a project by kevin daly architects where you can see a section drawing with what seems like a cfd analysis (could be an illustration)
it was my initial visualization/simulation goals were for a facade design I am working on
1) an average air velocity across a zone at noon, for example, if a passive design strategy like this was used. for this I am guessing cfd is not entirely necessary. probably means that it could be used earlier in a design process, too. This would be more about user comfort.
2) at a later phase, like in detailing facade components, if airflow is indeed as expected for a zone that is connected to an air wall / chimney like feature (and to see if there is a proper mixing of air)
3) and a projection of energy savings, of course.
After seeing a video of simulation cfd I was optimistic, but like I said sim cfd does not take account of solar loading. I think I would probably go ahead start with one zone with sim cfd first, try three zones stacked on top of each other, then try hyperworks and try to factor in solar radiation.
For analyzing multiple zones on different levels, being able to add a chimney would be especially useful, I think. Having said that, I don't have a lot of experience of using honeybee except for the daylight component so it would take some time for me to understand the components.
I hope some of the information here is useful for you. after all, both sim cfd and hyperworks are commercial softwares and somewhat different than the e plus project you are working on, I guess but still trying to address a similar problem.
so.. in cased you missed it I was asking I downloaded the Honeybee_Set EP Natural Ventilation component and made sure that it is allowed and placed in the user object foler, but it does not show up in grasshopper. what could be the reason?
…
Analysis Tools (LAT). Our plugin has come a long way in the last 4 years and, while the legacy version will still include some small updates and contributions, we are confident in saying that the changes will be far fewer and the plugin more stable in the following months as we switch gears into the LAT effort. I can say personally that (save for a couple of small capabilities) I have made it through my list of critical features and I will hereafter be working on making these features cross-platform, cleanly-implemented, and well-documented in the new Ladybug Analysis Tools software package. As always, you can download the new release from Food4Rhino. Make sure to remove the older version of Ladybug and Honeybee and update your scripts.
The majority of changes with this release represent “icing on the cake” after a long, multi-year effort to connect to the major open source engines and datasets. So, without further adieu, here is the list of the new capabilities added with this release:
LADYBUG
Stereographic Sky Projections - Thanks to several code contributions from Byron Mardas, all Ladybug sky visualizations now support stereographic projections! Such projections are useful for understanding the hemispherical visualizations in a 2D format and they also make it easier to overlay different sky datasets on top of one another. Check here for an example file showing the sun path overlaid with helpful/harmful parts of the sky and see here for an example file using shading masks representing strategies (like an overhang) on top of the helpful / harmful portions of the sun path.
Wind Rose Upgrades - Devang Chauhan has added several new features to the Ladybug wind rose including both visual and numerical outputs of average wind velocity and frequency for each petal of the rose. Not only does this enhance the usefulness of the rose but it also paves the way for the use of the wind rose to set up CFD simulations once Butterfly is released in the near future. The new features of the wind rose can be seen in this hydra example file.
Complete Set of Local Thermal Discomfort Models - After the last release included components to evaluate radiant asymmetry discomfort (which can be modeled using these example files: 1, 2), today’s release completes Ladybug’s suite of local discomfort models from ASHRAE and the ISO by adding components to account for discomfort from cold draft. Specifically, two draft models have been added for different types of situations. The first is an older model published by P.O. Fanger, which was developed through experiments where subjects had cold air blown on the back of their neck (the most sensitive part of the body to draft). While this is useful for understanding a worst-case scenario, it can greatly overestimate the discomfort for cases of draft at ankle level - a more common occurrence that typically results from the tendency of cold air to sink. For this situation, a second draft discomfort model has been included, which is specifically meant to forecast ankle draft discomfort. The model is currently undergoing review for integration into ASHRAE-55 and a publication outlining the derivation of this model can be found here:
Liu, S., Schiavon, S., Kabanshi, A. and Nazaroff, W. (2016), Predicted Percentage Dissatisfied with Ankle Draft. Indoor Air. Accepted Author Manuscript. doi:10.1111/ina.12364 (http://escholarship.org/uc/item/9076254n).
Special thanks is due to Shichao Liu, Toby Cheung and Stefano Schiavon for sharing the model and the results of their study with the development team. The integration of draft models completes the full integration of ASHRAE-55 and EN-15251 with Ladybug. Now, you can rest assured that, if there is a certain thermal comfort standard that you need to fulfill for a given project, you can model it with the ‘bug!
Window-Based Draft Model - With the integration of draft models, the first question that one might ask is “how should these models be applied to typical design cases?” While the (soon-to-be-released) Butterfly plugin for OpenFOAM should open up a Pandora’s box of possible situations, this release of Ladybug includes a simplified downdraft model from cold vertical surfaces, which helps model several typical cases of draft discomfort. The model has been validated across several papers:
Heiselberg, P. (1994). Draught Risk From Cold Vertical Surfaces. Building and Environment, Vol 29, No. 3, 297-301
Manz, H. and Frank, T. (2003). Analysis of Thermal Comfort near Cold Vertical Surfaces by Means of Computational Fluid Dynamics. Indoor Built Environment. 13: 233-242
It has been built into the “Ladybug_Downdraft Velocity” component and has been included in an example file illustrating discomfort from cold windows in winter. The example is intended to show when glazing ratio and window U-Values are small enough to eliminate perimeter heating - a practice that is aesthetically unpleasing, costly to maintain and wasteful in its energy use.
Operative Temperature on the Psychrometric Chart - This is a feature that should have been added a long time ago but we are finally happy to say that the Ladybug_Psychrometric Chart can draw a comfort polygon assuming that the air temperature and radiant temperature are the same value (aka. an operative temperature psychrometric chart). This operative temperature chart is the format that is needed to use the ASHRAE-55 graphical method and is generally a better representation of the range of comfort in cases where one does not intend to hold the radiant temperature constant. This operative temperature capability is now set as the default on the component but you can, of course, still bring back the older comfort polygon by simply plugging in a value for meanRadiantTemperature_.
Contour Map Visualizations - Using the same inputs as the Ladybug_Recolor Mesh component, the new Ladybug_Contour Mesh component allows you to generate contoured color graphics from the results of any analysis. Now, you to maximize the use of your high-resolution studies with contours that highlight thresholds and gradients!
Image Texture Mapping for Colored Meshes - Antonello DiNunzio has added the very useful Ladybug_Texture Maker component, which allows you to bake Ladybug colored meshes with image texture maps (as opposed to the classic method that used colored vertices). This enables the creation of transparent Ladybug meshes, making it even easier to overlay Ladybug graphics with one another and with Rhino geometry:
This component also adds the ability to render Ladybug + Honeybee meshes with other rendering programs like V-Ray and 3ds Max. So you can produce Ladybug graphics like this!
Finally, image-mapped textures are also the format required for gaming and Virtual Reality software like Unity and Augmented Reality programs like Augment. So now you can export your Ladybug meshes all of the way to the virtual world!
Rhino Sun Component - If you have ever had to set up the sun for a rendering plugin and wished that you could just take your Ladybug sun and use that, then you are in luck! Byron Mardas has contributed a component that lets you set the Rhino sun based on your EPW location data, your north direction (if different from the Y-Axis) and any time of day that you want. Not only does this make it easier to coordinate the Rhino sun with your Ladybug visualizations, but you can also use it for real time shadow previews by setting your Rhino view to “Rendered” and scrolling through a slider.
Rendered Ladybug Animations - With both the image texture mapping and the Rhino sun components released, your first thought might be “it would be great if I could use this all in a rendered animation!” Thankfully, Ladybug has added a new component to help you here. The Ladybug_Render View component works in essentially the same way as the Capture View component, allowing you to make a series of images as you animate through a slider. The major benefit here is that it works with both Rhino Render and V-Ray so that animations like this can be produced effortlessly:
Cone of Vision Added - Antonello Di Nunzio has added a component that allows you to visualize various cones of vision in order to help inform your view studies. You can fine tune parameters to include just text-readable or full peripheral vision and use the resulting view cone to constrict the results of your “Ladybug_View Analysis” studies.
Terrain WIP Components Released as the Gismo Plugin - Our friend Djordje has released a new plugin Gismo - a plugin for GIS environmental analysis. As a result the following 5 terrain components: Horizon Angles, Flow Paths, Terrain Shading Mask, Terrain Generator 2, Terrain Analysis, have been removed from Ladybug+Honeybee's WIP section and are added to Gismo.
HONEYBEE
Search, Select, and Import the Hundreds Outputs from EnergyPlus/OpenStudio - Many of the power users in our community know that EnergyPlus is capable of writing several hundred different outputs from the simulation (well beyond what the basic Honeybee result readers can import). While Honeybee has always allowed one to request these outputs by adding them to the simulationOutputs_ of the component, there has not been an official workflow for searching through all of the possible outputs or importing their specific results… until now! We have added the "Honeybee_Read Result Dictionary" component, which allows you to parse the Result Data Dictionary (or .rrd file) that EnergyPlus outputs during every run of a given model. This allows you to see all of the outputs that are available for the model and you can even search through this list to find a particular output that you are interested in. Once you find what you are looking for, simply copy the text output from the component into a panel and and plug this into simulationOutputs_. Then you can use the "Honeybee_Read EP Custom Result" component to bring your custom results into GH after rerunning the simulation. The example file of an evaporative cooling tower shows how to use the workflow to request and import in the energy removed by the tower.
OpenStudio HVAC System Sizing Results - After the full integration of HVAC in the last release, we realized that a number of people wanted to run EnergyPlus models simply to evaluate the size of the Heating/Cooling system in the model (obtained from the EnergyPlus autosize calculation that is run at the start of every simulation). Such a sizing calculation can be a great way to quantify the anticipated savings from a given strategy (like shading) on the size/cost of the building’s HVAC system. To get the results of the sizing calculation, all that one needs to do is connect the output eioFile from the OpenStudio component to the Honeybee_Read HVAC Sizing component. The outputs will indicate the peak heating/cooling loads of each zone (in Watts) as well as the size of each piece of HVAC equipment in the model. The next time that you are on a project that is about to value-engineer out an exterior shading system, use the workflow in the following example file to show that the client will probably end up paying for it with a more expensive HVAC system: Quantifying HVAC Sizing Impact of Shade.
Improved Memory Usage When Building Large Energy Models - As we take the capabilities of Honeybee to larger and larger models, many of us have begun to run up against a particular limitation of our machines: memory. After upgrading our machines to have 32 GBs of RAM, there was only one way left to alleviate the problem: restructure some of the code. Honeybee now uses an enhanced approach that ensures all the previous iterations of Honeybee objects will be removed from the memory once there is a change. In any case, the considerations of memory are definitely something that we intend to improve with the future Honeybee[+] plugin.
Workflow to Import gbXML Files - While GrizzlyBear has been around for several years, enabling us to export Honeybee zones to gbXML, we have gone for quite some time without a workflow to import gbXML files to Honeybee. The new Honeybee_gbXML to Honeybee component addresses this and establishes an easier path to import models from Revit into honeybee. You can read more about the component in this post.
Window Frame Capabilities Added to OpenStudio - After the implementation of LBNL THERM / WINDOW capabilities in the last two releases, there was one final bridge to build in the Honeybee workflow - fully connecting LBNL WINDOW to Honeybee’s OpenStudio workflow. This release of Honeybee will now write all FrameAndDivider objects exported from LBNL WINDOW glazing systems into the energy simulation, enabling you to account for the frame’s thermal bridging effects. As long as the construction is brought in with the Honeybee_Import WINDOW IDF Report component, the frames associated with the construction will be assigned to all windows that have the construction. Finally, it is worth noting that the current Honeybee will also write all glass spectral data as well as gas (or gas mixture) materials into the simulation. This means that essentially all properties of any IDF export that one makes from LBNL WINDOW can be factored into the OpenStudio energy simulation (with the only exception being BSDF materials).
OpenStudio Daylight Sensors Added - In our previous releases of Honeybee, the only means of correctly account for daylight sensors in an energy simulation was to run an annual daylight simulation and use the resulting schedules for the lighting in the energy simulation. However, this can take a lot of time and work to set up and run, particularly if the daylight control (at the end of the day) will be driven by just one sensor per room. Now, we have added another option, which uses OpenStudio/EnergyPlus’s built-in daylight controls. You can assign just a point and an illuminance target on the “Set Zone Thresholds” component and the lighting will be automatically adjusted in the course of the simulation. It should also be noted that the addition of daylight sensors has also coincided with the addition of blind/shade control based on glare. The same sensor point for daylight can be used to drive dynamic shades in the energy simulation based on glare experienced at this point. This example file shows how to set up daylight controls on the EnergyPlus model and check the lighting power results to see the effect.
Better Defaults for Natural Ventilation - After many good people wrote to me informing me that Honeybee overestimates natural ventilation airflow and I wrote back showing the way that I intended natural ventilation to be set up with the component, it dawned on me that I had selected some poor component defaults. Accordingly, this release includes a window-based natural ventilation option on the Set EP Airflow component that corrects for some of the common issues that I have seen. Insect screens are included by default and the component runs a general check to see if wind-driven cross ventilation is possible before auto-assigning it. The component will air on the side of more-conservative, lower airflow rates unless the user overrides the defaults. Finally, it’s worth noting that all of these changes have not affected the freedom of the Custom WindAndStack option on the component. The new defaults can be viewed in this example file.
CFD Results Can be Plugged into Microclimate Maps - In preparation for the (very soon) release of the Butterfly that connects to the OpenFOAM CFD platform, we just wanted to note that all of the microclimate map recipes can now take an input of a csv file with a matrix of CFD results for wind speed. For the time being, we have used these to produce very high-accuracy, high resolution maps of outdoor comfort. There will be more to follow soon!
We should also note that, in the last release I mentioned that we would be phasing out the EnergyPlus component so that all efforts are focused on the OpenStudio component. While I reiterate that all of the features of the EnergyPlus component are available in the OpenStudio component and I encourage everyone to use the OpenStudio component in order to take advantage of its HVAC capabilities, I have come to realize that many prefer to use the EnergyPlus component out of habit and have not yet gotten the time to understand why the OpenStudio component is an improvement over the EnergyPlus component. As a result, we have decided to leave the EnergyPlus component in place for the time being so that everyone has more time to understand this. The future Ladybug Analysis Tools platform will only interact with EnergyPlus through OpenStudio and so it is recommended that everyone use these two components in the Honeybee plugin will serve as an educational resource to understand our current path moving forward with OpenStudio.
Lastly, it is with great pleasure that we welcome Devang Chauhan and Byron Mardas to the developer team! As mentioned previously Devang has contributed several updates to the Ladybug Wind Rose in addition to finding and solving a multitude of bugs in other components. Byron has contributed code that has enabled the previously-mentioned stereographic sky projections along with a better method for running the Ladybug Sky Mask. Finally, Byron has contributed the Rhino Sun component, which allows you to coordinate your Rhino renders with your Ladybug data. Welcome to the Ladybug team, gentlemen!
As always let us know your comments and suggestions. Cheers!
Ladybug Analysis Tools Development Team…