{"id":1791,"date":"2010-07-22T20:28:19","date_gmt":"2010-07-23T00:28:19","guid":{"rendered":"http:\/\/www.easterbrook.ca\/steve\/?p=1791"},"modified":"2010-07-22T23:54:54","modified_gmt":"2010-07-23T03:54:54","slug":"a-portable-climate-model","status":"publish","type":"post","link":"http:\/\/www.easterbrook.ca\/steve\/2010\/07\/a-portable-climate-model\/","title":{"rendered":"A portable climate model"},"content":{"rendered":"

One of the exercises I set myself while visiting NCAR this month is to try porting the climate model CESM1<\/a> to my laptop (a MacBook Pro). Partly because I wanted to understand what makes it tick, and partly because I thought it would be neat to be able to run it anywhere. At first I thought the idea was crazy – these things are designed to be run on big supercomputers<\/a>. But CESM is also intended to be portable, as part of a mission to support a broader community of model users. So, porting it to my laptop is a simple proof of concept test – if it ports easily, that’s a good sign that the code is robust.<\/p>\n

It took me several days of effort to complete the port, but most of that time was spent on two things that have very little to do with the model itself. The first was a compiler bug that I tripped over (yeah, yeah, blame the compiler, right?) and the second was the issue of getting all the necessary third party packages<\/a> installed. But in the end I was successful. I’ve just completed two very basic test runs of the model. The first is what’s known as an ‘X’ component set<\/a>, in which all the major components (atmosphere, ocean, land, ice, etc) don’t actually do anything – this just tests that the framework code builds and runs. The second is an “A” compset at a low resolution, in which all the components are static data models (this ran for five days of simulation time in about 1.5 minutes). If I was going on to test the port correctly, there’s a whole sequence of port validation tests<\/a> that I ought to perform, for example to check that my runs are consistent with the benchmark runs, that I can stop and restart the model from the data files, that I get the same results in different model configurations, etc. And then eventually there’s the scientific validation tests – checks that the simulated climate in my ported model is realistic.<\/p>\n

But for now, I just want to reflect on the process of getting the model to build and run on a new (unsupported) platform. I’ll describe some of the issues I encountered, and then reflect on what I’ve learned about the model. First, some stats. The latest version of the model, CESM1.0<\/a> was released on June 25, 2010. It contains just under 1 million lines of code. Three quarters of this is Fortran (mainly Fortran 90), the rest is a mix of shell scripts (of several varieties), XML and HTML:<\/p>\n

\"\"<\/a>

Lines of Code count for CESM v1.0 (not including build scripts), as calculated by cloc.sourceforge.net v1.51<\/p><\/div>\n

In addition to the model itself, there are another 12,000 lines of perl and shell script that handle the installing, configuring, building and running the model.<\/p>\n

The main issues that tripped me up were<\/p>\n