INSIDER: Ladybug Tools Aim to Take Environmental Analysis to Wider Audience

Ladybug Tools has only been formally a company for a few years now, formed in 2017 by Mostapha Sadeghipour Roudsari and Chris Mackey. But the two have been collaborating on the building environmental simulation and analysis software plugins for several years before that. Ladybug itself is a set of simulation tools that date back to 2013, and from there, Honeybee came next in 2014, and a series of tools would then continue to follow.

Architosh readers may recall Chris Mackey’s name from our 2018 Firm Profile feature on Boston architecture practice Payette, which won the coveted AIA Firm of the Year Award in 2019. Just before the recent holidays, I spoke with both of them about the exciting developments with Ladybug Tools LLC and about the state of computational design in general.

MORE: Bespoke Computational Tools at Payette Drive Unforeseen Values to Firm and Client Alike

Before we jump into the interview, we should acquaint the reader with the full spectrum of software available under the Ladybug Tools company banner. Ladybug Tools started with Ladybug first and we’ll get to that story in a moment in the interview. Ladybug provides an analysis of climate data for its impact on building design. Honeybee goes further to model the inside of the structure by supporting daylight simulations, energy models, and envelope heat flow. Butterfly is aimed at computational fluid dynamic (CFD) simulations, while Dragonfly analyzes large-scale climate phenomena like urban heat island effects. There are a few other tools and planned new “insects”—all their tools are named after them—but these four are the base.

Now that you are familiar with their products, here’s the interesting good news: they are free! These computational design tools, or what we at Architosh often refer to as AAD (algorithms-aided design) tools, are free to download and install and use on your own. You may ask, how does a software company give away all their stuff and manage to feed itself? That’s a great question, and we will get to that because that question is central to perhaps the AAD movement in general and, in particular, has importance to what is happening with a great variety of tools in the AEC market in general.

Let’s get to the interview because there is a lot of important stuff going on at Ladybug Tools.

The Interview

(Anthony Frausto-Robledo) I want to talk briefly about Ladybug Tools and how it came into existence because I think it’s kind of a classic startup story and a not so classic startup story. After all, as a group, you, Chris, and collaborators have been at it for years. Now you are officially moving to provide commercial services, as you mention on your website. What drove that?

(Mostapha)  I created the Ladybug Tools plugins to solve things I needed to solve on a daily basis. Once I released them, they became so popular I needed to change my job in order to keep up with it. I changed my job twice, and then eventually, I realized it was just bigger than something I could handle on the side.

 

 

 

 

We started the company to sell services like consulting around Ladybug Tools. Then last year, we applied for a grant from the Department of Energy (DOE) to develop a cloud service called Pollination Cloud. It became clear that we have reached the limitations of a desktop application and it is time to take the next step forward. The initial goal was to run simulations at scale but it ended up being much more than that. Pollination Cloud is the platform for building, sharing, and executing environmental building simulations. We call it the “GitHub for Building Simulation.”

Now, Chris, you were working at Payette doing some interesting bespoke development at one of the nation’s top architecture firms combining building science and custom software development. Besides wanting to do this full time, what is different about this development than the bespoke development inside a firm?

(Chris)  There is a real difference between developing bespoke solutions for individual projects in a firm like Payette versus what we are providing with Ladybug Tools. (see: Architosh, “Bespoke Computational Tools at Payette Drive Unforeseen Values to Firm and Client Alike,” 5 Feb 2018). A good software ecosystem has a strong foundation, like a strong tree trunk holding up many large branches. The main pitfall of bespoke development, even at a firm like Payette, is that you are so focused on addressing the specific needs of individual projects (the “tree branches”) that you don’t get enough time to make this strong reusable foundation. So, from project to project, teams tend to rebuild code elements that should be ready and deployable. What we want to do here with Ladybug Tools is build this strong trunk.

Speaking of Ladybug Tools, before we jump into Pollination Cloud—the most interesting thing you guys are focused on now—I want to introduce the basics of Ladybug tools to the reader. What do Ladybug and Honeybee do and what are some of the other tools?

(Mostapha) Ladybug is for weather data analysis, the simulations it runs are very simple and it is most useful for building massing studies. As soon as you want to get inside the building that is where Honeybee comes in.

I understand they both do solar radiation analysis and simulation. 

Yes, but when you do radiation analysis in Ladybug it doesn’t include the reflection between surfaces—Honeybee does. Ladybug is for quick studies when you as an architect or engineer don’t know about the materials yet. Honeybee lets you get into those types of details.

People like to see them in order. Like you start with Ladybug, then use Honeybee for daylight, then energy and finally Butterfly when you get closer to the end of the project. I’m fine with that but in reality, the project needs are not linear and questions come up based on project needs. These slides show how a project manager thinks Ladybug Tools will be used and how a design/engineering team uses it during the design process. (images above and below)

What was the [+] Project about, is that about Pollination Cloud?

That was about taking all the code out and rewriting it from scratch to make it easier for contributors to aid in the code development process. It was also about making it cross-platform by separating the geometry dependencies from the core libraries. The core code is now outside of Grasshopper, which means you can use it in other places, including Pollination Cloud.

So you won this grant from the DOE to do this cloud initiative called Pollination Cloud. Great name by the way. Is this bringing Ladybug tools to the web as a web service? 

Thanks! I know people think about it as Ladybug Tools in the cloud but it is not just Ladybug Tools in the cloud. We have a new platform and language agnostic scheme to describe building geometry and properties, so regardless of how you have generated your model, you can just take that model, make automatic edits to it using the CLI+API of our core libraries, run it through any of the simulation engines we support, and get the results. In the future, we want to add better result visualization and analytics but the first step is making sure that everyone has access to building environmental simulations that can run at scale.

 

 

 

 

We have also created a platform-agnostic workflow language: Queenbee (see it on GitHub here). The goal is to write reusable workflows that can be shared between different platforms for execution. This ensures that we create reusable workflows “together” instead of having several half-baked workflows. We started this in Honeybee with the concept of recipes but Queenbee workflows are written in YAML which makes them readable to both programmers and non-programmers. I presented the idea during the last International Radiance Workshop. (see presentation slides here).

(Chris) Our codebase is now portable and we can run on different operating systems including Mac and Linux. Originally it was written using IronPython and could only be run within Rhino on Windows systems but it is now CPython. This means apps we build with this code will be able to run on servers in the cloud and can be made accessible to a wider audience.

So distribution through the Internet extends the democratization process? 

We are moving towards more accessibility. That is the main goal. Similar to what GitHub did for software developers. It’s about developing the right tools for the community of experts to make a “smart room” of people rather than a solitary genius. We have experts in the community helping people over the world and our goal is to make the knowledge of these experts accessible to more people through our tools.

What about the performance and technical benefits of moving your tools to a cloud architecture platform? 

Continued on page 2