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

(Mostapha)  It depends on the type of study you are trying to run and it depends on how much you want to pay. In most cases, if you use 100 CPUs, the results are going to come much faster than using 8. I can’t give an exact number but I can tell you that it is going to be several times faster than doing these simulations on the desktop.

 

 

 

 

But here is the key, it is not just about running the simulations faster, it is also about developing the simulations workflows faster and collaborating on developing those workflows in a more optimal way.

You are talking about getting people together to discuss these simulations, about working with engineers and bringing them into the process…

Right. Right now it takes so long for people to collaborate and run these simulations. We are trying to address the collaboration issue with Pollination. For example, the engineer can set up the workflow for a specific project, deploy it to Pollination Cloud, and tell the architect to just send over the data once they are done. It’s about sharing data and not sharing 3D models.

So you said earlier how much you want to pay for, in reference to using Pollination Cloud, the web service. Recap for me how your company generates revenue. 

(Chris)  Well, the core libraries will always be free; the Grasshopper plugins will always be free. You pay for access to the platform for collaboration, reliability, and scalability. You also have to pay more if you want to keep your workflows private. Again, very similar to why people pay for GitHub when it’s free for open-source projects.

Well, I remember Chris that some of your work at Payette used HumanUI to develop more accessible interfaces for people who don’t know visual scripting. What about adding those levels of user interface engagement?

We absolutely plan to support more traditional interfaces that don’t have the learning curve of visual scripting. However, if people are looking for a shortcut to bypass learning curves that our community members have gone through, then this may be an area where we would charge money.

 

 

 

 

Our philosophy is always that, if you are willing to sit down, become an expert, and teach yourself about the advanced parts of the software, then you should never hit a paywall. But, if you want to access advanced capabilities without putting in as much time to learn about them, this might come with a price tag.

I want to ask about your community in a bit, but first, I want to talk about how the [+] Project and Pollination Cloud can get your tools into other places, get your tools into other tools. 

(Mostapha) The [+] Project was about making the codebase more accessible, getting it out of Grasshopper, getting it ready for the cloud, and making it easier to maintain. And one of the issues with it being in Grasshopper is that it doesn’t scale well. For heavy lifting work, we needed to take it outside of Grasshopper. Grasshopper is single-threaded; it doesn’t use multithreading; it’s not easy to scale up.

And the other thing about this effort was making the code much easier to test and maintain, in a Continuous Integration and Continuous Delivery (CI/CD) model, using automated processes to test and deploy code, things that are not easy or even possible to do when all your code is inside a tool like Grasshopper.

While Grasshopper and Rhino are clearly kings of the computational design tools world, it sounds like you can now get your tools into other AAD (algorithms-aided design) platforms, like Bentley Generative Components or Vectorworks’ Marionette. 

It is. We have endpoints that you can call from any of these tools. We have SDKs in different languages. Even if you don’t want to use our cloud solutions, we have a library that enables you to utilize your own geometry layer, and the rest of the tools can run regardless of the platform you are on. (see image below).

It sounds like you are building up a good API or that strong trunk in the tree analogy from which to distribute and democratize these tools. 

(Chris) Yes, and we take a lot of inspiration from other software that we feel has been developed correctly like Rhino itself. They have this strong API, this sturdy and robust foundation and, as a result, they have a thriving and expanding ecosystem of plugins and applications around it.

And speaking of expansion, when is Pollination Cloud going to be ready? And what are your plans for expanding your tools—any more bugs?

(Mostapha) The endpoints are planned for the end of the first quarter of 2020. And then in the second quarter of 2020, we will release plugins for Grasshopper. We will support daylight analysis and energy analysis first, and then we will decide if we add comfort or CFD to Pollination Cloud next.

(Chris) We are interested in inserting a couple of new insects in the future.

Getting back to the community…how big is your user base, and has your user base changed? 

(Chris) We have approximately 60,000 unique email addresses in our user base and a few thousand in our active community. Historically, we had many more architects and consultants than engineers, but this has changed. People in the engineering community have been climbing the learning curve of Grasshopper now that many of them see the flexibility it affords with designing HVAC systems. We have data from a survey with 200 responses from the most active users in our community. 40 percent of them were in architecture, 33 percent were environmental consultants, and the rest were engineers.

This is all very fascinating, and I wish you both the best of luck with Ladybug Tools and the new initiatives. 

(Mostapha and Chris) Thank you.

Readers can learn more about Ladybug Tools by visiting their website here.

---

Image Credits

Format equates to “party with copyright” / “party with reserved rights of use.” (eg: image: Ladybug Tools LLC / Architosh. All rights reserved.) 

Title image credit: Ladybug Tools LLC / Architosh. All rights reserved.

---