Another NASA/GISS ModelE Code Fragment
Using the NASA/GISS ModelE code browser I ran across the MODULE CONSTANT in which several constants are setup as parameters.
The following code fragment is also in the routine:
!@param shv specific heat of water vapour (const. pres.) (J/kg C)
c**** shv is currently assumed to be zero to aid energy conservation in
c**** the atmosphere. Once the heat content associated with water
c**** vapour is included, this can be set to the standard value
c**** Literature values are 1911 (Arakawa), 1952 (Wallace and Hobbs)
c**** Smithsonian Met Tables = 4*rvap + delta = 1858–1869 ????
c real*8,parameter :: shv = 4.*rvap ????
real*8,parameter :: shv = 0.
The variable shv that is set to 0. appears in a few lines of code in routines SURFACE and DIAG. The former routine was the subject of this post.
The inline comments about shv in the coding seem to indicate that the NASA/GISS ModelE numerical solution methods fail to conserve the thermal energy associated with all the physical fluid components that are attempted to be modeled. Because of the lack of concise documentation for the NASA/GISS ModelE models and methods it is not possible to fully understand why accounting for the sensible energy content of water vapor could cause such a major problem.
This situation is in direct contrast to the impression offered by the IPCC that the GCM models are based on the fundamental principles of conservation of mass, momentum, and energy.
But the situation is completely consistent with this post. That is, the model for ‘conservation of energy’ used in AOLGCM codes does not account for and provide for conservation of actual real-world thermal energy. Only a hypothetical model for thermal energy conservation is employed in GCM codes. The calculated internal state of the system being forced by energy addition will very likely encounter states that do not correspond to the state of the physical system. And even if a model equation that corresponds rigorously to the physical world was used, the lack of convergence of the numerical solution methods automatically imposes a lack of conservation of energy that would correspond to the actual physical situation.
When modeling and calculations of the temperature of a complex system is the analysis objective, conservation of thermal energy is a really crucial requirement.
The inline comments about shv also indicate a mysterious lack of understanding of where to find numerical values for the basic fundamental thermophysical properties of water vapor. Other comments, and numerical values of fluid properties set in MODULE CONSANT, indicate that many (maybe all) of the transport properties are set to constant approximate values for standard atmospheric pressure at 0 Celsius.
As an aside, the following lines of code in routine DIAG illustrate the new and innovative ways provided by F90/95 to produce inactive code:
! * *HSCALE*LOG(P(I,J)/PMID(L,I,J)))
This F90/95 approach to inline code documentation will surely lead to future problems. Also note that it costs as much to maintain a line of inactive code as it does for a line of active code. But in the case of lines of code like the above, it will very likely cost more because time will be spent in efforts to find out if the more or less hidden method of ‘commenting out’ code is a mistake or was actually intended. More likely, a non-zero value will be set for shv in MODULE CONSTANT above and the statements in DIAG will not be corrected to make them active. This is a very messy situation that should never have arisen.
Looking around in the SURFACE routine I find 29 lines of code that have been commented out by a ‘c’ in column 1.
Update january 28, 2008
While reading Stoat, Only In It For The Gold, and Bryan Lawrence over the weekend I was struck by the following fact. Languages don’t write bad coding, people write bad coding. In some case, as shown in the post, very, very bad coding. There is absolutely nothing in any version of the Fortran language that compels that constructs such as shown above be used. They are entirely the result of people writing bad code. And that is possible in any language. Additionally, some languages allow constructs that seem to encourage building code that is almost impossible to understand.
There are a very large number of incorrect impressions given in the discussions on the blogs cited above. I will note only one at this time. Characterization of Fortran as a language from the 1950s is simply not correct. As all programmers who use the language know to be a true fact. Construction of data structures has always been possible in the Fortran language.
It would be interesting to check to see how many of the GCMs used in the various IPCC reports are written in a language other than Fortran. I’ll guess none are without even bothering to check.
Finally, the depth of the naivete relative to the tasks required to replace/upgrade very olde, very poorly constructed, undocumented, and yet very actively used, code displayed in the discussions in the blogs linked above is almost beyond description.