Spurred on by Michael Tobis’s thoughts about building a readable/understandable climate model in Python, I dug up an old bookmark to a course offered in UMinn’s geology department onĀ Designing your own “Earth System” Model. Really neat idea for a course. Now, with a bit of tweaking, I could set up a similar course here, but with a twist – we recruit a mix of CS and Physics students onto the course, and put them together in cross-disciplinary teams, each team building an earth system model of some kind (tapping into the domain knowledge of the physicists), using current CS and software engineering tools and techniques. And to keep Michael happy, they code it all in Python. Marks awarded based on understandability of the code.

In the longer term, we keep the models produced from each instance of the course, and get the next cohort of students to develop them further – the aim is to build them up to be full scale earth system models.

Update: Michael has posted some more reflections on this.

8 Comments

  1. I commented on Michael’s post that small projects would be a better way to start than throwing a team at developing a fully competitive model from the start … so I’m bound to agree that this sounds like a fun practical course. I’d love to teach something like that myself (but that’d mean I’d have to remember how to be a modeller …)

  2. Why just physicists?

    [Good point. I didn’t really mean to suggest just physicists. – Steve]

  3. And why just your students? Could you think about open source for this? From the video, the STELLA and iThink looks fairly comprehensible http://www.iseesystems.com/community/WebSeminars/Dec_10_2008.aspx

  4. Thanks 1.0e6!

    If this goes forward I think it’s important to get some input from meteorologists and oceanographers, while not leaving them in control! The first part of the requirement is to avoid coming up with something novel, elegant and wrong. The second, of course, is to avoid coming up with another instance of the same sort of heavy and fragile contraption we are already stuck with.

    I have often observed that many physicists do not find the problem appealing. They end up making Dysonesque criticisms that are surprisingly off-base. In general, the field can neither benefit from as much physical rigor as most physics, because the problem is too messy, nor from as much statistical rigor as most biological/medical research, because the sample size for most purposes is 1. A certain tolerance for ambiguity is required; the intellectual style is different from that of other sciences.

    (Some people think these inherent problems leave us off the hook for policy. Why this is unsound is left as an exercise for the reader.)

    I think it’s absolutely got to be an open-source project but like any large open source project it needs a core group whose motivation is other than casual. A paid team would be good, but on consideration, if enough students could be rounded up for this, it might even be better. It would simultaneously serve as 1) an instance for the development of a theory and a pedagogy of scientific software development and 2) a basis for expansion of the population of people who have a substantive understanding of climate.

    In short I think it could be a very fine strategy.

  5. Michael Tobis :

    … the intellectual style is different from that of other sciences…

    Yes, I think this is a crucial point. The ability of software people to create useful abstractions and ignore detail when necessary is a major intellectual asset. As is the idea of systems thinking, which has had some influence on the systems analysis / requirements engineering community.

  6. Well,on reflection, there is a problem with having a student design of a CGCM.

    So, an atmospheric model is pretty much four parts: fluid dynamics, radiation, boundary conditions/forcing, and everything else, the last also known as “physics” for some reason. Radiation, in principle simple, in practice is sufficiently complex and specialized as to be inaccessible to anyone but a specialist. Fluid dynamics is numerical methods intensive. Conceivably students could achieve these goals, but they would really have to be domain specialists.

    Ocean models lack an important radiation term, but the fluid dynamics are substantially harder. And there is the spin-up problem. And ice dynamics are very hard. My sense is you don’t teach numerical methods for PDEs. They are really the reason these codes are so few and far between. They are not really as big as the bloated fortran would have you believe, but they are, in places, subtle.

    So it is not easy to imagine a full blown CGCM being put together this way. One thing we might think about instead is designing an EMIC that could be extended to a CGCM. I’ll ponder this further.

  7. @Michael Tobis

    As a software engineer without the physics/climate grounding, I really would like to contribute to a project like this in the design/architecture/system sense but am not sure how realistic that is. On the positive side, it’s not like I knew anything more about any of the business fields I have helped model and build software systems around, but there’s still always the trepidation of “but you don’t know what we do” – well yes, that’s what I do, get to know what you do at the point where it intersects with a software model.

    I love the class-based approach suggested here, although it doesn’t help me fit myself in any better. :) On taking a literate approach, one thing that I have rarely seen CS students prepared for is writing significant explanatory test suites around their algorithmic solution. But for a teachable, open, maintainable software model it ought to be an even more central part of the development process.

  8. Pingback: Documenting climate models | Serendipity

  9. I admire the motivation and intent of a project like this, but when software guys start talking about design/architecture/systems I get really nervous about ‘over design’. The design of a code like this should reflect the governing equations (modules for different terms interacting through well-defined ‘operators’), getting more complex than that is overkill. OpenFoam is a great example of the sorts of abstractions that make sense, some decent software engineering effort puts the code written using those libraries closer to how you’d write down the governing equations.

    I’ll echo the support from the other commenters for a ‘literate’ approach, scientists are already trained to communicate with tightly coupled prose/math/data/viz, finding a way to integrate code into that sort of method seems promising.

Join the discussion: