to make compromises when deciding what to do with more computing power. Modelers have consistently aimed to get five or 10 calculated climate years per day of computing time, says Meehl, and keeping to that figure sets a practical limit on the increase in resolution or scientific complexity that additional computing power will buy. To get climate change predictions right, Meehl says, new science must eventually be included, because inadequate treatment of various feedbacks is “in large part what contributes to the disagreements among models.” On the other hand, Kirtman says that he prefers to focus on refining what’s already in the models, because “we can’t even get the clouds right and until we do that we can’t usefully add in the other feedbacks.”

Programming Problems

Getting everything right is still years away. Achieving global one-kilometer resolution with current GCMs—while adding no new science—is a computational task of exascale proportions, requiring the performance of approximately 10¹⁸ floating point operations per second. Right now, climate modelers are beginning to grapple with petascale systems, built from tens of thousands of processors. But making good use of such a system is no easy matter as the evolution of efficient programming techniques has not kept pace with the growth of computing power, says Dave Bader of the Program for Climate Model Diagnosis and Intercomparison at Lawrence Livermore National Laboratory.

What makes coding a GCM a particular challenge, Bader explains, is the huge amount of information that must be continually and rapidly transferred among the model’s numerous components. On top of that, climate models generate large amounts of output data, and getting those results out of the program and into displays that users can make sense of is also challenging.

If the limiting factor in running a climate model on a multiprocessor system is inefficient communication of information within the program, then the amount of processing power dedicated to solving equations falls and the model fails to take advantage of the raw processing power available. “The programming model we use [now] is not viable anymore in the next couple of

is it better to compute
existing models in
finer detail, or to make
the models bigger
by adding more
scientific content?

generations of computers,” says Bader. The handful of vendors in the supercomputer market—IBM, Cray, and a few others—don’t devote as much effort as they used to in developing languages and compilers that serve scientific users, he adds, so that responsibility for such things falls increasingly on the shoulders of researchers at various laboratories working in partnership with the vendors.

The drive for programming efficiency has changed the way climate scientists work. Meehl says that when he started in the 1970s, scientists would “fiddle with Fortran code, submit it to the machine, and it just ran. We didn’t have to think about it a whole lot.” Now, though, the team behind NCAR’s Community Climate System Model (CCSM), a state-of-the-art GCM used by researchers across the U.S., includes a working group of software engineers dedicated to ensuring the code runs reliably and efficiently.

Still, there’s room for innovation. “I actually do a fair amount of my own code work, by the seat of my pants,” says Kirtman. His programming may be inefficient and prone to failure, but that’s not important while he’s developing it, Kirtman says. To get his new work on ocean-atmosphere interactions incorporated into the CCSM, he turns it over to software engineers who transform his pilot program into a robust piece of modeling that any researcher can download and use. That’s something he couldn’t do, Kirtman says, and the net result is “I get a lot of feedback from people who are trying to apply my methods to their problem—that’s really powerful to me.”

 

David Lindley is a science writer and author based in alexandria, Va.

Network Architecture
Inside
Internet
Hardware

the idea was simple, only no one thought it was attainable. Surely network hardware companies would never allow outside researchers to access their equipment and established installation, right?

Not so, according to Technology Review, reporting on a project called openFlow that has opened some of the most commonly used network hardware from companies such as cisco, hewlett-packard, Juniper, and Nec. a team of researchers, led by Stanford university’s Nick McKeown, has been given unprecedented access to Internet hardware and an opportunity to improve the Internet’s security, reliability, energy efficiency, and pervasiveness.

“In the last 10 years, there’s
been no transfer of ideas into
the [Internet] infrastructure,”
said McKeown, a professor
of electrical engineering and
computer science. “What
we’re trying to do is enable
thousands of graduate students
to demonstrate ideas at scale.
that could lead to a faster rate
of innovation, and ultimately
these ideas can be incorporated
into products.”
the Stanford team secured
permission from major equip-
ment vendors to write a small
amount of code that grants
access to the flow table. When
a packet of data arrives at a
switch, for instance, software in
the switch looks up instructions
on the flow table to decide where
to send the packet. openFlow
essentially offers direct access
to the flow table to add and
delete instructions. as simple
as it sounds, McKeown explains
it has not been implemented
before because the prevailing
assumption was that vendors
would not open their hardware.
the Stanford team sees
the potential to open up the
airwaves, allowing portable
devices to access any wireless
network they can detect.
the goal, McKeown says, is
“seamless mobility. We’d
love to come up with a way to
rearchitect cellular networks.
But that’s further out. We’re
talking 10 years.”