In this guest post, ERST607 student Callum Mclean delves into the using GIS to estimate solar radiation.  Take it away, Callum… (updated 14 October for clarity.)

An Introduction to the weirdly complex world of solar power

As a well-informed evildoer you might have heard we are in the midst of a rather problematic climate situation. A big part of this is how we generate energy, particularly the combusting of ex-dinosaurs. Alternative energy sources are a great way to help combat climate change, and solar energy is an excellent place to start (but not the only idea). But, as budding mad scientists, we still want to vaporise a troublesome spy or two. Time for some climate-friendly death rays.

Figure one: Artists impression of future campus additions

It takes about 3 GJ to vaporise someone, meaning we need a lot of solar panels. We might need to work out where to put them all – The Lincoln Uni campus is barely used over summer, so that’ll work nicely. Now to work out how much energy we can generate there. If only we had a program that was used for spatial analysis…

Yeah, of course, this is about ArcGIS. Specifically, this is about a tool called area solar radiation, which is part of the solar radiation tool kit.  The other tools in this toolbox are the points solar radiation and the solar radiation graphics tool. The points solar tool is just the area solar tool, but for points.  The solar radiation graphics tool is more complex and is used to visualise a hemispherical viewshed and sun and sky map, and I’m not talking about it cause it’s too hard to keep a light and casual tone.

Anyway, strictly speaking, the solar radiation tool is very simple. All you need is a digital elevation model (DEM), although this can be surprisingly complicated, and it’ll produce a pretty map that will give you all the information you need…

Unfortunately, it’s not actually that simple. Let’s take a proper look at this tool.

This is the landing page for the solar radiation tool. I’m sure the eagle-eyed readers have already spotted that there are only two required parts to this tool – an input raster (which must be a DEM) and an output raster, which you just need to give a name.

However, doing that won’t actually help you very much at all. The first thing that needs to be fixed is the latitude. The latitude is essential because as we whirl around in a giant vacuum around that giant burning ball of gas, the angle the light approaches changes depending on where you are, and when you are. We need the latitude to be at 430 (for Christchurch). The tool is designed for local landscape scales, so you only need to use one latitude value. If you want to use larger DEMs, you’ll need to break up the DEM into areas contained within a single degree. If your DEM has a spatial reference, this is automatically entered into the tool. I’ll come back to sky size soon.

Time configuration is the next bit we need to play with. This setting sets how many days the tool will calculate. The start/finish day can be entered using the calendar icon, or numerically with one being the first of January. The year looks like it would set the dates, but it only tells the tool if it is a leap year. Yes. Really.

If you just want to do a year, you can use the drop-down menu to change ‘Multiple days’ to ‘year’ or ‘day’. The day and hour interval is how often within the set time period it will measure. As a rule of thumb, for multiple days, keep three-day intervals as a minimum to stop sun track overlaps.

Sky size is the resolution of the viewshed and sun and sky maps used for the calculations (You can make your own with the Solar Radiation Graphics tool). A higher resolution allows for more accurate calculations but nearly melted my computer when I played around with it, so approach with caution. The default setting is entirely appropriate for most purposes, especially if calculating annual radiation on large DEMs with a 14-day interval. At points, a sky size of 512 is more appropriate, and smaller day intervals need higher sky resolutions. At one day intervals, a sky size of 2800 is recommended. Again, this tool can melt your computer, so consider this when choosing settings.  The small checkbox means you get individual outputs for each interval, rather than a cumulative total.

The next piece we have to interpret is the topographic parameters. The Z factor is used to correct for Z units if they are different from the X,Y units. Not usually a problem. Unless you’re an American.  You can work out the aspect and slope from a separate raster if wanted. Calculation directions are related to the resolution of the DEM. At 30 m resolution, 16-32 are appropriate, but fine resolutions, and/ or high numbers of man-made structures the number of directions needs to increase. This will also add to the computer melting, though.

The diffuse model type can either be uniform (default) or standard overcast, which accounts for the zenith angle. The azimuth and zenith divisions are used to create the sky sectors, so increase for greater accuracy.

The radiation parameters are designed to correct for atmospheric conditions, and you must update for them manually. Diffusion is 0.2 for very clear sky conditions and 0.3 for generally clear sky conditions. Transmission (how much energy reaches the ground) values are 0.6 or 0.7 for very clear sky conditions and 0.5 for only a generally clear sky.

Finally, these optional outputs give you additional outputs showing the direct (no diffusion), diffuse, and finally the duration of incoming solar radiation (how long the area is getting light) in hours. The last one is surprisingly useful.

Whew. After wrangling your way through all those not really optional inputs, we can finally get our output and start putting up some solar panels.

Ok, so that’s pretty, but not amazingly helpful. There’s no units. And there’s no attribute table. What are we looking at?

If we scrounge through the documentation, we can find that the output raster is in units of Watt-hours per square meter (WH/m2), not to be confused with watts per hour.

The unit above is a measure of the energy reaching the earth’s surface, solar insolation. A watt-hour (WH) is a measure of energy while a watt measures the rate of energy being used (or produced) in joules per second.  If we compare this to time and distance, a WH is like distance (in metres) and a watt is like speed (in metres/second).  The tool was set up to run over a whole year, so we see in the legend is the accumulated energy per square meter accumulated over the entire year.  This means that somewhere, there is a square meter on campus that is getting 1,258,750 watt-hours of energy per year, enough to vaporise 1.5 people every year (that would be Dr Evil and Mini-Me).


So now we can translate the output, it would be nice to know a little more than the max and mean values. Even though we don’t have an attribute table, we still have another option – making some charts!

That’s a nice graph, with some great info quietly tucked away. We now know that we have 322,979,453,029 accumulative watt-hours hitting the campus every year (from the Sum value). That’s more like it, with enough energy to vaporise the population of a small cites worth of spies! Regarding the obligatory Star Trek reference, that’s still only 0.0000025098% of the 12.75 million terawatts that the Enterprise’s warp drive produces.

Unfortunately, there’s a slight issue with this plan. Solar panels don’t have 100% efficiency of converting solar radiation to energy. The best commercial market makes about 22.8% of intercepted energy, with the industry-standard sitting at around 20%. In case you thought super science might save us here, the upper limit according to standard physics, is 33.16%.  This is easy enough to fix though and gives us a final total of 77,515 spies vaporised a year, at a rate of about nine an hour.

This didn’t go into how to determine where to put all the solar panels, which is a whole other thing, but hopefully, you’ll now know that you need three GJ of energy to fully vaporise James Bond. And something about area solar radiation and stuff.