Interacting with Climate Data

We’re creating a web-based tool for interacting with climate data. The Department of Energy’s EPW files have a consistent format and are publicly available for almost every major city on Earth. This is great for data visualization, so here’s the first step we took: observe and compare parameters from an EPW file for TMY Data.

While there are plenty of robust programs available for environmental simulation of modeled geometry, abstract climate analysis and our interaction with it requires improvement in the AEC industry.

A great tool for early climate study is Climate Consultant, but this is a standalone program which makes it difficult to produce drawings and provide documentation. Another option is Ecotect, but Autodesk absorbed this beloved program and quickly put an end to further releases, vying instead for a limited front-end implementation in other software.

In the Grasshopper community, promising development for data interaction can be found with Ladybug and Dhour. These programs are powerful in that they can use climate data directly with geometry, however many designers are not familiar with Grasshopper for Rhino which creates a potential hurdle.

The interface we’re working on offers customization of graphics through web-based interaction (we’re setting geometry aside and focusing on climate conditions). In the video above, we have a familiar scatter plot with a row of parallel coordinates below. All of these coordinates may get a little confusing, so the below interface is a simpler example which focuses on Seattle’s summer temperature conditions. Remember to be in Firefox or Chrome to get full functionality:

As is the case with any parametric model, we learn about its properties through interaction. With a flexible interface, we can apply a forensic approach when learning about a given climate. We often compare humidity to temperature and radiation to illuminance, but are there other trends which we have overlooked? How about our intuitive assumptions? Do they align with the raw data? Our aim with this first pass is to provide an easy way to visualize EPW data, identify patterns in parametric relationships, and deduct conclusions on the climate based on visual feedback.

The basic example above reveals some interesting things about Seattle when adjusting some of the viz parameters. By toggling through the X-axis, Y-axis, Radius, and Color display, we get an array of charts as represented below:

HG
FE
DC
BA

Now, this is looking rough and abstract and it may get even more so. While the above was a look at some temperature and humidity values, bear in mind that an EPW file offers 20+ parameters measured at every hour over the course of a typical meteorological year. There’s much more data to be explored. Below is a demonstration of solar values, and this is setup with “date” in the X and “hours” in the Y to create the familiar heat map that we see in various climate visualization software:

Again, by making basic adjustments in the visibility settings, we can observe transitions between nodes to better understand the data (ie: does a y value move up or down when animating from a temperature trend to a humidity trend?) Some choice examples can be found in the images below:

a5a4
a3a2
a1a8
a7a6

When using the interface, one starts to understand that the radius and color parameters create significantly more complexity. These settings are optional so the user doesn’t get overwhelmed by four-dimensional data on a two-dimensional canvas.

And speaking of multi-dimensional complexity, many thanks to Kai Chang for his development of the parcoords library for D3JS. This library was essential in the design of this tool. For more on parallel coordinates, check out Kai’s mind-altering presentation from OpenVisConf 2013.

Lastly, we’re ensuring that this interface remains generic for dealing with any range of data. We did some earlier work with optimization solvers and intend to implement an interface similar to this for optimization solvers. In the design for this post, we have parameter values pop-up when the mouse hovers over a target node. It’s possible to turn this functionality into a fully interactive model for each node on a full landscape of optimization. Similarly, we can use a generic tool like this to study trends in occupancy comfort data as well as EMUs (Energy Monitoring Units).

In conclusion, we’re providing the interface for designers to test out on their projects. Click here to access the interface, have fun and let us know if you have any questions or learn something new about your climate.

6 Comments

  1. Nathan Lowe says:

    Erick,

    You are the man! This is the sweetmeat!

  2. Sam says:

    This is fantastic. How do we control the date though?

  3. ekatzenstein says:

    Sam, as it stands now one can control the day by scrubbing the “Date” column in parallel coordinates.

  4. Sam says:

    Love this tool, especially when I need to quickly cull out a certain set of climate conditions in order to determine whether a certain passive design concept is worth pursuing. Being able to more accurately control the date range would be helpful, if not simply adding in the other nine month names along the axis. Thank you for the tool, keep up the interesting work.

  5. Dan says:

    This is very intuitive, which isn’t something you hear a lot when people talk about energy modelling/weather data tools.

    One quick suggestion: The interface currently labels the data axes (DryBulb, RH) using the abbreviations of the weather file. For people who aren’t familiar with EPW files, it would help to provide a description of the abbreviations, or a link to a website that does. I mention this because I was particularly interested in rainfall data, but eventually realized ‘PrecWater’ is not a measure of rainfall. A glossary of some sort could prevent these confusions.

Leave a Comment