BOULDER, Colo.—For almost five years, an international consortium of scientists was chasing clouds, determined to solve a problem that bedeviled climate-change forecasts for a generation: How do these wisps of water vapor affect global warming?
They reworked 2.1 million lines of supercomputer code used to explore the future of climate change, adding more-intricate equations for clouds and hundreds of other improvements. They tested the equations, debugged them and tested again.
The scientists would find that even the best tools at hand can’t model climates with the sureness the world needs as rising temperatures impact almost every region.
When they ran the updated simulation in 2018, the conclusion jolted them: Earth’s atmosphere was much more sensitive to greenhouse gases than decades of previous models had predicted, and future temperatures could be much higher than feared—perhaps even beyond hope of practical remedy.
“We thought this was really strange,” said Gokhan Danabasoglu, chief scientist for the climate-model project at the Mesa Laboratory in Boulder at the National Center for Atmospheric Research, or NCAR. “If that number was correct, that was really bad news.”
At least 20 older, simpler global-climate models disagreed with the new one at NCAR, an open-source model called the Community Earth System Model 2, or CESM2, funded mainly by the U.S. National Science Foundation and arguably the world’s most influential climate program. Then, one by one, a dozen climate-modeling groups around the world produced similar forecasts. “It was not just us,” Dr. Danabasoglu said.
I’m glad I’m not the only one who frequently comes up against the “NetCDF must be built with the same compiler as your code” issue! I hadn’t fully appreciated the reason why before seeing this nice description though.
NetCDF must be built with the same Fortran compiler as CESM. In the netCDF build the FC environment variable specifies which Fortran compiler to use. CESM is written mostly in Fortran, netCDF is written in C. Because there is no standard way to call a C program from a Fortran program, the Fortran to C layer between CESM and netCDF will vary depending on which Fortran compiler you use for CESM. When a function in the netCDF library is called from a Fortran application, the netCDF Fortran API calls the netCDF C library. If you do not use the same compiler to build netCDF and CESM you will in most cases get errors from netCDF saying certain netCDF functions cannot be found.
@samharrison7 - The issue is not with the C-interoperability part of netCDF. Its with the incompatability of the module file formats used by different Fortran compilers. The current netCDF Fortran API is composed of two different parts. The first is a set of Fortran 90 compliant software that gets included into modules. The second is a set of Fortran 2003 C-interoperability software that was written to replace old C wrappers that were generated by a C macro file (the resulting code was C). I wrote the original version of Fortran 2003 C-interoperability part of the netCDF Fortran API (started around 2005 and worked on it off and on for several years). UCAR adopted my code as a replacement for the C based interfaces around 2013. I’m not sure if you can compile and link non-module code compiled with gfortran into an Intel program but if you can, it should be possible to call my code directly. However, you will be stuck with what looks like the old Fortran 77 compliant C based interfaces. One of these days I might try to implement my own OO based API but I just don’t have the time now.
Edit
Also, I should have mentioned that the F90 interfaces call the F2003 C-Interop routines. The C-interop software replaces the old C based F77 interfaces. Also some parts of my code are approaching 17 or so years old and need to be refactored to correct some poor design choices I made back then
