Great Ladybug Tools Community,
It has been a long time coming but we are excited to finally announce another stable release of Ladybug Tools (LBT) for Grasshopper (version 1.9.0)! This new release is fully functional in Rhino 6 through 8 on both Mac and Windows.
If you’re installing on Windows, you can get the new release by downloading and running the FREE SINGLE-CLICK INSTALLER. All that you have to do is create an account on our Pollination platform and you can download the free Pollination Grasshopper installer, which comes with a copy of the latest version of Ladybug Tools. The single-click installer also includes a compatible copy of Radiance and OpenStudio, which are installed in a way that they won’t interfere with other versions of these engines that you may have on your system. For the Mac aficionados of our community, you will still need to install by downloading the LBT 1.9 installer .gh file from Food4Rhino and following the same instructions as previous releases. Note that using this installation workflow requires you to manually update to the latest compatible version of OpenStudio (version 3.9) listed in the compatibility matrix.
If there is a theme to the new features in this 1.9 stable release, it would be best described as “enhanced ability to work with large models.” Most of you are already aware that we sell a Pollination RHINO PLUGIN, which is fully integrated with all of the LBT 1.9 Grasshopper components. The Rhino plugin streamlines the process of creating, editing and QA/QC’ing large detailed honeybee models by providing a set of Rhino commands for building and editing them. It also comes with a set of Grasshopper components for passing your honeybee models back and forth between Rhino and Grasshopper (complete with all model properties). For anyone wishing to use Ladybug Tools for full building models, the workflow we now recommend is to build the honeybee model with the Rhino plugin and then bring the model into Grasshopper for any custom simulation and analysis.
We also sell a REVIT PLUGIN, which can be installed independently of the Pollination Rhino plugin and the Ladybug Tools Grasshopper plugin but is nevertheless fully integrated with them. The Pollination Revit plugin provides the most streamlined workflow for extracting Honeybee models from Revit and comes complete with a new 2D Model Editor interface that has a suite of commands for quickly cleaning up the common issues that make raw Revit models unsuitable for building simulation. Models can be exported directly to a Honeybee Model file (HBJSON) or Dragonfly Model file (DFJSON) in order to work with them in LBT-Grasshopper.
The influx of new large models from both the Pollination Revit and Rhino plugins has spurred us to add many new LBT Grasshopper features that make it easier to work with them. So, without further ado, let’s dig into the new features!
Ladybug Improvements
LB Samples Component
Many of you were right to remind us that the old Hydrashare platform that we built to share sample files with our legacy plugin was a valuable asset to your workflows. We wanted to make sure that you had a similarly valuable asset with LBT Grasshopper and so LBT 1.9 includes a new LB Samples component, which can pull up any number of sample Grasshopper scripts right into the Grasshopper definition you are working on.
Click to read more
With this release, we have also tried to ensure that all of the legacy hydra samples that we had been regularly maintaining now have an equivalent LBT sample file that can be accessed through the LB Samples component. Granted, some samples (like those for THERM or Radiance electric lighting) will not have an equivalent for LBT-Grasshopper until we find a way to support the larger feature set but, if there are any missing samples that you feel should be included and don’t rely on missing features, just let us know and we will be happy to add them.
Export Visualization Sets to SVG
Many of you are already aware of the features offered by Ladybug Tools Visualization Sets as noted in our previous releases. We are happy to add yet another feature to the list with the LBT 1.9 release, which is that any Visualization Set that you create with LBT Grasshopper can now be exported to an SVG file. The new capability is available through the LB Dump VisualizationSet component, which now has an option for “SVG” under the _format_ input. There are also several new options that help customize the dimensions of the SVG, the view to use for the SVG (which is distinct from the Rhino views), and how the legend should display. All SVGs output can be opened in a browser and hovering over any parts of a colored analysis geometry will reveal the value associated with that color like so:
Click to read more
Some examples of SVGs exported for visualization sets of different types of ladybug graphics can be found below. Right-click and open them in their own browser tab to experience the hover/interactivity. We hope that this helps share your Ladybug graphics in a way that is more meaningful to your coworkers and clients.
Color Blind Friendly Options
While we have always let you customize the colors of Ladybug Tools graphics to be anything you want, we are long overdue in adding options to the standard color schemes in the LB Color Range component that are designed to be color blind friendly. So, with this release, we are happy to add 3 new color schemes aimed at addressing this, which, in full transparency, were taken directly from the “Sequential Colormaps” section of the Wikipedia page on color blindness. The three new schemes can be seen in flood plots below and thanks goes to Alejandra Menchaca and Andy Berres for bringing this to our attention as part of their work with project stasio.
Honeybee Improvements
Support for Zones
Historically, Honeybee has only ever supported simulating each Room as its own zone in energy simulation. This was in spite of the fact that many real-world buildings serve multiple rooms with a single thermostat, meaning honeybee models were not the best representation of these buildings. Furthermore, OpenStudio has always supported a distinction between the Room (aka. Space) and the Zone (aka. ThermalZone), EnergyPlus has supported it since 2021, and many of the other engines that LBT connects to with gbXML rely on grouping rooms into zones to perform calculations of large buildings in a timely manner. So we are happy to finally announce that LBT 1.9 includes full support for zones as distinct from Honeybee Rooms. Those of you worried about the impact on your existing scripts will be happy to know that the default behavior assumes each room is its own zone, ensuring that there are no breaking changes to any existing scripts or workflows. However, those wishing to make use of the new capability will find a new HB Set Zone component that can be used to assign a zone name to rooms. Once this is done, this will cause energy simulation results to be reported for the zone rather than the rooms like so:
There is also a new HB Automatic Zoning component that can automatically group rooms together that share a common floor level, orientation, and program. This can be used to quickly convert models with lots of Rooms and slow simulation times into a version that will simulate much faster with more manageable levels of simulation results.
Select Rooms/Faces by Attribute Filter Room Results
While grouping rooms to zones can reduce the number of data collections coming out of an energy simulation, large models will still have a lot of them, which makes it difficult to check the simulation results of small groups of rooms. For this reason, we have added a new HB Filter Room Result component that helps you filter the data collections coming from an energy simulation according to the rooms they relate to.
Click to read more
As the screenshot above demonstrates, the HB Rooms by Attribute component has also been updated with a new value_ input, which allows you to get only Rooms with the attribute set to a specific value out of the components. The HB Faces by Attribute has a similar new input. Together, these updates should make it much more manageable to perform focused analyses on large models with lots of geometry.
Simplify, Clean, Offset and Repair Apertures
When trying to simulate large models in reasonable timeframes, the next step after consolidating rooms into zones is often the simplification of window geometry in a manner that preserves the total area of glass facing each orientation. For this purpose, we have added a new HB Simplify Apertures component, which can perform the two most common types of simplifications that improve energy simulation performance without compromising results. By default, the component simplifies apertures into a single window per wall with an area that matches the existing window geometry. However, this changes the placement of windows (making it unsuitable for daylight or thermal mapping) so, alternatively, a merge_dist_ can be specified in order to simplify the windows by merging windows together that lie within the specified merge distance of one another. This is particularly useful for cases with models from Revit, where each and every glass lite will often be represented with a separate family instance. So a model can be simplified to the following, which will simulate much faster in energy simulation engines
Click to read more
Keeping in the spirit of these improvements, there is also a new HB Offset Aperture Edges component, which is meant to assist with cleaning up windows where the window geometry includes the frame when it is not supposed to (or vice versa). This makes it possible to work with window geometry from different sources with different levels of cleanliness and format it so that it conforms to what is needed for simulation. Furthermore, the HB Add Subface component has also been updated to include a new input for “projection distance,” which can be used to handle aperture geometries that are not perfectly coplanar with the parent wall. This is particularly useful for handling window geometry from design models, which rarely have the windows coplanar with parent walls as is needed for energy simulation.
Validate Models by Destination Engine
Honeybee has always supported at least two simulation engines to which models can be exported - EnergyPlus and Radiance. But the family of engines has been growing with the Pollination plugins, which connect to IES-VE, eQuest, DesignBuilder, TRACE, and more. So the HB Validate Model and DF Validate Model components have been updated with an option for extension_, which can be used to specify the destination engine. The pact still stands that, if your model validates for a specific engine, it will simulate in that engine without issues. If, for whatever reason, it does not you have found a bug and we will fix it if you let us know.
Load Balance Supports Conduction by Face Type
While this is a relatively minor improvement that normally wouldn’t merit its own bullet point in release notes, load balances are so essential to understanding energy simulation results that we felt it was worth highlighting. It is now possible to get conduction terms separated by walls, roofs, and floors by using a new detailed_faces_ option on the HB Thermal Load Balance component. The new option not only separates the conduction terms but also separates the storage terms such that it is possible to see how much heat energy is being stored in floor slabs vs. walls vs. the interior air mass. The situation where this new capability is most apparent is in observing load balances over summer design days where the thermal mass provided by interior floor slabs (and conduction of heat into slabs on grade) contributes significantly to reducing peak cooling demand:
Dragonfly Improvements
Greatly Improved Automatic Core/Perimeter Workflows
The LBT 1.9 stable release includes a complete refactor of the methods that are used to generate core/perimeter rooms in both the Dragonfly “Create” components and in the HB Striaght Skeleton component. Previously, it was relatively easy to make concave shapes that would cause a failure of the core/perimeter methods - not because of anything flawed with the mathematical proof that every polygon has a straight skeleton but because practical algorithms to compute straight skeletons are notoriously difficult to write. With no algorithm of the past 3 decades proven beyond doubt to return a valid straight skeleton for every possible input geometry, we opted for an approach that catches all cases of imperfect skeletons and cleans them into something useful for performing core/perimeter zoning. With the new algorithm in LBT 1.9, you are pretty much guaranteed to get something useful for energy simulation, even if it is derived from an approximation of the straight skeleton rather than the true mathematical skeleton. This means that the full range of perimeter depths is supported for effectively all shapes:
And you should feel free to plug in perimeter depths for your large complex urban models with the assurance that core/perimeter zones will get generated for all of them:
To handle the fact that building geometries with curved edges tend to produce impractical zoning schemes with too many perimeter polygons, we have added a new component called DF Join Small Rooms, that can merge these small polygons together. For particularly curvy buildings, this will often reduce the number of rooms in the energy simulation by a factor of 3 or more - speeding up the energy simulation while still capturing the meaningful differences that happen across perimeter zones.
Streamlined Workflows for Sloped Roofs, Plenums, and Basement
Much like the core/perimeter generation, the dragonfly algorithms for sloped roofs also underwent a ground-up refactor such that any roof geometry that you apply to your Buildings with the DF Apply Roof component should now shape the rooms into closed solids. You no longer need to worry about overlaps between roof geometries in plan when using sloped roofs since all of these overlaps are resolved in the translation of dragonfly models to honeybee. Together, these capabilities can be leveraged to represent fairly complex building geometries without having to resort to using Honeybee with its lack of abstraction.
Click to read more
Furthermore, plenum assignment now happens in a much more streamlined manner without the need to specify different floor-to-ceiling heights for rooms with plenums. This is accomplished with a new DF Set Plenums component that allows you to plug in any dragonfly object (Room2D, Story, Building or Model) and assign ceiling and/or floor plenum depths. The plenum rooms are automatically split off from the base Room2D to which the plenum depths are assigned upon translation to 3D. Lastly, there is a new DF Make Basements component that enables you to set a given number of stories to have ground boundary conditions.
Ground Heat Exchanger Sizing with GHEDesigner
Born out of NREL’s continued work on the GHEDesigner Python package and the 2024 SimBuild hackathon, we are happy to offer a new DF GHE Designer component that can autosize vertical borehole fields of ground heat exchangers given site geometry and time series data collections of building heating + cooling loads. The component is supported by a set of 6 other new components under the Dragonfly District Thermal section, which help customize various different parameters of the sizing calculation. The results of the sizing can be visualized as borehole geometry in the Rhino scene and outputs like the g-function can be fed into Ironbug components to estimate energy savings associated with Ground Heat Pump systems.
Those looking to test out the new workflow should see the new ghe_sizing_with_gshp_energy_sim.gh sample file, which sizes a ground heat exchanger for a small building and feeds the result into an energyplus model of that building. Special thanks goes to the team at NREL, especially Matt Mitchell for the continued work on the open source GHEDesigner package. Thanks is also due to @victorbrac for walking @mingbopeng and I through the complexities of his ground heat exchanger sizing workflow in order to be able to build these new components for the 2024 Simbuild hackathon.
More Modelica-Based District Energy Systems (DES)
While Modelica DES systems were mentioned in the 1.8 stable release of LBT Grasshopper, there have been a number of major improvements to dragonfly DES workflows since the proof of concept in the last release. New improvements include the ability to bypass EnergyPlus simulation for Modelica DES creation (by assigning custom timeseries loads to dragonfly Buildings), and more. Those wishing to test out the new workflows should look at the dragonfly samples available in the new LB Samples component - specifically those that start with ghe_ and des_.
Features Targeted for the Next Stable Releases
Just for those of you holding out on us porting over the few last capabilities from Legacy to LBT, know that we have not forgotten about the following and we hope to have them in the next stable release:
Solar Hot Water- At this point, effectively all Legacy Honeybee energy simulation capabilities have been ported over to LBT. However, Legacy Ladybug had some components for modeling solar hot water systems that have no equivalent in the LBT plugin. For the next release, we hope to rectify this by incorporating solar hot water into the existing LBT Honeybee Energy Service Hot Water systems, which already do a pretty good job modeling the demand side of hot water usage.
Electric Lighting for Radiance - Many of you keep bringing up the lack of electric lighting in the LBT plugin since it is effectively the only Legacy Radiance capability that has no LBT equivalent. So we hope to add some components and workflows for electric lighting using .ies files in the next release.
C-Factor and F-Factor boundary conditions - This one keeps coming up as the default ground boundary conditions used by Honeybee have a constant temperature and are therefore fairly limited. So we hope to implement C- and F-factor conditions for the next release as a first step towards more advanced ground boundary conditions.
