Pattern Matching in GISS/NASA ModelE Coding
In a previous post I gave an illustration of how GISS/NASA employees have implemented new and innovative ways to produce inactive code using the capabilities provided by F90/95. I had run across the following statements in routine DIAG.f:
! * *HSCALE*LOG(P(I,J)/PMID(L,I,J)))
The ‘!’ in the first line is going to be very difficult to remember it exists and correctly maintain. Someone might come along and say, “I wonder what that’s doing in the middle of an executable statement.” and promptly un-do the comment. Or un-do the comment of the second line while overlooking the comment in the first line. That would make a screw up on several levels.
Today I have found many more examples of innovative coding by employees of GISS/NASA. It is clear that the NASA Software Quality Assurance procedures are ignored by GISS/NASA. It is equally clear that there are no Software Quality Assurance procedures being applied to the GISS/NASA ModelE code. None.
Update November 2, 2008 down near the end.
Black box computer codes are universally acknowledged to have great potential for harboring inordinate numbers of bugs. But I had never seen anything like the above example of bad coding in my entire career. And believe me I have seen lots of bad coding. In my industry, legacy coding rules.
Recently I was thinking about that coding and said to myself, Hmmm … I wonder how many more applications of that particularly nasty application of code are in ModelE. I was thinking that I might have to try many arbitrary search patterns to run across even another single example. Imagine my surprise when the very first one I tried, ‘! +’ gave me 18 hits. Now some of these are in fact inline comments and do not affect the calculations. And in this case, inline means actually on the line of coding that performs calculations. Such comments are generally very much less than useful.
Here is an example of what that first EWAG search found, in routine SEAICE.f
C**** reconstitute upper layers
MSI1 = ACE1I + SNOW
IF (ACE1I.gt.XSI(2)*MSI1) THEN ! some ice in first layer
HSIL(1) = (HICE-FHSI2)*(ACE1I-XSI(2)*MSI1)/ACE1I + HSNOW
SSIL(1) = (SICE-FSSI2)*(ACE1I-XSI(2)*MSI1)/ACE1I ! + SSNOW
Those inline comments that modify the calculations are hard to spot, I think.
Well, given that this was much easier than I ever expected, I gave it another shot with ‘ !*’ and got 39 hits. Again some are actual comments, but the majority are not comments but instead modify the calculations. This search gave hits in the several versions of the CLOUDS_S12000 routines
C**** COMPUTE EVAPORATION OF RAIN WATER, ER
ER(L)=(1.-RHN)*LHX*PREBAR(L+1)*GRAV*BYAM(L) !*GbyAIRM0 ! GRAV/AIRM0
and here’s an example from GHY_DRV.f
ccc accumulate tracer evaporation and runoff
trevapor(n,itype,i,j) = trevapor(n,itype,i,j) + atr_evap(nx)
!trevapor(n,itype,i,j) = trevapor(n,itype,i,j) + aevap !*rhow
Actual blocks of comments that explain the modifications are not present in the code, but it seems to me that this change had a great potential to change the units for the aevap contribution. Apparently the coders were not so sure about this one either, because the entire line is also commented out. Makes you wonder the order of the modifications.
This was way too easy. So next I tried ‘! *’ and I got 20 hits. Here’s one from CLOUDS_S12000,f
RCLD=25.0*(WTEM/4.2d-3)**BY3 ! * 500./(pl(l)+500.)
and from GHY.f
c atr_g(:ntg) = ! instantaneous ! atr_g(:ntg) +
c & ( fb*( tr_w(:ntg,1,1)*(1.d0-fr_snow(1))
c & + tr_wsn(:ntg,1,1) ) !*fr_snow(1)
c & + fv*( tr_w(:ntg,0,2)*(1.d0-fm*fr_snow(2)) ! *fw0 !! remove fw?
c & + tr_wsn(:ntg,1,2)*fm ) ) / !*fr_snow(2)
c & (rhow * tot_w1) ! * dts
I love that one. Note that in the case of the line containing !*fw0 !!remove fw? there was a display of We don’t know what we’re doing. And in the last line the multiplication by the time step, dts, has been commented out. To be fair, note that all these lines have been commented out by the use of ‘c’ in the first column. Given the clear lack of understanding about the coding, that is very likely a good thing.
There is also an application in SUBROUTINE SPLN44
QK(K)=FFCUSP ! *CUSPWT+FFLINR*(1.D0-CUSPWT)
Next I tried ‘!+’ and got three hits that modify the calculations. One being the EWATER(j) case given at the top of this post. And this one also from DIAG.f
710 AJK(J,K-1,JK_TOTVTAM)=AJK(J,K-1,JK_TOTVTAM)+WU4I !+W4I*UEARTH
It looks like an error was discovered and fixed by this application. Again it seems that very likely the units could have been incorrect in the original coding. Or they may be incorrect in the modified coding.
And finally this one from GHY.f
! evaporation from the canopy
if ( process_vege ) then
ibv = 2
evap_max_wet(ibv) = w(0,2)/dt !+ pr ! pr doesn''t work for snow
So next I tried ‘! -‘ and got several hits that are difficult to figure out. For example, in ATMDYN_S12000.f we see:
do jk=iplimb+1,iplimt ! -1 ?????
Is that a correction to previous coding, or is it a question on the part of the person writing the code. Maybe they are hoping that the compiler will correctly figure it out.
And from GHY_DRV.f
c**** outside loop over time steps, executed nisurf times every hour
timez=jday+(mod(itime,nday)+(ns-1.)/nisurf)/nday ! -1 ??
yet additional sterling examples of certainty on the part of the code writers.
Well I could go on, but this exercise is getting to be just way too distressing to continue. Maybe you’ll fire up your favorite editor and look around in ModelE, too. You can get your personal copy from here.
November 2, 2008 update. I did two quick searches using ‘!/’ and ‘! /’ and got a few hits that modify the calculating. I’ll not give the details here.
There is probably a way to write a script that will find only the modifications that affect the calculations. Maybe I’ll give it a shot. My favorite scripting language for parsing strings is FORTRAN :-).
Additionally, I did several quick searches in the UCAR CAM 3.1.p2 source and did not get any hits. While looking through the coding, this code seems to be in far better shape than the ModelE coding.
I think I have been reasonable in all the posts on this blog. But I think these examples clearly illustrate an alarming lack of the most basic proper attention to the source of the numbers that are used in Climate Crisis analyses by employees of GISS/NASA. Actually I think this is bordering on being a national disgrace.
November 2, 2008 update. On second thoughts, it is a national disgrace. And, GISS/NASA doesn’t need “an extra thousand code checkers”, they need individual code writers that can follow the most simple concepts of writing reasonable code.