GIStemp STEP5 – the process

This is step 5

STEP5 Overview

STEP5 runs only one program of its own: SBBXotoBX.f from one script do_comb_step5.sh which is the top level controlling script. Strangly, the source code of STEP3 is repeated in full in STEP4_5 unchanged for no understandable reason. Those programs that are used here appear to be annzon.f, zonav and zonav.f as near as I can tell. The program trimSBBX was run in STEP4.
 

Sizes and Listings

 

Lets look inside STEP4_5 (the two steps live in one directory together…) for how big things are. Files ending in “.f” are FORTRAN program source code (that when compiled into something the computer can run gets the “.exe” executable binary suffix) while those ending in “.sh” are Unix / Linux shell scripts. Oh, and “*” is the “wildcard character” that says “match anything” so *smith would match “Goldsmith” and “Tinsmith” and… So just taking a look at the line count numbers for selected files in this step (cd STEP4_5, wc -l *) :

   Lines   Words   Bytes File Name

     434    1456   14828 SBBXotoBX.f
     247     851    8909 annzon.f
      38     154     991 do_comb_step5.sh
      35     102     881 zonav
     397    1556   13952 zonav.f
    1151                 total

 

For STEP5 there are about 1151 lines of code in total. I will be reviewing the actual code much more loosely than we did in the early parts, since otherwise the postings will get a bit long and we’ve seen much of it before. In particular: annzon.f, zonav and zonav.f were seen in STEP3.

 

Scripts:

 

Note – all FORTRAN is compiled to runnable binaries in-line in the scripts, executed, then the runnable binaries deleted. You would expect the human readable source code to be in a distinct archive, compiled to runnable binaries in a distinct program library once, and only deleted when a newer version had passed a Quality Assurance test.

One comment on style. I always learned that you created and used your work files in a work file directory; this code creates and uses them in the same directory as the program source code, then when done, moves them into a work directory. Not what you would expect.

There are two scripts. The top level controlling script, do_comb_step5.sh will be reviewed inline here. The “wrapper script” zonav that compiles the FORTRAN will be reviewed along with the programs it wraps.

zonav

This is called last in the do_comb_step5.sh process (it was first in STEP3). It compiles and runs zonav.f and also does some file housekeeping. Please note that zonav also compiles and runs annzon.f for no explicable reason. This breaks with the style of dedicated wrapper scripts.

do_comb_step5.sh

This is the start. It runs the show.

A Deeper Look at the Top Level Script

 

We will take a brief look at the top level controlling script do_comb_step5.sh and, after the listing of it, I’ll describe what it does.

Begin listing of “do_comb_step5.sh”:

#!/bin/ksh

fortran_compile=$FC
if [[ $FC = '' ]]
then echo "set an environment variable FC to the fortran_compile_command like f90"
     echo "or do all compilation first and comment the compilation lines"
     exit
fi

