Honeybee.0.0.62

Release note

Read full release notes here.

Support for OpenStudio 2.x - A few months ago, the National Renewable Energy Lab (NREL) released a stable version of OpenStudio version 2, which included a number of improvements in stability and available features. This stable release of Honeybee is built to work with the new version of OpenStudio and, in the coming months, Honeybee will be adding a few more capabilities to its OpenStudio workflows to support v2.x’s new capabilities. Most notable among these will be support for OpenStudio measures. Measures are short scripts written in Ruby using OpenStudio’s SDK to quickly edit and change OpenStudio models. They are fundamental to visions of OpenStudio as a flexible energy modeling interface and to Honeybee’s goals of being a collaborative interface between the architectural and engineering industries. Stay tuned for the next release for many of these new capabilities!

Critical Memory Issue Fixed for Large Energy Models - A number of you wonderful members of our community have been aware of computer memory issues with large Honeybee models for some time (examples: 1, 2, 3, 4). Namely, a model that is larger than 50 zones could quickly eat up 16 GBs of memory and change Honeybee from a fast-flying insect to something more reminiscent of a snail. We are happy to say that, after a much longer time than it should have taken us, we finally identified and fixed the issue. In this version of Honeybee, such large models can now be created using less than 2% of the memory and time previously. Thanks to all of you who made us aware of this and hopefully you will now reap the rewards of your struggle.

Split Building Mass Component Getting a Makeover - Many of you veteran Ladybug users will recognize Saeran Vasathakumar as one of the original contributors of Ladybug who added components for solar fans and envelopes years ago. Now he’s back with new components to split a building mass into zones that are truly revolutionary in their speed and methodology. Saeran has divided the new capabilities into two components (one for floor-by-floor subdivision and another for core-perimeter subdivision) and they both can be found under the WIP section of this release. In this WIP version, core-perimeter thermal zones can only be generated for all convex and very simple concave geometries. Most concave geometries and geometries with holes (or courtyards) in them will fail. However it can handle even very complex convex geometries with speed and ease. You can expect the component to start accommodating concave/courtyard geometries very soon.

Load / Dump HB Objects to File - Keeping in line with the support of large, full building energy models, this release includes full support for two components that can dump and load any HBObjects to a standalone file. All information about HBzones can go into this file including custom constructions, schedules, loads, natural ventilation, shading devices, etc. You can then send the resulting .HB file to someone else and they can load up the same exact zones in another definition. This also makes it possible to have one Grasshopper file for generating the zones and running the simulation and another GH definition to import results and color zones/surfaces with those results, make energy balance graphics, etc.

Write ViewFactorInfo to File - After many of you asked for it, the _viewFactorInfo that is output from the “Honeybee_View Factor” component can now be written out to an external file using the same Load / Dump HB Objects components cited above. For those of you who have worked with the comfort map workflows, you probably already know that calculating these view factors is one of the most time consuming portions of building a microclimate map. Having to re-run this calculation each time you want to open up the Grasshopper script is a nuisance and, thanks to this new capability, you should only have to run it once and then store your results in an external .HB file.

Transform Honeybee Components Modified for Large Model Creation - Many large buildings today are made up of copies of the same rooms repeated over and over again across multiple floors, or along a street, etc. Accordingly, one can imagine that the fastest way to create a full building energy model of such buildings is to simply move and copy the same zones several times. This is what a new set of edits to the Honeybee Transform components is aimed at supporting by allowing one to build a custom set of zones, translate them several times with a Honeybee_Transform component, then solve adjacencies on all zones to make a complete energy model.

Central Plants Available on HVAC Systems - While Honeybee has historically supported the assigning of separate HVAC systems to different groups of zones, each HVAC was always an entirely new system from the ground up. So a building with separate VAV systems for each floor would be modeled with a different chiller and boiler for each floor. While this can be the case sometimes, it is more common to have only one chiller and boiler per building but separate air systems for each floor. The new ‘centralPlant_’ options on the Honeybee coolingDetails and heatingDetails enable you to create this HVAC structure by making a single boiler and chiller for any HVAC systems that have this option toggled on. Furthermore, in the case of VRF systems, you can also centralize the ventilation system, using the grouping of zones around a given HVAC to assign which zone terminals are connected to a given heat pump.

More HVAC Templates Added - As the profession continues to push the industry standard towards lower-energy HVAC systems, Honeybee intends to keep up. In this release, we have included a few more templates for modeling advanced HVAC systems including Radiant Ceilings, Radiant Heated Floors + VAV Cooling, and Two Ground Source Heat Pump (GSHP) systems. Variable Refrigerant Flow (VRF) systems have also gotten a large boost as it is now possible to model these systems with more efficient water-source loops. The next release will include the ability to model central ground source systems that use hydronics for heating cooling delivery.

Run THERM Simulations Directly from Grasshopper - Anyone who has used the THERM workflow in the past likely realized that, while Honeybee can write the THERM file, you would still have to open model in THERM yourself and hit “simulate” to get results. Now that LBNL has started a transition to becoming more open, they have graciously allowed free access for everyone to run THERM from a command line. What this means for Honeybee is that you no longer need to open THERM at all in order to get results and you can now work entirely in Rhino/Grasshopper. This also opens up the possibility of long parametric runs with THERM models since you can now automatically run simulations and collect results as you animate sliders, use galapagos, etc. A special thanks is due to the LBNL team for exposing this feature, including Setphen Selkowitz, Christian Kohler, Charlie Curcija, Eleanor Lee, and Robin Mitchell.

All Options Exposed for THERM Boundary Conditions - To finish off the full implementation of THERM in Honeybee, a final component has been added called “Honeybee_Custom Radiant Environment.” This component completes the access to all boundary condition options that THERM offers, including separate radiant and air temperatures, different view factor models, and the specification of additional heat flux (which is typically used to account for solar radiation).

Improvements to Schedule-Generating Components - Many of you who have watched the Honeybee energy modeling video tutorials have likely gotten in the habit of using CSV schedules for everything. While this is definitely one valid way to work, it is not always the most efficient since simple schedules can be specified much more cleanly to EnergyPlus/OpenStudio and the use of CSVs can also make it difficult to share your energy models (since you have to send CSV files along with the schedules themselves). This release adds two new schedule components that should take care of a lot of cases where CSV schedules were unnecessary. The new “Constant Schedule” component allow you to quickly make a schedule that is set at a single value or a set of constantly repeating 24-hour values. The second component allows you to create “Seasonal Schedules” by connecting “week schedules” from the other schedule components along with analysis periods in which these seek schedules operate. Together, these will hopefully make our schedule-generating habit a bit better as a community.