by Zelia E. ’21
This summer, as part of the Lakeside Summer Research Internship (LSRI) experience, I am working on a narrow data project which requires pulling data from the output of one computer model and passing it to another. The task is rather simple in description, but the path to implementation has been chalk-full of obstacles and red herrings. Mentored by Dr. Town, who has been supportive every step of the way, and working closely with my partner Olivia W. ’22, I overcame obstacles and wrote a successful piece of code to transfer data from complex output files into strictly formatted input files. My work will hopefully help the Northwest Avalanche Center (NWAC) with their risk forecasting.
My project is a small part of a larger one, in cooperation with Olivia W. ‘22. Our ultimate goal is to set up a tool to help the avalanche risk forecasters at NWAC. Each day at NWAC, they predict the degree of avalanche risk by region and provide other relevant information (learn more about this in Colton’s or Vishnu’s posts about their avalanche forecast consistency analysis project). These predictions are based on weather data and information about the snowpack (i.e. grain shapes and moisture contents of different layers within the snow, affecting their relative stability). Olivia and I have been working with SNOWPACK, a Swiss land surface model that calculates a whole bunch of information about the snowpack, including the information that avalanche forecasters consider in their predictions. The SNOWPACK model is currently used for both research and avalanche risk forecasting. However, the European-made model is used much less here in America. Just a few avalanche centers in the U.S. currently use SNOWPACK, and we hope to bring its utility to our local NWAC to assist the forecasting team there.
To have the SNOWPACK model predict future snowpack, we need to feed it forecasted weather information by location. For this forecasted weather data, we turn to another model: the Weather Research and Forecasting (WRF) model. The plan was to take data from WRF output and feed it into SNOWPACK. The trouble is this: WRF is a complex program designed for a broad range of applications, while SNOWPACK has strict requirements and asks for a specific set of data. WRF’s broad purpose means that it calculates a lot of different information; it has so many possible outputs that it would be cumbersome and inconvenient to make them all available at once. So when various organizations run the model for their own purposes, they tailor it to their needs and only make certain data available in the output files.
Because of its complexity, WRF is not the sort of model we might run on our own computers. Instead, we are using output from the University of Washington Forecasting Group who runs WRF for the region. To get our output files, though, we go through NWAC. This is getting complicated, and so far I’m only setting the scene for my own work, so let me take a step back. After all, I am doing what I am doing so that others don’t have to. Long story short, the output files we get to use are not configured for our purposes. They were set up for someone else, and they don’t fit our project how we would ideally want them to — we are working with hand-me-down data. But as with most hand-me-downs, they fit our needs and we made them work.
My first task was finding what output variables from WRF would fulfill SNOWPACKS’s input requirements, and next I would put that list into action. I filled out a nearly complete list of variables for all of the values SNOWPACK required and even some optional ones, but when I ran my code to access those variables from WRF, it failed. After scouring the internet for other ways to access variables from WRF and any other possible names that my variables might have, I discovered that the information I’d been working with all along was wrong.
I had been looking at a list of output variables for a WRF model run, indeed a WRF model run from the UW. But remember: the data that I was given was hand-me-down data, and it had already received alterations. Our output files were tailored in anticipation of someone else’s needs, not our own, and the list of variables I was looking at for a UW WRF model run were not available in our own files. So I went back to the drawing board. I threw out the list I had before and again worked to find matching WRF output variables to satisfy SNOWPACK’s input requirements — this time with much more limited options from WRF. Some values were quick and easy to find equivalents for, and others took time.
The types of meteorological forcing (weather input) data that I needed to collate from the WRF model and prepare as input for the SNOWPACK model: wind speed, air temperature, air humidity, incoming longwave radiation, incoming and reflected shortwave radiation, snow surface temperature, ground surface temperature, accumulated precipitation, and snow height.
I reached out again and again to Dr. Town, to confirm my hunches about specific terminology and variable descriptions. When Dr. Town was not sure, we wrote down our questions and brought them to a meeting with Robert Hahn, the avalanche meteorologist at NWAC who sent us the WRF output files. He was, after all, the previous owner of the hand-me-downs, and he had more experience with these output files than we did. After trials and tribulations, frustrations and false-successes, I finally found something for each and every required variable and successfully ran my code to get them all from WRF output files and into an input file for SNOWPACK. We don’t have as many optional inputs as I previously thought we might, but we managed to satisfy every need.
Olivia is hard at work running SNOWPACK with the input files I set up. So far, this run is merely proof of concept, but we are excited for the prospect of eventually enabling NWAC to run SNOWPACK for themselves day-after-day all season long. And we are both ecstatic that after every error message I saw in Python and every error message Olivia saw in SNOWPACK, everything ran smoothly!