RLand=100 ; # up to 100km from a station, land surface data have priority over ocean data
if [[ $# -gt 0 ]] ; then RLand=$1 ; fi

i1="input_files/SBBX1880.Ts.GHCN.CL.PA.1200"
i2="input_files/SBBX.HadR2"

if [[ ! -s $i1 ]] then echo "input file $i1 missing"; exit; fi
if [[ ! -s $i2 ]] then echo "input file $i2 missing"; exit; fi
echo  'inputfiles: ' $i1 $i2

   mv $0.log out/.  2> /dev/null ;   mv BX.${1}x ../old/.  2> /dev/null
##  Input files:
ln -s $i1 fort.10
ln -s $i2 fort.11

$FC  SBBXotoBX.f -o to.exe
to.exe $RLand 0 > SBBXotoBX.log

##   Output files:

echo "The following file was created:"
echo "BX.Ts.ho2.GHCN.CL.PA.1200"
mv fort.12   BX.Ts.ho2.GHCN.CL.PA.1200

# Clean-up
rm fort.1[01] ;   rm to.exe

mkdir work_files 2> /dev/null
zonav  ho2.GHCN.CL.PA

 
End of script.

This script is once again Korn shell. It starts off with a check that the environment variable “FC” is set to your FORTRAN compiler. Given that we’ve seen f90 constructs in some programs and f77 explicitly called in others, it would be “nice” if they had settled on one and had a script that explicitly set the environment variable for you “up front” as part of the start of the show GIStemp run. Doing that would reduce some of the confusion and constant checking for what has / has not been done.

We set the default radius for land variable, RLand, to 100 km then check to see if we have been passed an override value. This is not the first time we’ve seen this. Any maps produced via the GIStemp code needs to inform you what choices were made at these “override” points or they will not be reproducible.

Next we set two input file names “i1” and “i2” to hard coded values of input_files/SBBX1880.Ts.GHCN.CL.PA.1200 and input_files/SBBX.HadR2 respectively (unlike in STEP3 where we used variables to hold the names, at least in bits and pieces.) and check that they exist; exiting if they are missing. The good news is that for this step our input files actually come from the directory “input_files”; unlike in some other steps.

This next bit gets a bit interesting. First up, we move a file named do_comb_step5.log into the directory “out” inside of STEP4_5 but unfortunately, there is no directory named “out” as unpacked. Oops. Guess that’s an exercise for the student too. Then we move the file BX.[RLand parameter]x to “../old” but in the parent directory of STEP4_5 there is no such directory as “old” and in both cases throw away the error messages that are inevitable.!

Astonishing. Simply astonishing.

OK, this performance is followed by the usual linking of the actual file names into temporary names of fort.10 and fort.11 and we are ready for the main event.

Finally, some real action. We compile the program SBBXotoBX.f (but name the output executable to.exe just as in STEP3) run it (as to.exe) with a passed parameter of “RLand” that ought to be 100 by default and a “0” though it isn’t clear why zero is used; then put the output log into the file SBBXotoBX.log and move to a very polite statement that we created another file too: BX.Ts.ho2.GHCN.CL.PA.1200

Which is actually a file named fort.12 that gets moved to that name.

Watch for those fort.xx names inside the FORTRAN code…

Finally, at the end, we deleted the files “fort.10” and “fort.11” along with the to.exe executable file

Here we make the directory work_files (again throwing away any error messages). This is getting just a bit irksom. It isn’t particularly hard to test for the existance of a directory and only make it if it does not already exist. This is just incredibly lazy programming with very poor style.

Then, as our final act, we run the zonav script with the argument of ho2.GHCN.CL.PA (and yes, I’m wondering where THAT came from…)

Now we sumarily end.

We know from the commentary in STEP3:

“You may use do_comb_step5.sh to create the temperature anomaly tables that are based on land and ocean data”

But this “process” just leaves us dangling. No operator directives. No helpful hints. Just dead air. Have A Nice Day. Neeexxxxt!

So what did we just do?

We made an anomaly map. A bunch of sound and fury signifying nothing.

FORTRAN source:

 

There are three FORTRAN programs:

SBBXotoBX.f

C*********************************************************************
C *** PROGRAM READS NCAR FILES
C *** Input argument: Rland (0-1200km) radius of influence of station
C *** Input file:   10,11    subbox.data (land, ocean based)
C ***
C *** Output file:  12       box.data
C ***
C *** This program combines 8000 subbox to 80 box data
C*********************************************************************
C****
C**** This program interpolates the given station data or their
C**** ANOMALIES with respect to 1951-1980 to a prescribed grid.

zonav.f

C*********************************************************************
C *** PROGRAM READS BXdata
C *** Input files:  11    box.data (BX1977.T1200)
C ***
C *** Output files: 10    zonal.means (ZON1977.T1200)
C ***
C*********************************************************************
C****
C**** This program combines the given gridded data (anomalies)
C**** to produce AVERAGES over various LATITUDE BELTS.

annzon.f

C*********************************************************************
C *** program reads ZONAL monthly means and recomputes REGIONAL means
C *** as well as annual means.
C *** Input file:  10    zonal.means (ZON1977.T1200)
C ***
C *** Output files: 11    annual.zonal.means (ANNZON1977.T1200)
C ***               12    zonal.means (ZON1977.T1200) changed
C*********************************************************************
C****
C****
C**** Displays data and their annual means
C****

And that concludes the overview of STEP5 FORTRAN.

Their is no STEP5 “readme” file to reproduced below:

Advertisements

About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in GISStemp Technical and Source Code and tagged , , , , , . Bookmark the permalink.