High Tech Tomatoes

A case study in data visualization with Observatory

Maximilian Zavodny

Creator of Observatory

The Sundrop Farms facility near Port Augusta, Australia as seen from above.

I had the privilege recently to work with a very talented team on a one-of-a-kind engineering project that was equal parts challenging and rewarding. Our task: commission the solar collector system for a concentrated solar power plant half way around the world. The project was a complete success, but it would not have gone so smoothly without the help of the Observatory data visualization library, which we relied upon throughout every stage of the project, from design to execution to ongoing maintenance. The experience also served as a proving-ground for the Observatory library itself as we stress-tested it in a variety of different configurations and scenarios with real-world consequences. The examples that follow serve to illustrate Observatory's versatility, as well as the crucial role of good visualizations in software and engineering projects.

At the top of this article is an aerial view of the project site near Port Augusta, Australia, which is owned and operated by Sundrop Farms. The solar field is comprised of 23,712 individually controlled mirrors (called heliostats), each one about the size of a picnic table (just over 2 square meters). The solar field acts like a giant magnifying glass: each heliostat is oriented to reflect the sunlight onto a specially-designed receiver that sits on the top of a tower near the field (i.e. that glowing thing in the upper right of the image). The concentration of light heats and boils water inside the receiver, which in turn is used to produce electricity and desalinate seawater. Sundrop Farms uses these outputs to fuel and feed produce (in this case, tomatoes) that is grown in greenhouses adjacent to the solar field. Sundrop Farms has put together some great videos if you are interested in learning more about their technology.

The central challenge in the design and operation of solar fields like this one is accurately orienting each mirror so that it reflects sunlight to the desired target, which is typically hundreds of meters away. Errors in pointing of even 1 degree are way too high. In order to ensure safe and efficient absorption of sunlight, each mirror has its own designated target on the receiver's surface, and performance will degrade if mirrors miss their targets by more than about 1/20th of a degree! The visualization on the right is a representation of the so-called aim-points shown overlaid on a 3d model of the receiver. The dark area is the light-absorbing surface, and there is one ray shown for each heliostat in the field. The rays are colored based on a metric used in the design of the aim-point strategy. We used visualizations like this one to design the aim-point strategy itself and to verify that our code is working as expected.

My responsibility in this project was to “calibrate” the heliostat field. Essentially, I needed to measure and adjust the pointing of each mirror individually ahead-of-time so that when they were commanded to reflect sunlight to the receiver, they would be on-target. Thankfully, my colleagues and I (and others) have devised automated techniques for doing this with a high degree of parallelism. Otherwise it would have been quite a tedious and unpleasant task! The basic technique by which we measure (and then compensate for) each heliostat's individual pointing is by reflecting a light source (sometimes the Sun itself, but usually just lights around the field) into one of a few cameras located on short towers surrounding the field. In this screenshot (left), you can see how we used Observatory to visualize the geometry of one of these reflections. The mirror in bright blue is reflecting a light (in the direction of the green beam) towards a camera (in the direction of the blue beam). With this perspective, one thing becomes very obvious: the neighboring heliostats are partially obscuring the one we are trying to measure! This effect has significant impact on measurement and pointing accuracy, and as such became a major consideration in many aspects of our system. With Observatory, it was easy and fast to explore different geometries and even test out whether we had accounted for the effects correctly in our code: the black regions on the bright blue mirror are the regions we believe are obscured in this case.

One common workflow pattern in both system design and data analysis was to extract a metric having a numeric value for each heliostat (e.g. the fraction of the mirror that is obscured) and to plot those values on a "field map." For example, the field map to the right shows how many distinct light-to-camera combinations are available to each heliostat (based on certain camera and light locations). Being able to rapidly generate and examine field maps like this led to the discovery of many subtle effects and bugs. Very often an otherwise undetected software bug is first noticed in the form of a suspicious pattern on a field map like this one.

As the field came online early in 2016, we started to amass enormous amounts of data. This is where the efficiency of Observatory's light-weight rendering engine really set it apart from other plotting tools. Working on sub-standard laptops and desktops, we could smoothly interact with plots containing hundreds of thousands or even millions of vertices without issue. Real-time rendering and the degree of interactivity it makes possible were not a luxury though; they were a necessity. With a fixed amount of time and effort to spend investigating potential issues, clunkier and slower plots simply mean that less investigation will get done, and the overall quality of the product will suffer as a result.

Over time, we developed a remarkable capability to navigate through our data quickly by creating dozens of scripts that generate highly-customized visualizations. These visualizations answered our common questions and streamlined troubleshooting efforts. For example, one such script produces a “timeline” that symbolically depicts the system’s activity during a specified time period (below). See the suspicious gap at around 8pm? So did we! And it’s a good thing we did, because it turned out to be symptomatic of a larger intermittent problem.

Here’s another example of a dashboard that we used to identify irregularities in the system's behavior. It shows a series of pie charts, depicting performance metrics on a per-camera and per-light basis. Having visualizations like this specifically tailored to our application domain made us much better at answering important questions about our system. The Observatory API is designed to give the user exactly this type of flexibility and control.

Another key aspect of Observatory's design is a consideration for the aesthetics and presentability of the visualizations that are produced. This allowed us to simultaneously use it as an engineering tool and as a reporting tool for management. In many cases, plots originally made for engineering purposes were used directly in correspondence with our customers, investors, and partners, and even in formal publications. This was a boon for us not only because it eliminated the extra burden of frequently manually touching-up plots, but also because it helped keep engineers and managers on the same page: since we could generate reports with minimal additional effort, we were able to provide updates far more often than we would have otherwise. During the commissioning phase of our project, we generated a series of daily reports, like these, which were consumed by engineers and managers alike. On the left is a simplified snapshot of the overall calibration state of the field, and on the right is a distribution of measured pointing errors.

Looking back on the project, I have to wonder what problems would have gone forever unsolved if we never developed the capacity to visualize and interact with our data with such agility. What executive decisions would have been made with stale data if it took too much time and efforts for our engineers to generate and disseminate reports? These are among the concerns I set out to address by creating Observatory in the first place. If something can be visualized in your mind, it should be straightforward to visualize it in Observatory. That continues to be the goal, and the success of the Sundrop Farms project gives me confidence that I've taken a stride in that direction.

Observatory