A Week At Work (3)

Tuesday.

Every Tuesday and Thursday morning, I join a group of colleagues for what we coined "The Write Stuff," a writing group. We meet down the hall from my office in a conference room with large windows that overlook a beautiful garden, and spend two hours not chatting (mostly), but working on whatever everyone is working on. It sounds banal, but it's incredibly effective. The peer pressure of "Everyone else is working!" really makes you push through and avoid distractions. Also, the room is a pleasant change from my windowless office situation.

Coding, finally.

My goal for today was to write a script that analyzed rainfall projections for the next 80 years (2020 to 2099) and find years with extremely high and extremely low amounts of rainfall in the Great Plains. We found previously that rainfall variability is very different across the Great Plains. For example, in the Southern Plains, annual rainfall can vary a lot more than in the Northern Plains. Now we were interested in whether these super dry and super wet years will occur more or less often in the future. Specifically, we wanted to see if the frequency of years and the number of consecutive years with rainfall of more than 20 percent above and below the decadal average will change over time.

Two assumptions were important for us going into this. We assumed that ranchers are used to some degree of year-to-year variability - they could handle some wet and dry years. But the really bad ones, especially when several occur back to back, like the droughts around 2012 or in the late 1980s, would be a real challenge. Because of that, we chose a threshold of 20 percent above or below the decadal average. It's an arbitrary value, really, and we'll change it once we find a more meaningful number that's based on previous studies. But for now we'll run with it. We also used an average that will change every decade, instead of one that runs from 2020 through 2099.  Why? Because of our second thought: whichever way things will change, even if it continues to get drier, ranchers will find ways to adapt to a new normal over time, just like they have in the past. Using something like a running average will account for this.

Now, of course a drought is more severe the hotter it is. So looking at rainfall without temperature will only give us half the picture. But for now, it is the first step to understand the effect of climate change (and climate variability) on ranching. We will repeat this process with temperature, and eventually with a suitable drought index that combines temperature and rainfall.

Once we had this figured out, the real challenge was writing the script, telling the computer what to do. I am using a programming language called NCL, which stands for NCAR Command Language (and NCAR is short for National Center for Atmospheric Research in Boulder, Colorado – we really know how to make things complicated). NCL is a programming language specifically for climate and model data, and widely used around the world. I had written a script a few weeks ago that did something very similar, only with monthly data that were compared to rainfall observations, and three thresholds, 10, 20, and 40 percent, instead of one. So this should be similar, but simpler. It's always easier to have a foundation to work from than to start from scratch, because some parts stay almost always the same. Most scripts have three parts: (1) open a data file and extract the necessary variables, (2) process the data in a certain way, and (3) save the result in a new data file. Some scripts create graphs or maps instead of data files, or in addition to it.

Writing a script is like giving a blind person directions for where to go. The computer knows basic operating rules, but it doesn't know what you want to do. It knows pre-defined commands that are hard-wired into the language, like how to open one or more files and how to add or subtract, and basic rules, for example don't divide by zero. But from there it is up to the programmer to make sure the computer does what it should. The smallest typo, a comma instead of a period or a space where there shouldn't be one, can crash the program, or worse, give out incorrect results without anyone noticing. I went step by step, wrote some code, ran it, checked the result, debugged if necessary, ran it again, checked again, wrote some more, ran it, checked it, and so on, until eventually, the script was complete.

Or rather, will be complete. This process can take all day, or longer. After 687 lines of code and eight hours of staring at a screen, I was square-eyed and decided to call it a day and unwind on a long run.

Tomorrow is another day.

Here are Wednesday and Monday, and if you wonder what this about, here is the intro blog post.