From Gary Strand, software engineer at the National Center for Atmospheric Research (NCAR) commenting on Climate Audit:
As a software engineer, I know that climate model software doesn’t meet the best standards available. We’ve made quite a lot of progress, but we’ve still quite a ways to go.
I’ll say. NASA GISS model E written on some of the worst FORTRAN coding ever seen is a challenge to even get running. NASA GISTEMP is even worse. Yet our government has legislation under consideration significantly based on model output that Jim Hansen started. His 1988 speech to Congress was entirely based on model scenarios.
Do we really want congress to make trillion dollar tax decisions today based on “software [that] doesn’t meet the best standards available.”?
There’s more. Steve McIntyre comments:
Re: Gary Strand (#56),
Gary, if this is what you think, then this should have been reported in IPCC AR4 so that politicians could advise themselves accordingly. I do not recall seeing any such comment in AR4 – nor for that matter in any review comments.
Steve McIntyre July 5th, 2009 at 7:49 pmRe: Gary Strand (#56),
If we can convince funding agencies to better-fund software development, and continued training, then we’ll be on our way. It’s a little harsh, IMHO, to assign blame to software engineers when they’re underpaid and overworked.
Boo-hoo. Hundreds of millions of dollars, if not billions of dollars is being spent. PErhaps the money should be budgeted differently but IMO there’s an ample amount of overall funding to have adequate software engineers. Maybe there should be some consolidation in the climate model industry, as in the auto industry. If none of the models have adequate software engineering, then how about voluntarily shutting down one of the models and suggest that the resources be redeployed so that the better models are enhanced?
I’m not making this QOTW to pick on Gary Strand, though I’m sure he’ll see it that way. It is a frank and honest admission by him. I’m making it QOTW because Gary highlights a real problem that we see when we look at code coming from NASA GISS.
But don’t take my word for it, download it yourself and have a look. Take it to a software engineer at your own company and ask them what they think.
GISS Model E global climate model source here
GISTEMP (surface temperature analysis) source here
Sure, this is one of many climate modeling software programs out there, but it happens to be the most influential, since GISS and GISTEMP are the most widely cited outputs in the popular media.
U.S. industry seems to do a better job of software development than government programs, because in business, if something doesn’t work, or doesn’t work well, contracts get lost and/or people get fired. There’s consequences to shoddy work.
In academia, the solution is usually to ask for more grant money.
The difference between a natural scientist or engineer (non-software) and a computer scientist:
A natural scientist or engineer will get bad code to compile and get some sort of output then declare a scientific conclusion based on this.
A computer scientist understands there is more to it than that.
Too true! I have run into this time and time again. I cannot count the number of people I have encountered that have Masters Degrees in Computer Science that are either complete hacks, or simply don’t know their rear end from a hole in the ground. Always makes me laugh. Want to impress me? Don’t show me your papers, that won’t do it…
Lee (08:22:00) noted: “The last piece of code that worked without any unexpected errors was;
10 Print “Hello”;
20 Goto 10
But I thought it has already been agreed, Lee, that the “10” was a typo as it was meant to have been “Hell”?
I would have to agree with this. I personally attended a University, 4 year Bachelor of Science degree, from an accredited engineering and agricultural research University. Many of my courses shared those with EEE students (Electrical and Electronic Engineering), especially Mathematics, Physics, Chemistry, etc… Our “Computer Science” curriculum was very much in line with the Engineering disciplines. I do not consider MIS degrees and all their various permutations, any where near to the class of a real CS degree from an engineering College or University. They simply are not compatible with one another. Perhaps this is where part of this breakdown is when using the term “Software Engineer”. There truly are “Software Engineers” out there (I am one). I would say this is far more the exception than the rule when speaking in general terms of “Software Development”. There is definitely a very sharp contrast between a “Software Developer” and a “Software Engineer”. The latter requires a much larger toolbox. Incidentally, my personal professional title is, and has been for a long time, Sr. Software Engineer. This same title has followed me for many years, even throughout my years working government entities as the DOD, DHS, Pentagon, Navy, and various defense contractors.
Precisely!!!! You could not have said it better. I cannot count the number of times I have had to remind people that any computer program, computer programming language, etc… IS JUST A TOOL! And like any tool, can be used properly or improperly. The term “use the right tool for the right job” comes to mind…
We really have been to this movie before.
The Strategic Defense Initiative ‘Star Wars Project’ of Pres. Reagan suffered perhaps its most serious blow when:
“On June 28, 1985, David Lorge Parnas [link] resigned from SDIO’s Panel on Computing in Support of Battle Management, arguing in 8 short papers that the software required by the Strategic Defense Initiative could never be made to be trustworthy and that such a system would inevitably be unreliable and constitute a menace to humanity in its own right.”
see: http://en.wikipedia.org/wiki/Strategic_Defense_Initiative
Remember? We could not show, using computer science protocol already well-established more than 30 years ago that the code-base for SDI could meet a “necessary and sufficient conditions” mathematical analysis. [This is an example of what “software engineering” really is/is about, and is at least roughly analogous to finding the harmonic modes of Galloping Gerdy, before it falls into the Tacoma Narrows).]
see: http://en.wikipedia.org/wiki/Necessary_and_sufficient_condition
The SDI code-base made today’s NASA GISS model E, GISTEMP et al look like a school teacher’s classroom management program. We were capable of using mathematical logic to determine whether the SDI software was actually internally consistent & coherent … and could show rigorously that it was not.
====
There is nothing inherently wrong with Fortran. On the contrary, Fortran work is currently important: it is still the Speed-King of high-level languages, and in plenty of ‘raw-computing’ applications, maximum computation speed is absolutely the bottom line.
There is also nothing inherently wrong with old algorithms/routines. The vast majority of all the algorithms we use are, unavoidably, old. There is actually an advantage to using Grandpa’s code-routine, since it has been hammered/tortured in more ways than some new-fangled method.
The problems with Model E, GISTEMP, etc code-bases aren’t that parts of it are in [guffaw!] Fortran (there is a modern-language conversion-effort underway), or that the routines are [hoot!] 3 decades old, but that these code-bases are not being managed/maintained appropriately.
Why not? Why isn’t this stuff taken care of properly, or subjected to analysis-procedures that can *prove* whether it’s water-tight or not? Because key people don’t care. Because at the levels that count, it’s not important. Remember, Congress cared whether SDI software produced GIGO, or actionable conclusions. Neither Congress nor the White House care if the GISS codes make good sense or not.
Key climate/weather data/analysis is performed by Pentagon & Intelligence departments & agencies. NASA/GISS is a dog & pony show without weight or leverage. Nobody particular cares if their software can even run, much less can be used to say anything verifiably scientific.
The President pays no attention to the NASA/GISS climate work, but he consults with the Pentagon liaison daily. NSA hovers just off his elbow, ’round the clock. Despite Dr. Hansen’s finest theatrics and personal letters to the White House and other Heads of State, Pres. Obama studiously ignores him.
NASA’s climate-work is sub-par, and redundant. Even if their efforts were well-managed, they are woefully antiquated (20 years behind Pentagon/NSA) and under-staffed/funded (by orders of magnitude), compared to the military and intelligence projects that our top leaders actually use to make ‘best-science’ decisions.
It is full of RATFOR. I haven’t seen RATFOR since the 80’s. If you are still coding in FORTAN much less RATFOR you probably should look to retire. FORTRAN is still a little faster than C++ on the numerical calculations but given multi-threading, etc. It gets blown away. This thing is junk. It’s full of arcane crap that that ensures job security. If Milton from Office Space were a programmer, this would be his work. I remember a guy who worked maintaining listing for the Yellow Pages. Back when large drives were measured in megs, he built a several gig flat file database. Trouble was he used to drop acid when he coded. No one could figure out how it worked. That said, I think his code was better than this garbage.
It is typical government coding. I advocate that we spend some of the stimulus money to get them Fisher Price keyboards. That way they can think that they are working, but not cause any real harm.
I was discussing some of these things with one of my software developers today. A major function of our job includes the translation of human processes into computer processes. There are engineering aspects to this, there are also creative aspects to this. These translation processes are not blank and white and can sometime require drawing from a vast array of disciplines and experience. Again, in this arena, I am rarely impressed by someones paperwork. Some of the best software developers and software engineers that I have met, have been your classic academic rebel (I being one of those), and rarely posses impressive credentials. Books are one thing, practice is another.
Agreed.Numerical coding is a bit different from systems coding, however. Without a good background in math or applied mathematics, model coding tends to go astray. It should be noted, however, that 80% of the work in most models is the shuttling, reading and formating of data. Numerical programmers tend to be lousy at that work, as evidenced by this code.
Did you read any of this stuff? It’s like steam-punk coding. I feel like I should get out a leisure suit to look through it. I realize that it’s government and they can’t afford anyone of quality, but is this some kind of retirement program for failed programmers?
I would agree, as FORTRAN is just another tool. Is it really the speed king? I would argue with that. C or C++ typically compiles to much more efficient assembler code than does FORTRAN. Further, some versions of Pascal compile to even more efficient assembler code, one of the best being the good old Borland Turbo Pascal, which would compile to about the same compact and efficient assembler code as C/C++, but had the speed advantage of passing parameters through registers rather than pointers to memory heap allocations. Borland Pascal used a very efficient way of utilizing registers and stacks rather than heap memory allocations. I am not saying that FORTRAN is poor, it is not, but I don’t know that I would give it the blue ribbon for efficiency either. I spent several years hand optimizing assembler output from a variety of source compilers and in my experience, C/C++, Pascal and even Modula II typically out performed most all other languages. Metrics from clock cycle testings and audits would confirm this at the time.
If I were to build a climate model:
Personnel ==
1) Gather up the brightest minds in physics, chemistry, climatology, all the necessary science disciplines required to understand the physical processes involved.
2) Gather up a good team of “Software Engineers” to design and develop the technologies to be applied and how to apply them. Use the engineers to “engineer” the development processes, application architecture, integrations, etc…
3) Gather up a strong team of “Software Developers” (ie; coders) capable of witting quality code, implementation, and unit testing individual portions of tasking as designed by the “engineers”.
4) Gather up a strong team of “translators” or “communicators” capable of communicating between the “scientists” and the “engineers”. Software engineers and physics scientists don’t speak exactly the same language, assistance is needed here to translate one discipline to the other. I would employ a team of people skilled at this practice.
Processes (SDLC) ==
1) Engage a peer review coding cycle processes
2) Engage proper source control management processes
3) Engage proper QA/QC and validation processes
4) Engage proper release management processes
Last I checked FORTRAN was still faster on certain numerical calculations, but I agree with you. Who cares on such small differences. The big issue here is maintaining and working with the code. This is classic FORTRAN full of cryptic variable names that are less than 8 characters. It really is old school. How do you even verify that this code is performing correctly. It is over 100,000 lines. No unit tests, no subroutine test drivers. It would take a long time to get your head around all the interactions in the sub-models. One good advantage is that it has formating for line printers. So it’s got that going for it. Which is nice.
Jim (18:57:06) :
Allan M R MacRae (18:24:23) : I’m glad you brought up aerosols. Something has been bothering me. The alarmists say aerosols cool, but some clouds warm. But, isn’t a cloud in fact an aerosol? The particle size can vary from the CN to a large hail stone, but most of it is an aerosol, no? If aerosols cool, shouldn’t also clouds that have not progressed to precipitation. (I realize clouds bring a lot more to the table that that, but the aerosol thing has been bothering me.)
________________
Good questions Jim, and we need someone better qualified than me to adequately answer them. Maybe Doug Hoyt will step in.
According to Wiki, I guess you are correct – clouds are aerosols:
“Technically, an aerosol is a suspension of fine solid particles or liquid droplets in a gas.”
I have read much about clouds and aerosols, and my impression is that the two are generally considered as different categories for climate model purposes.
Clouds can form from water vapour, a potent greenhouse gas, and vice versa, so clouds could exhibit more complex behaviour in this regard than other aerosols.
I have also read that high-level clouds and low-level clouds can have opposite effects wrt warming and cooling. This I have to take with the usual grain of salt, as I haven’t read much that supports these views.
I guess you are aware of Svensmark’s hypothesis that cosmic rays seed low-level(?) cloud formation, causing cooling. I can accept that low-level clouds cause cooler temperatures than would occur under clear skys during daylight, but it seems to me that at night the low clouds trap heat and reduce the rate of overnight cooling.
Aerosols from major volcanic eruptions are known to cool the Earth, and these consist of sulfates, particulates, etc.
All this is rank speculation on my part as I have no time to prepare a proper response. I’ll ask Doug Hoyt if he wants to comment.
Back in the mid 80’s, I was briefly involved in a project with the Chem. department or my University, and one of their research projects. The Chem. dept. is infamous for gobbling processor time on any machine. They were frequently awarded grants from IBM that included the use of newly developed technologies (ie: super computers) of the time. One such computer was the IBM 9000 series Vector Processor machine. My role was to assist in the performance optimization of critical computational components. All of the original code was written in FORTRAN. To achieve our goals, we broke out critical portions and rewrote those components using C which incorporated a lot of hand optimized in-line assembler code. Our results were rather astounding, with an average performance improvement of around 1700-2000%. This was pretty significant. In this example, I would say that our C implementation blew away the computational performance of standard FORTRAN, but to do so wasn’t exactly easy either.
There are two core problems here. The first is triage. Get this POS cleaned-up. Break the data from the model. Separate data layer from model layer and from the results layer. This work is straight-forward but dull has hell. A few days in you’ll be using the Clockwork Orange eye openers to keep going. It is a necessary first step, however. get it stabilized and documented. I realize that a good deal of documentation exists, but unit tests and regression testing on the model components needs to be in place. There really is nothing quite like a large-scale, non-linear model without regression tests.
The second stage can follow traditional development techniques like you have outlined above, but you have to get this thing into a malleable form.
Squidly (23:13:27),
Yes, I swung the praises of Fortran just a bit wide. 😉
To go on & on in Fortran for housekeeping chores isn’t nice. I perused the NASA Model E upgrade project pages about 6 months ago, and saw that a major problem is the use of cryptic, short variable-names. Git out!? Now, that’s a maintainance chore that shoulda got done about a standard career back.
For the most part, Fortran is only going to be ‘in the way’, agreed. Where the aim is to really come to grips with Formula Translations, though, it might have an edge (not that Models, as noted, are doing computationally/numerically-limiting stuff in most of the routines). And, I’m not as current on language-issues (a socially-acceptable 20th C. substitute for religion-arguments? 😉 as I would have been a decade (2?) back…
But I do see on the handiest reference:
“Since Fortran has been in use for more than fifty years, there is a vast body of Fortran in daily use throughout the scientific and engineering communities. It is the primary language for some of the most intensive supercomputing tasks, such as weather and climate modeling, computational fluid dynamics, computational chemistry, computational economics, and computational physics [5 links]. Even today, half a century later, many of the floating-point benchmarks to gauge the performance of new computer processors are still written in Fortran (e.g., CFP2006 [link], the floating-point component of the SPEC CPU2006 [link] benchmarks).”
http://en.wikipedia.org/wiki/Fortran
Like Burke (23:27:06) says, for the right crunch-jobs, it’s evidently still it.
Yes, a climate-modelling team-approach like you describe, or a modern-Celtic OSS approach could rapidly put the computational/modelling portion of climate-investigation (it still needs a huge, ongoing investment of actual, physical science) on a good footing. Dr. Hansen is stuck in a (faulty) loop.
“In addition to being complex the climatology models are – and are supposed to be – constantly changing as they learn more of the natural forcings at play. To suggest they should be required to stop now and re-write the code from scratch is… shall we say… not very reasonable.
Pete”
Wow…. Pete, do you really believe that just stacking more useless wrong data on top of bad code, on a already WRONG Theseus is the correct thing to do? I mean Wow…..
You say that code will change with more knowledge on natural forcings……… well if the forcings are not known by any person on this planet at the time of the code writing, how do you compensate for that big of error in knowledge of the code?
eg.. If the earth is said to be flat after extensive scientific study, and then proved wrong, how do you think you might adjust to that realization?….. Hmm, my question…… shall we say… not very reasonable.
“The models they are working with appear to have been proven fairly accurate over the last 20 years. This video contains some historical perspective of climate models;
Pete”
The bottom line Pete, modeling climate is delusional and that video is a crock. You say models have been accurate for 20 years, but not one predicted the cooling that has been going on in the last 10+ years and ZERO mention of a one whole degree of drop in mean temperatures in the last 3 years.
Really, a heating of .7C in a century and then a drop be 1C in the last few years is a big forcing.
Sooo, out of control CO2 heating doesn’t seem to exist, but in a computer model.
Phillip Bratby (09:46:34) : My experience of Fortran coding from many years ago was that to make sense of it and for purposes of verification, somewhere between 20% and 50% of the code should be comments. Without having the time to look at the code, can anybody tell me how much of the code is made up of comments?
Well, nearly zero.
Taking Step2 as an example, it has about 1319 lines of code (the result of:
$:~/WeatherModels/GIStemp/STEP2 chiefio$ cat * | wc -l
1319 ) of which 15 have a leading “C ”
$:~/WeatherModels/GIStemp/STEP2 chiefio$ !! | wc -l
grep “^C ” * | wc -l
15
And just to show you how helpful those 15 lines are, here they are:
PApars.f:C *** unit#
PApars.f:C *** Input files: 31-36 ANN.dTs.GHCN.CL.1 … ANN.dTs.GHCN.CL.6
PApars.f:C ***
PApars.f:C *** Output file: 78 list of ID’s of Urban stations with
PApars.f:C *** homogenization info (text file)
PApars.f:C *** Header line is added in subsequent step
PApars.f:C KM = the number of time frames per year
PApars.f:C 121 LEN(IS)=ILSR(IS)-I1SR(IS)+1 ! (counting gaps also)
invnt.f:C WRITE(6,*) ITRL(3),INFO(6)+IYR0,INFO(6)+IYRL-1
text_to_binary.f:C print*, line(1:64)
text_to_binary.f:C print*, line
toANNanom.f:C do i=1,ndim
toANNanom.f:C write(*,*) i,idata(i)
toANNanom.f:C end do
toANNanom.f:C if(ndim.gt.0) stop 11
As you can see, the bulk of them are chunks of commented out code…
IMHO, having read all of the GIStemp code, it is crap. The comments are at best unhelpful. It is a “hand tool” that expects manual intervention at several points. It is NOT a production product and I would fire the person who came to me with this level of code and said they were ready to ship. (I have managed production of software before and shipped product repeatedly, including the compiler tool chain for GNU aka RedHat…)
Oh, and to the guy who said software writers are not engineers: Please talk to the the ENGINEERING department that awards ENGINEERING degrees in Computer ENGINEERING at major universities… My Computer Science friends with ENGINEERING degrees from places like U.C. Davis, UCB, UCLA, Stanford, and CalPoly S.L.O. would not agree with you… nor would I, having employed said engineers to write code in the Engineering Department at a couple of name companies that created the computers you use… One of my engineer friends wrote the software that lets the B1B fly (his code controls the tail surfaces). You don’t think that’s engineering? Try flying the B2 without the software… (HINT: You WILL crash. Fast.)
Back on the “hand tool” style of GIStemp. From STEP4_5 we have:
$:~/WeatherModels/GIStemp/STEP4_5 chiefio$ grep comment *
do_comb_step4.sh: echo “or do all compilation first and comment the compilation lines”
do_comb_step5.sh: echo “or do all compilation first and comment the compilation lines”
trimSBBX: echo “or do all compilation first and comment the compilation lines”
zonav: echo “or do all compilation first and comment the compilation lines”
Notice that this says to do things “by hand” if you like and comment out chunks of code that you don’t like… This is NOT production style. This is what is commonly called a “Kludge”.
George Tobin (09:01:16) : I was unaware that any blame had been directed at GISS software engineers. My understanding was that they were faithfully implementing the bogus sensitivity assumptions and all the rest of that which comprises current climate modeling ideology.
George, you are laboring under the assumptions that the code was written by a software engineer and that there was a division between the designer and the coder. The code looks to me like it is largely written by folks who learned programming as a sideline or “had a class in it” not by professional programmers. (Yes, anyone can learn to program just like anyone can learn to write poetry… that does not make you a professional programmer nor a good poet…)
I’ve read GIStemp front to rear. It looks like it was written by folks who had a FORTRAN class once, years ago (I would guess some of it was written by Hansen himself decades ago…) and do not make production product for a living. It also has “layers” that look like kludge added on top of kludge over time. Some blocks are ALL CAPS and look like F77 style (and syntax). Other newer chunks are mixed case and F90 style. In short, “it just growed” is how it looks. There are exceptions. The Python chunk is more professionally done and looks like it was contracted out to a sub.
But most of it, frankly, looks like someone who learned BASIC and then took a FORTRAN class made a hand tool. Specifically, all the FORTRAN is compiled in line, run, then deleted. It is treated as an interpreted language.
What few comments there are indicate that the pieces are to be run by hand as you see fit and that if you want to edit the code to change it, well heck, why not! Work files are scattered around in the source “archive” willy nilly and the data files constantly mutate name and function from piece of code to piece of code. Nothing prevents or even encourages preservation of the source code during operation. What part is run in what order is also left as an exercise for the student…
I am inclined not to read much into this fellow’s candid assessment. And I think Steve M. was a little over the top implying that the programmer should have communicated his misgivings about the models to IPCC, Congress and the media. The guy who has to translate crappy assumptions from higher higher into workable code should not have to field that kind of issue or get caught in the middle.
While I generally agree with your sentiment, you are assuming that there was a division between the designer and the coder. It looks to me, from inspection of the code, like it was written by the “designer”… in which case one can not expect much in the way of a mea culpa from Hansen…
John Galt (10:30:55) :
Rod Smith (09:48:05) : And why is anyone still coding in Fortran?
I asked that question about FORTRAN previously and was roundly spanked by people who informed me that FORTRAN is still used in the engineering field and is also commonly used on supercomputers.
I can only assume Fortran is equally prevalent in science as in engineering. I still question why a more modern, object-oriented language such as C++ (or even Java) isn’t used. Is FORTRAN mult-threaded?
Having lived through several “language wars” and written code in more languages than I can remember, I have an opinion about computer languages:
IT DOES NOT MATTER.
All that matters is that the person writing the code is competent in the language.
I’ve worked in BASIC, COBOL, FORTRAN, PL1, Pascal, C, ALGOL, several “non-procedural database languages”, several scripting languages on Unix / Linux machines, programmed several varieties of routers including CISCO in two major variants of their OS, a couple of different assembly languages, and have read Python in GIStemp. Oh, and I once learned APL just to see what it was all about and wrote a few programs in it. It deserves the descriptor “write only language”… And I’ve coded some RPG once too. There are a few others but they don’t float to the top of the memory stack right now… like FORTH that I learned once eons ago…
At the end of the day, you can write good code in all of them and you can write crap in all of them. Some are a little easier to use for some tasks, but an experienced programmer in any of them can use that tool to run rings around an inexperienced programmer in any language.
I managed a supercomputer site at one point in my career. FORTRAN was exceptionally optimized on it at that time and C was a new port (mid ’80s). While we wrote a lot of code in C on the Cray, if you had something that really needed to be fast, you used FORTRAN. I doubt if that has changed, simply because there has not been as much money in supercomputers in the 20 years since then (to fund the very large staff needed to make a truly stellar C compiler that would match what had been done with the FORTRAN compiler) as was done in prior years with FORTRAN.
I’m also told some versions of FORTRAN have object-oriented extensions, but they aren’t commonly used.
Having managed a software development that lead to 4 software patents and was written in C++, I still have to say that IMHO object-oriented is somewhat over hyped. Yeah, it’s “neat”, but not exactly something that obsoletes everything written before… It’s just another “neat trick” that makes some things easier and some things harder. Good to have if you need it, irrelevant if you don’t need it, and not NECESSARY if you have a non-object oriented language and a programmer skilled in it. Everybody thinks their favorite language or feature is the big deal. It isn’t. It’s what you can do with the hammer that matters, not whos hammer is bigger…
If software engineers are in short supply, that’s a sign that NASA needs to migrate to a more contemporary system. Last I heard, there were a lot of layoffs in the IT field. Surely there are some out-of-work computer science majors who would love to work for GISS?
I’d love to get a job re-writing GISS code, but I wouldn’t want to work for Hansen… That said, why would a shortage of engineers argue for a conversion effort that would require hiring more engineers?… It takes fewer engineers to just leave it alone and run it once a month…
But the problem I see in the code is not just the way it is written. The bigger issue is that it makes bogus assumptions. Things that are demonstrably wrong. One example:
GIStemp assumes that a station 1000 km away can be used to fill in missing data from another station. I can assure you from a half century of personal experience that not only can you NOT use the San Francisco temperature data to fill in for Lodi, but the two are INVERSELY related in summer. The central valley of California heats up, the updraft pulls ocean cool air over SF and brings the fog in. When Lodi gets hotter, SF gets colder and danker.
But this “pump” works with a 3 to 4 day cyclicality and with variable time delays between the inland heating and coastal cooling… so you can’t just assume a naive relationship. It changes dynamically (and GIStemp makes no allowance for this).
Does anybody know the hardware and OS GISSTEMP runs on?
I don’t think it matters. It needs an F90 compiler. After that the OS and hardware are not very important. The quantity of data and the operations done could be easily handled by a modern PC. It’s pretty simple processing.
My GUESS would be that it runs on a UNIX workstation, probably a Sun of some sort. I saw no “Crayisms” in the code and nothing tied to a particular platform. It also was blissfully devoid of Micro$oft isms…
Last time I was at NASA was a while ago, but then they had Crays, SGIs, Suns, and PCs (and I think there where some HP boxes too). Being a government agency they probably have whatever the lowest bidder offered last cycle… I think everything has to either be POSIX or MS Windoze …
The way it is written ought to be independent of the OS or hardware. There were no “endian” problems AFAIK and they didn’t use much in the way of fancy coding techniques (ie. nothing proprietary). To that extent they did a good job…
Dave Andrews (14:39:07) : The discussion you recall may be this one
http://www.thebulletin.org/web-edition/roundtables/the-uncertainty-climate-modeling#
Yes thanks that’s the one. Whilst they are open about limitations, I get the feeling that they just want to continue building models. That’s just what they do. The comment about how they already know with certainty that CO2 causes warming, and is as certain as knowing that a cup falling to the floor will shatter, therefore we must “leap” out of the way, we must act, regardless of what else models may tell us, is an interesting take on things. It suggests that models are just research curiosities. The ones that output significant warming are of course newsworthy, like any techy gadget can be newsworthy, but they are not the original proof or basis for global warming. That, as they say, was already known with certainty.
Like a shell game, in global warming/climate change we’re still left wondering where the real ball is.
I’ve just been looking at some of the GISS Code and it is schoolboy stuff from a software point of view. I did a quick Lines of code count and it appears that GISS believe that the earth’s climate can be accurately simulated with only 100,000 lines of badly written Fortran. When you consider that windows Vista has 50 Million lines of code it makes you wonder how something that is orders of magnitude more complicated than the climate, could ever be expected to boot up, let alone do anything else.
I don’t think it would matter much in the end if the climate models were completely rewritten from scratch in the best and most modern code available. The end results would still be the same, i.e., the global temperature, CO2, sea level, glaciers, Arctic ice, Antarctic ice etc. would still be rising, rising, rising, melting, melting, melting respectively at even faster rates than they had previously thought (modelled).
So if it ain’t broke… Everything’s hunky dory. What temperature do you want? What sea level rise do you want? Etc, etc…
You should see some of the awful FORTRAN code still used and maintained to do attitude determination, orbital mechanics, guide star occultation, etc. for spacecraft. Complaining that past coding doesn’t meet current standards is just plain silly. As long as it ‘works’ for the primary user, redoing it is just bad engineering (if ain’t broke and all that). Any disagreement with the definition of “works’ has little to do with the ‘quality’ of coding.
Gary was trying to defend what he does for a living. Why, I’m not sure. He calls himself a ‘software engineer’ but is not necessarily any more an ‘engineer’ than a ‘building maintenance engineer’. His ‘admission’ is at about the same level as that of a building maintenance engineer’s admission to the sad state of architectural design. Ho hum.
Should the climate models be used for trillion dollar decisions? Of course not! But for far better reasons than crappy, hard to follow code. Let’s focus on the real issues instead of peripheral ad homs like ‘crappy code’.
Move along people. There’s nothing to see here.
The trouble with models is that they are pseudo-quantitative. Numbers are based on qualitative judgements.
Would be better if they used a true qualitative approach such as hazard and operability [hazop] studies where experts and interested parties talked through the issues in a semi structured way. Not dissimilar to a blog really.
cheers David