Great Ladybug Tools Community,
We are excited to announce yet another release of Ladybug Tools (LBT) for Grasshopper (version 1.7.0)!
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 complete with a copy of the latest version of Ladybug Tools. It also includes a compatible copy of Radiance and OpenStudio, which are installed in a manner so that they won’t interfere with other versions of these engines that you may have on your system. Lastly, for those of you with IT overlords, your department will be happy to know that the installer can be run silently using this command described on the Pollination forum.
Note that we also sell a RHINO PLUGIN as part of the Pollination CAD suite, which includes all of the LBT 1.7 Grasshopper components along with a set of components that fully integrate with Ladybug Tools. The Rhino plugin adds many new capabilities that streamline the process of creating, editing, QA/QC’ing, and exporting Honeybee models to other BEM platforms.
So we recommend testing the trial if you have not already. We’d also like to highlight that we 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 is arguably the only software that can produce a clean, simulate-able energy model geometry directly from a design-document Revit model.
Lastly, for the Mac fans of our community, you will need to install by downloading LBT 1.7 from Food4Rhino and following the same instructions as previous releases. The single-click installers are not yet available for Mac and so Food4Rhino is the only installation pathway. Just note that using this installation workflow requires you update to the latest compatible version of OpenStudio and Radiance listed in the compatibility matrix by uninstalling and reinstalling them.
Now onto the exciting part of all the new features included in version 1.7!
Ladybug Improvements
Adaptive Comfort Chart - Back by popular demand from the Legacy plugin, LBT 1.7 includes a component for the LB Adaptive Comfort Chart. The chart has a few improvements from Legacy including the ability to set custom lower and upper boundaries for both temperature axes and the ability to plot data other than time/frequency for the colored mesh. For example, you can plot the occupancy schedule data on the chart to understand which hours are heavily occupied. This helps understand things like the colder hours in the following studies can likely be ignored given their low occupancy and relative closeness to the comfort polygon but the very hot hours in the second set of charts is a major issue:
A sample file showing how to use the chart with energy simulation results can be found here.
Click to read more
Another improvement is that both the chart and the adaptive comfort model itself have been updated to reflect the latest European standard, which had several changes to the adaptive comfort in its most recent version. The chart also illustrates the stance that the LBT plugin has taken towards hours where the prevailing outdoor temperature is colder or hotter than the recommended ranges of the standard. In this case, the upper and lower ranges of the comfort polygon simply become a fixed lower and upper temperature, which was slightly different than what the legacy plugin did, which tried to use findings from research, which ultimately proved too speculative to be practical.
UTCI Polygon on the Psychrometric Chart and UTCI Parameters - The Adaptive Comfort model isn’t the only thermal comfort index to get some improvements in LBT 1.7 and there are several new features related to UTCI. Some of you may remember all of the way back in the LBT 1.2 release notes that included the psychrometric chart that one of the benefits of having a separate component for the chart itself is the ability to plot different types of polygons on it. So this release includes a LB UTCI Polygon component, which will plot the range of UTCI “No Thermal Stress” along with the other thermal stress categories:
A sample file for the new UTCI Polygon is here and the new component can also be used to understand the impact of criteria like wind and higher radiant temperatures from the sun on UTCI.
Click to read more
LBT 1.7 also includes a new LB UTCI Comfort Parameters component, which can be used to adjust the thresholds of UTCI at which conditions are considered to have cold stress or heat stress. The output of this component can be plugged into any of the components related to UTCI, including the HB UTCI Comfort Map.
Screen-Oriented Text and Custom Legends - After the new Visualization Set capability made a splash in the last release with its head-up-display (HUD) visualizations, we’ve extended some of these HUD capabilities based on popular demand. In particular, we have added a new LB Screen Oriented Text component to produce any screen-oriented text that you want. For example, this can be used to project metrics like spatial daylight autonomy or overall radiation benefit into the Rhino display to complement any detailed visualizations in the scene. Furthermore, the LB Create Legend component has also been updated with at leg_par2d_ input, which should enable you to make a screen-oriented legend for any data set that you create in Grasshopper.
Radiance Improvements
Dynamic Apertures in Annual Daylight Simulation - Ever since the older Honeybee[+] plugin first offered simulation of dynamic windows, we know that many of you have anxiously awaited this capability in LBT. This is why we are very happy to announce that LBT 1.7 has full support for dynamic Apertures in Annual Daylight simulation! Setting up a model with dynamic windows involves assigning HB Dynamic States to a HB Dynamic Aperture Group. These states can include either a modifier for the Aperture (which can be glass, BSDF, etc.) and/or it can include detailed shade geometries such as dynamic blind or louver systems. There is also a HB Automatic Aperture Group component that can auto-generate the groups based on orientation, view factor to the sky, and other criteria. The Annual Daylight simulation will run through each state of each group to find its contribution. Then, after the simulation is run, you can specify an HB Aperture Group Schedule for each dynamic group, which you can plug into any of the annual Results Components to understand the effect of your dynamic apertures on annual daylight metrics, electric lighting schedules, and more! An example file for basic dynamic aperture simulation can be found here and an example using the automatic aperture group component is here.Full credit goes to @mikkel for making this a reality. Over the past 2 years, he put in a lot of the work to not just organize the recipe logic to simulate all of the states but also wrote the numpy-based result parsing methods that make it possible to test different dynamic schedules in real time. You can see a short demo of this real-time testing here:
Click to read more
We should note that the new dynamic apertures are only supported when using the HB Annual Daylight component (with the new enhanced_option as True - the default). While we are working to support dynamic groups on the other two annual components (Imageless Annual Glare and Annual Irradiance), you will currently get a warning if you try to use the dynamic schedules with these results.
Annual Sun Exposure (and LEED Daylight Option 1!) - Computing Annual Sun Exposure (ASE) has been one of the most requested features on this forum. However, we have been reluctant to offer it because we know most of you are asking because of LEED and, until recently, we did not support the dynamic blind states that are needed to model the LEED criteria. Now that this is possible with dynamic apertures, we are happy to say that LBT 1.7 includes a HB Annual Sun Exposure component. This will tell you if you satisfy the basic ASE requirements of LEED, though figuring out the dynamic blind schedule to account for the impact on spatial Daylight Autonomy is still a challenging task. For this reason, OUR POLLINATION PLATFORM HAS A FREE RECIPE YOU CAN USE FOR LEED DAYLIGHT OPTION 1. All that you need to access it is make a free account on Pollination and then you can run as many local simulations with the recipe as you want. The recipe models all aspects of Option 1 and will tell you the number of LEED daylight points that you can get. With the exception of LightStanza, the Pollination recipe is the only application that will compute the ASE and dynamic blind schedules using the enhanced 2-phase method to properly account for direct sun. So this recipe is our final answer to anyone wanting to evaluate LEED daylight points in the Ladybug Tools/Pollination ecosystem. Just note that you’ll want to set up your aperture dynamic groups before you run the LEED recipe using either the new HB Automatic Aperture Group component (or manually using HB Dynamic Aperture Group components if you want full control).
Option to Turn Off Enhanced Annual Daylight Calculation - As you can tell by our description of our LEED Daylight recipe, the enhanced 2-phase calculation in Annual Daylight has a lot of merits to it and there are good reasons to believe that it is required to accurately model direct sun for ASE. However, there is one drawback to it, which is that it takes more time to run. For simple studies of Daylight Autonomy or UDI, it can sometimes represent an extra step. For this reason, the latest version of the HB Annual Daylight component has an enhanced_ Boolean option on it, which can be used to switch between the default enhanced 2-phase method and a simpler 2-phase daylight coefficient calculation with sky patches. Setting this option to False will typically get the annual daylight simulation to run in less than half of the time of the enhanced simulation, giving you more control to customize the accuracy of the simulation to the metric you are trying to compute.
Generate Sensor Grids from Apertures and Faces - Honeybee has always supported automated ways to generate sensor grids from the floors of Rooms. While this is suitable for metrics like Annual Daylight and Daylight Factor, metrics like Radiation and Irradiance are often most useful when they’re evaluated on the facades of buildings. For this reason, LBT 1.7 offers a HB Sensor Grid from Apertures component and a HB Sensor Grid from Faces component that can generate sensor grids along facades for use in these recipes.
Energy Improvements
Apply Detailed Ironbug HVAC Directly To Honeybee Rooms - Many of you are familiar with the Ironbug Plugin by @mingboPeng, which exposes all of the power and customizability of OpenStudio HVAC systems in the Grasshopper environment. The Pollination single-click installers have been shipping with Ironbug for over a year and it has always been possible to apply Ironbug HVAC systems to the .OSM files that were exported from Honeybee. However, this extra postprocessing step often meant extra time to set up and run. More importantly, it meant that Ironbug HVAC were not usable in recipes like the Comfort Mapping components or within Pollination Cloud simulations that take a HBJSON file as input. This changes in the LBT 1.7 release since there is a new HB Detailed HVAC component that allows you to apply Ironbug HVAC systems directly to your Honeybee Rooms and they will automatically be added to the .OSM as part of the translation from Honeybee > OpenStudio. This means Ironbug HVAC can be used in recipes like comfort mapping and they will automatically be saved within any HBJSON files you export from your Model.
Click to read more
We would also like to highlight that Dragonfly Buildings, Stories and Rooms also support the assignment of detailed Ironbug HVAC systems, which can be done using the DF Detailed HVAC component. All credit for both of these features goes to Mingbo, who developed a way to translate the schema of OpenStudio SDK objects into a JSON format.
HVAC Efficiency Standard Automatically Applies All ASHRAE 90.1 Efficiencies - This feature is subtle in its impact on the components but it has major implications for energy modeling capabilities, particularly for ease of compliance with codes and standards. The templated HVAC systems that ship with Ladybug Tools have always had the option to set the _vintage_, which determines the efficiency of some of the large HVAC components like chillers and boilers. However, much of the building code is written with efficiencies determined by the size of HVAC components. For example a fan of size X must have an efficiency of Y. If it is larger, it must have an efficiency of Z. This means that it’s impossible to apply the correct efficiency to certain pieces of equipment without performing a design day simulation and sizing calculation. So that is exactly what the new eff_standard_ on the latest HB Sizing Parameter component does. By providing a building vintage to the eff_standard_ input, the resulting OpenStudio translation process will perform an additional sizing calculation with EnergyPlus, which is then used to set the default efficiencies of all HVAC equipment, including fans, pumps, outdoor air controllers, and more. This significantly increases the translation time to OpenStudio but it means that you can be sure that the Model you are getting is a perfect representation of what the building energy code dictates for the HVAC.
Click to read more
You’ll also find that, particularly for all-air systems, models that pass through this efficiency-setting routine will use significantly less energy in the simulation. It’s also worth noting that this sizing routine can be applied on top of any HVAC system, including custom Ironbug HVAC systems. In this case, only the HVAC components of the system that have specifications dictated by the standard will be changed. All credit for this feature is due to the authors of the OpenStudio Standards Gem, who have worked hard to turn all of the logic of the building energy code into literal Ruby code.
College Building Program Available - Like the previous feature where we have to thank the OpenStudio Standards Gem authors, we also have to thank them for processing the new College Building of the DoE Prototype Building Models into a format that we can use in Ladybug Tools. Thanks to this effort, you can now find that College is an option available in the HB Building Programs component.
Intersect Honeybee Rooms for Matching Adjacency - Honeybee has always included a component to intersect Rhino Brep geometries with one another for matching adjacency but the fact that this component only worked with raw Rhino geometries meant that it had to come first in a Grasshopper script, often limiting how the script could be organized. For this reason, we are happy to report that the HB Intersect Solids component in LBT 1.7 can accept Honeybee Rooms as input, performing the intersection on these geometries and preserving all attributes of the Rooms in the process.
Dragonfly Improvements
Option to Fully Solve Ceiling Adjacency - Historically, each Dragonfly Room could have only one boundary condition for their ceilings (either outdoors or adiabatic for interiors). This often introduced a small amount of error in terms of the exposed outdoor Roof area when two Rooms of different stories did not align in plan. In the LBT 1.7 release, the ceil_adjacency_ option on the DF Model to Honeybee component and the DF Model to GeoJSON have been greatly improved such that this type of mis-match is automatically intersected upon translation so that you will get the correct outdoor roof area. This means that complex building geometric created using the “From Building Solids” workflow can be modeled with the most accurate boundary conditions:
Support for Sloped Roofs and Skylights - Two other major geometry enhancements are support for sloped roofs through the new DF Apply Roof component and support for skylights through a new DF Gridded Skylight Parameters component. Both of these features preserve the fundamental extruded nature of Dragonfly Room geometry but, when the Dragonfly Models are translated into a 3D format for simulation, the floor plate is projected onto the roof geometries instead of simply being moved vertically. Skylights are added after all roof geometry is created. The new capabilities make it possible to model gabled roof geometry with relative ease, making distinct models of single family homes more accurate in particular.
Automatically Process Alleyways and Party Walls - A very common case when constructing mid rise urban blocks involves setting the boundary conditions of the party walls to adiabatic or removing the windows facing the narrow alleys. We’ve made custom scripts for this in the past but decided it was time to support these routines with an official DF Process Alleys component. The component addresses both of these use cases with a separate option for adiabatic such that windows can be removed without changing the outdoor boundary condition. And multiple components can be used in sequence to set adiabatic conditions for buildings at short distances but only remove windows for buildings at longer distances.
Rejoin Rooms to Building - Another very common Dragonfly workflow for customizing the properties of Buildings involves separating Rooms by some criteria (eg. core vs. perimeter or ground floor vs. other floors) and then joining those edited Rooms back together into a Dragonfly Building for simulation. This workflow is straightforward enough when constructing Dragonfly Models starting from individual Rooms but is more work when starting from the DF Building from Solid workflow or the DF Building from Footprint workflow. To make these workflows easier, we have added a DF Rejoin to Building component, which can take Rooms created with these workflows and join them back into the original Building, preserving all attributes of the original Building in the process. This along with the several other enhancements noted above should make it straightforward to build accurate dragonfly models of virtually any urban typology, from low-rise single-family developments all of the way up to downtowns filled with dense skyscrapers.
[BETA] Get Modelica Filed for District Thermal Systems - This last feature is very much in beta but the LBT 1.7 release includes a DF Run Modelica DES component that can write Modelica files URBANopt District Energy Systems (DES) after simulating the it in EnergyPlus/URBANopt. There is currently no way to run the Modelica files from Grasshopper and so the adventurous people wishing to test this will need to run them in Dymola or the OpenModelica Interface. Dymola simulation is much more stable than OpenModelica but Dymola is a paid proprietary software package. LBT 1.7 includes a component for setting up a typical 4th generation DES with a heating and cooling plant and a component for setting up a 5th generation DES with a ground heat exchanger. More on this feature set should be coming in the next release!
Features Targeted for the Next Stable Release
More Ladybug “Analyze Geometry” Components - At this point, practically all Ladybug “Analyze Data” and “Visualize Data” components have made the transition from Legacy to LBT Ladybug. Most missing components are under the “Analyze Geometry” section and we hope to port many of these over from Legacy in the next release.
Photovoltaics for Energy Simulation - Several of you have noted that PV is effectively the only energy simulation feature that Legacy supported which has not made it to LBT. Accordingly, we are targeting to have it implemented before the end of 2023.
Streamlined Mesh-Based Workflows for Radiance - A number of you focused on creating large detailed Radiance models have witnessed your Grasshopper canvas grinding to a halt whenever you plug this geometry into Radiance workflows. Accordingly, the next release should have a dedicated Shade Mesh object within the Honeybee Model schema, which will be translated directly into a Radiance Mesh and will help streamline the process of simulating detailed geometry.
