Dragonfly 0.0.3 and Urban Weather Generator 5.0 Released!

Release Notes - July 9 2018
Dragonfly 0.0.3 and Urban Weather Generator 5.0

Greetings members of the Ladybug Community!

We write to you today with a special announcement about an insect that is finally getting past its pupa stage! Many of you know that the Dragonfly plugin has existed as a beta for a while and, until today, it had not been officially released due to complications with the underlying engine that it connects to: the Urban Weather Generator (UWG), which morphs rural (or airport) epw files to account for the the effects of urban heat island. This is achieved by simulating the energy balance of the heat fluxes coming from a typical urban canyon, and accounts for, amongst other factors, the impact of building geometry, program, urban materials, traffic, vegetation and atmospheric heat transfer.


Over the past year we have poured a substantial amount of time into translating the Urban Weather Generator from it’s original Matlab code into Python. This has resulted in a number of major benefits to Dragonfly, including:

  1. We can now access more features of the engine, increasing the urban and building parameterization choices, improving the precision of the inputs, and the overall accuracy of the results.
  2. We can easily fix bugs in the engine, meaning that the engine is now much more stable than it was previously. For those of you who were familiar with the “Fatal Error” bug that prevented many of us from using the engine previously, we have applied a patch to resolve most occurences of this bug.
  3. We can make use of the building archetype templates that Joseph Yang added to the UWG for his thesis. These 768 templates represent sixteen different building types, three construction eras, and sixteen climate zones generated from the Commercial Building Energy Consumption Survey (CBECS), which substantially cuts down on the time needed to build urban models.
  4. We can run the engine using the Python package that installs with Rhino, which makes Dragonfly installation a lot easier.

In summary, we can finally say that the urban heat island modeling capabilities of Dragonfly are stable, can yield the accuracy seen in the original UWG validation studies, and are ready for broad usage. For this reason, we invite all of you with an interest in urban heat island to install Dragonfly and the new Python UWG by following the instructions on this page:


We also invite you to look at the updated example files and summary of workflows for using Dragonfly:

Now, many of you may be asking yourself, if Dragonfly is no longer a beta, why are we installing it from a github code repository as opposed to Food4Rhino like the other insects? The reason is that, while the urban heat island modeling capabilities of Dragonfly are largely complete, the full vision of Dragonfly is far from finished. Those who have seen presentations on Dragonfly know that the ultimate purpose of the plugin is to give access to a range of large-scale climate data sets and modeling engines. Urban heat island is only one of such large-scale climate phenomena and, before you see us post a copy of Dragonfly to Food4Rhino, you can bet that Dragonfly will also have robust capabilities for retrieving Actual Meteorological Year (AMY) epw data. AMY data differs from Typical Meteorological Year (TMY) data in that it can represent an extreme year (like one with a heat wave) as opposed to the typical conditions of a climate. We also intend to add support for visualizing publicly available satellite image data sets (including several with thermal images), as well as the creation of future weather files that account for global climate change.

Finally, we would like to give special thanks to Joseph Yang for working with us throughout this project to brilliantly explain the logic behind the original UWG code, and Ryan Welch who was always willing to stop what he was doing and work through the math behind the code.

So enjoy modeling urban heat island for the time being and stay tuned in coming months as we build the next version of Dragonfly with more features!

The Developers of Ladybug Tools
Including Saeran Vasanthakumar and Chris Mackey
Maintainers of the Urban Weather Generator and Dragonfly


Congrats @chris and @SaeranVasanthakumar!

Thank you @chris, @SaeranVasanthakumar and the other LB’s developers for the great tools !!

Thank you @chris and @SaeranVasanthakumar.

Great news @chris and @SaeranVasanthakumar.
Thanks for this contribution.

Really nice guys @chris and @SaeranVasanthakumar. Can’t wait to test it :wink:

I am going to use this a lot. Thanks a lot @SaeranVasanthakumar and @chris

Great work, but Rhino6 requirement is a showstopper for me. Can I still download the version that works with Rhino5 (despite all the bugs)? Thanks.

1 Like

Thanks for the update!

@erydjunaedy ,

To be honest, it is possible to get it running in Rhino 5 with a very hacky method that I can post about soon. The key issue is that the version of ironPython in Rhino 5 lacks certain critical modules used by the uwg (notably, the csv module) and you have to install these modules manually.

I’ll try to post the Rhino 5 workaround soon but I definitely recommend using the 90 day free trial of Rhino 6 before using the hacky method that I will post.

And I definitely do not recommend using the very old version. Beyond the fact that it only worked ~50% of the time, there are a number of important parameters that have been exposed in the new version here that are important for getting an accurate simulation.

Hi Chris, yes I am installing the trial version. If you can post the work around for Rhino 5, that would be great. I appreciate it. Thanks.

Phenomenal work as always Chris and Saeran, its good seeing newer insects getting more attention. The old UWG version would crash horribly or simply not respond to changes in user inputs. Hope the new version works well. As the others already said, please make this work in Rhino 5 as well, if possible.

Wow ! Great work,
Thanks so much for your effort.

Congratulations @chris and @SaeranVasanthakumar

May I suggest two things ?
1 - Meteonorm software is providing different types of meteorological data, including what you would name AMY. Furthermore, it can create interpolation between different meteostations around your project site. http://www.meteonorm.com/
2 - Weather data from airport station can be a source of mistake. French academics working on Urban Island Effect in Nantes measured that, whether wind was coming from forest around (cool and humid air), or tarred runway (jot and dry), a temperature difference of up to 7°C was possible in summer !

Thanks for all.

Hi Chris,

Did you finally post the hacky method to run Dragonfly in Rhino 5? I could not find it.


@Julioamodia89 ,

No. It’s frankly a significant amount of development effort on our end just to add a feature that, in our opinion, is a step back in time. If you really need it and you have no other option, you would have to edit the csv module out of the UWG:

Or you could run the UWG from command line using a .uwg file after using Dragonfly to help you get the correct inputs to plug into it.

The main issue is that the version of Python in Rhino 5 is so ancient that it lacks a csv module.

1 Like

Hi @chris
Thanks for the quick response. I understand what you mean. I think I will jump into Rhino 6.

@chris has the creation of future weather files been implemented in the current version of Dragonfly?

Hi @patrykWozniczka ,

The answer is no and the reason is still that, if we implement it, I would want to “do it right”. Of course, if all that you wanted to do was add 2C to every hour of an EPW file, this is easy enough to do right now and it’s not that much different from what I know certain “future weather” services charge for. You can just use the LB Arithmetic Operation and the DF Create EPW component to make your own weather file with dry bulb temperatures shifted up by a certain amount.

But I would consider this type of thing a hack and not the right way to do it since it does not account for the change in the weather extremes that one would likely experience within a typical future year (I’m still a bit amazed that some services charge people for just a simple addition across a list of temperatures).

In any event, the current hope to “do this right” is to get a collaboration going with NREL as I know there are several people over there with an interest in offering future weather files that are truly forecasts and not hacks. Maybe with the current administration in the US, there’s some hope for NREL getting funding for this now.

Depending on how deep you want to go I can also recommend this open source project:

It relies on a huge data set and so I have not gotten it to run on my system but I know that it’s using much better methods than the hack that I described.