Call for Papers:
IEEE Software Special Issue on Climate Change: Software, Science and Society

Submission Deadline: 8 April 2011
Publication (tentative): Nov/Dec 2011

A vast software infrastructure underpins our ability to understand climate change, assess the implications, and form suitable policy responses. This software infrastructure allows large teams of scientists to construct very complex models out of many interlocking parts, and further allows scientists, activists and policymakers to share data, explore scenarios, and validate assumptions. The extent of this infrastructure is often invisible (as infrastructure often is, until it breaks down), both to those who rely on it, and to interested observers, such as politicians, journalists, and the general public. Yet weaknesses in this software (whether real or imaginary) will impede our ability to make progress on what may be the biggest challenge faced by humanity in the 21st Century.

This special issue of IEEE Software will explore the challenges in developing the software infrastructure for understanding and responding to climate change. Our aim is to help bridge the gap between the software community and the climate science community, by soliciting a collection of articles that explain the nature and extent of this software infrastructure, the technical challenges it poses, and the current state-of-the-art.

We invite papers covering any of the software challenges involved in creating this technical infrastructure, but please note that we are not soliciting papers that discuss the validity of the science itself, or which take sides in the policy debate on climate change.

We especially welcome review papers, which explain the current state-of-the-art in some specific aspect of climate software in an accessible way, and roadmap papers, which describe the challenges in the construction and validation of this software. Suitable topics for the special issue include (but are not restricted to):

  • Construction, verification and validation of computational models and data analysis tools used in climate science;
  • Frameworks, coupling strategies and software integration issues for earth system modeling;
  • Challenges of scale and complexity in climate software, including high data volumes and throughputs, massive parallelization and performance issues, numerical complexity, and coupling complexity;
  • Challenges of longevity and evolution of climate models codes, including legacy code, backwards compatibility, and computational reproducibility;
  • Experiences with model ensembles and model inter-comparison projects, particularly as these relate to software verification and validation;
  • Meta-data standards and data management for earth system data, including the challenge of making models and data self-describing;
  • Coordination of cross-disciplinary teams in the development of integrated assessment and decision support systems;
  • The role of open science and usable simulation tools in increasing public accessibility of climate science and public participation in climate policy discussions;
  • Case studies and lessons learned from application of software engineering techniques within climate science.

Manuscripts must not exceed 4,700 words including figures and tables, which count for 200 words each. Submissions in excess of these limits may be rejected without refereeing. The articles we deem within the theme’s scope will be peer-reviewed and are subject to editing for magazine style, clarity, organization, and space. Be sure to include the name of the theme you are submitting for.

Articles should have a practical orientation, and be written in a style accessible to software practitioners. Overly complex, purely research-oriented or theoretical treatments are not appropriate. Articles should be novel. IEEE Software does not republish material published previously in other venues, including other periodicals and formal conference/workshop proceedings, whether previous publication was in print or in electronic form.


For more information about the special issue, contact the Guest Editors:

  • Steve Easterbrook, University of Toronto, Canada (
  • Reinhard Budich, Max Planck Institute for Meteorology, Germany (
  • Paul N. Edwards, University of Michigan, USA (
  • V. Balaji, NOAA Geophysical Fluid Dynamics Laboratory, USA. (

For general author guidelines:

For submission details:

To submit an article:


  1. The Climate Code Foundation will definitely submit a paper.

  2. Pingback: Tweets that mention IEEE Software Special Issue on Climate Change: Software, Science and Society | Serendipity --

  3. A trivial question: I have seen the term “software infrastructure” used mostly in the sense of “middleware, network protocols, databases” etc. that is, infrastructure that is used by applications to do their job, just like the usual term “infrastructure” denotes means of transportation etc.

    But when you say “A vast software infrastructure underpins our ability to understand climate change” its “software infrastructure” in a sense that encompasses all software used in climate science, correct?

    Another question out of curiosity: The high energy physics community is quite famous for inventing new software technologies to solve their somewhat idiosyncratic problems, the WWW itself is a prominent, but rather special example. Did climate science already influence software engineering in a similar way? (This question is deliberatly imprecise 🙂 )

  4. Tim: I expect it’s used in the same (broad and sophisticated sense) that Paul Edwards uses it in his excellent book “A Vast Machine”, which you should read if you are interested in climate science and computation.

  5. @Nick Barnes
    Thanks for the reference, but I fear that a push on my need-to-read stack will result in a StackOverflowException.

    The quote “I intend the notion of knowledge infrastructure to signal parallels with other infrastructures, such as those of communication, transport, and energy distribution. Yet this is no mere analogy or metaphor. It is a precise, literal description of the sociotechnical supports that invariably undergird facts and well-accepted theories.” seems to indicate that Edwards uses “infrastructure” in the sense I expected, or is there more to it?

  6. Well, Edwards spends most of his first chapter discussing the concept—which he describes as “a key analytic category” in the history and sociology of technology—so I’m reluctant to summarize. Also, I can’t speak for Easterbrook or Edwards on what they mean by the term. But I would expect “the software infrastructure” here to include the whole caboodle: all the code, all the data, and especially all the processes and people contributing to the information-technological underpinning of climate science (and also presumably to our response to climate change, as outlined in Easterbrook’s recent Grand Challenge paper).

  7. Tim: what counts as infrastructure depends on the observer. To an application software developer, middleware is infrastructure – it’s there, it’s useful, but most if its detail and history is invisible. To a writer, the applications software is infrastructure for the same reasons. Infrastructure is any stuff you rely on, without needing to think much about. I explain a little more here:

Leave a Reply

Your email address will not be published. Required fields are marked *