Inside GCM Model II

Earlier I did the ‘where to find it how to get it what’s in the box’ posting on NASA GISS GCM Model II in this posting:

https://chiefio.wordpress.com/2016/12/27/a-remarkably-tiny-global-circulation-model-you-can-run/

At the end of the process (down in comments) I’d gotten the thing to compile under Linux. The short form is:

Download.
Unzip.
Edit Makefile and replace the SVNVER variable ‘discovery’ of what svn version you have with
SVNVER=0.0
Edit RANDVAX.f and setpath.f to remove the “_” character from names of functions
Copy Makefile.gfortran to Makefile.pi and comment out the LIBS= line:
#LIBS = -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib

At that point “make” and then “make -f makefile.pi” ought to build it.

At that point you discovery it wants a bunch of fairly complicated input configuration files that are not in the software download. I’m working on getting or creating those… While that happens, I’m doing a bit of code review on the package.

In the earlier posting I noted those small FORTRAN and other source files that were not the core of the program. Things like the GUI added bits and some Macintosh glueware to make it go on a Mac. In this posting, I’ll be looking at the larger bits that were not examined then. (Likely this one and some more as there are 5 large code blocks and I think one per posting is likely the limit. We’ll see as I write them…)

Here’s a listing fo the files you get in the downloaded source tarball:

sh-4.3$ ls -l
-rw-r--r-- 1 chiefio chiefio   3926 Aug  2  2005 B83XXDBL.COM
-rw-r--r-- 1 chiefio chiefio   3164 Aug  2  2005 BA94jalC9.COM
-rw-r--r-- 1 chiefio chiefio 240095 Apr 17  2008 DB11pdC9.f
-rw-r--r-- 1 chiefio chiefio  13208 Aug  2  2005 FFT36macDBL.f
-rw-r--r-- 1 chiefio chiefio   5362 Aug  2  2005 FORCINGSjalC9.f
-rw-r--r-- 1 chiefio chiefio   1333 Aug  2  2005 FORCINGSmac.COM
-rw-r--r-- 1 chiefio chiefio    876 Mar 23  2006 Info.plist
-rw-r--r-- 1 chiefio chiefio    906 Dec 27 23:00 Makefile
-rw-r--r-- 1 chiefio chiefio    612 May 12  2008 Makefile.Mac.PPC
-rw-r--r-- 1 chiefio chiefio   3145 Apr 18  2008 Makefile.README
-rw-r--r-- 1 chiefio chiefio    747 Apr  1  2008 Makefile.gfortran
-rw-r--r-- 1 chiefio chiefio    706 May 12  2008 Makefile.ifort
-rw-r--r-- 1 chiefio chiefio   9238 Apr 17  2008 Makefile.win
-rw-r--r-- 1 chiefio chiefio   2252 Apr 17  2008 Makefile.win.gui
-rw-r--r-- 1 chiefio chiefio 204365 Mar 23  2006 Mjal2cpdC9.f
-rw-r--r-- 1 chiefio chiefio 331692 Jan 17  2006 Pjal0C9.f
-rw-r--r-- 1 chiefio chiefio     59 Aug  2  2005 PostBuild.sh
-rw-r--r-- 1 chiefio chiefio 555793 Aug  2  2005 R83ZAmacDBL.f
-rw-r--r-- 1 chiefio chiefio   1248 Dec 27 22:58 RANVAX.f
-rw-r--r-- 1 chiefio chiefio   1427 Aug  2  2005 RANVAXxlf.f
-rw-r--r-- 1 chiefio chiefio   3339 Mar 13  2007 README.f.in
-rw-r--r-- 1 chiefio chiefio 128314 Aug  2  2005 RFRCmacDBL.f
-rw-r--r-- 1 chiefio chiefio   4203 Jan 18  2006 UTILmacDBL.f
-rw-r--r-- 1 chiefio chiefio   4202 Dec 14  2006 UTILwinDBL.f
-rw-r--r-- 1 chiefio chiefio   5548 Jan 17  2006 commandlinetest.gui
-rw-r--r-- 1 chiefio chiefio  11887 Aug  2  2005 modelF.r
-rw-r--r-- 1 chiefio chiefio   1475 Aug  2  2005 mrweprefs.r
-rw-r--r-- 1 chiefio chiefio    132 Aug  2  2005 pd_COMMON
-rw-r--r-- 1 chiefio chiefio   1321 Dec 27 22:58 setpath.f

Of those, I’ve already mentioned that the COMMON and .COM files are FORTRAN common blocks (definitions of what variables and arrays will be shared by several programs for data passing), the .r files are for Macintosh compatibility use, and the Makefile.x set are custom build scripts for different environments (with Makefile doing a set-up step then telling you to run one of the others). README.f.in is processed by Makefile to produce README.f which looks like it just sticks a ‘edGCM branding’ comment on the tops of programs. Also, I’d looked at setpath.f (that does a workaround for execution path setting in some environments) and RANDVAX files that basically is a “call random” function for making pseudo-random numbers. The “commanlinetest.gui” didn’t interest me as I’m not using the edGCM GUI code (that is proprietary and licensed for a fee…) also the PostBuild.sh shell script that is a one line “copy the executable to your bin directory” trivial “scrip”. That leaves info.plilst and a very few FORTRAN programs to look at next.

-rw-r--r-- 1 chiefio chiefio 240095 Apr 17  2008 DB11pdC9.f
-rw-r--r-- 1 chiefio chiefio  13208 Aug  2  2005 FFT36macDBL.f
-rw-r--r-- 1 chiefio chiefio   5362 Aug  2  2005 FORCINGSjalC9.f
-rw-r--r-- 1 chiefio chiefio    876 Mar 23  2006 Info.plist
-rw-r--r-- 1 chiefio chiefio 204365 Mar 23  2006 Mjal2cpdC9.f
-rw-r--r-- 1 chiefio chiefio 331692 Jan 17  2006 Pjal0C9.f
-rw-r--r-- 1 chiefio chiefio 555793 Aug  2  2005 R83ZAmacDBL.f
-rw-r--r-- 1 chiefio chiefio 128314 Aug  2  2005 RFRCmacDBL.f
-rw-r--r-- 1 chiefio chiefio   4203 Jan 18  2006 UTILmacDBL.f
-rw-r--r-- 1 chiefio chiefio   4202 Dec 14  2006 UTILwinDBL.f

A MUCH smaller set of things to look at, no? I’m going to take them more or less in order of increasing size. Why? To clear out the small and simple stuff quickly, leaving on the larger core to chew on at length. Often this is the best way to discover out a new package works. Nibble off the edges until you are left with a few things to figure out…

So first up, “Info.plist”:

This is just FILLED with angle brackets. Since WordPress strips out all things angle bracket, and I’m not interested in typing a few hundred obscure escape codes to show them, I’m just going to replace them with square brackets for display purposes.

[?xml version="1.0" encoding="UTF-8"?]
[!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd"]
[plist version="0.9"]
[dict]
      	[key]CFBundleExecutable[/key]
	[string]modelII 8x10x9[/string]
	[key]CFBundleIdentifier[/key]
	[string]com.edgcm.modelII[/string]
	[key]CFBundleInfoDictionaryVersion[/key]
	[string]6.0[/string]
	[key]CFBundlePackageType[/key]
	[string]APPL[/string]
	[key]CFBundleSignature[/key]
	[string]eGCM[/string]
	[key]CFBundleVersion[/key]
	[string]1.0.7[/string]
	[key]CSResourcesFileMapped[/key]
	[true/]
	[key]CFBundleIconFile[/key]
	[string]modelII.icns[/string]
	[key]CFBundleShortVersionString[/key]
    [string]1.0.7 Model II[/string]
    [key]CFBundleLongVersionString[/key]
    [string]1.0.7, GISS GCM Model II (8x10 or 7.826x10, 9-layer)[/string]
    [key]NSApplescriptEnabled[/key]
    [string]No[/string]
[/dict]
[/plist]

“Propertylist” and with an xml tag at the tope. Looks to me like a bunch more of the GUI oriented stuff that I’m not bothering with. OK, moving on…

UTILmacDBL.f and UTILwinDBL.f

As you might guess from their name, these are a Mac and Windows version of the same thing. A “diff” on them shows little difference. The Windows version has “clock90” while the Mac version has “secnds(0.0)”. I’ve preplaced the angle brackets in the ‘diff’ output below with [ and }.

sh-4.3$ diff UTILmacDBL.f UTILwinDBL.f 
33c33
{       IHSC = secnds(0.0)
---
} c      IHSC = secnds(0.0)
35c35
{ c      IHSC = clock()
---
}       IHSC = clock()
124c124
{       MNOW  = secnds (0.0)      
---
} c     MNOW  = secnds (0.0)      
126c126
{ c      MNOW = clock()
---
}       MNOW = clock()

So what’s the Mac version look like in total? It is 131 lines.

sh-4.3$ cat UTILmacDBL.f 
c  *********************************************************************
c  *********************************************************************
c  **
c  ** Model IImac
c  ** Based on GCMII code for IBM RS/6000 computers created at GISS
c  ** Modified to compile under Absoft Pro Fortran 6.2 for MacOS.  
c  ** Based on MP008macC9, BA94C9 and MA94DC9
c  **
c  ** CHANGE HISTORY:
c  **
c  ** 7/27/99 First Successful Compile! (DCH)
c  ** 7/27/99 Changed MCLOCK() call to DTIME() unix call (DCH)
c  ** 7/30/99 Patched DTIME to 4 to make it compile
c  ** 11/01/99 Another patch to work as a shared lib (MFS)
c  ** 12/21/00 Try with another version of Model II (MFS)
c  ** 09/28/02 Use clock() to replace MCLOCK() (MFS)
c  ** 01/27/05 working MCLOCK (GLR)
c  ** 01/17/06 reverted to CLOCKS, secnds on Mac, clock on Win (MFS)
c  **
c  ** NOTES:
c  **  Not sure if DTIME does the same thing as MCLOCK, but Reto believe
c  **  all calls to CLOCKS are not important to the running of the model
c  **
c  *********************************************************************
c  *********************************************************************

c  MS SYSTEM ROUTINES EMULATION FOR IBM RS/6000
c

Looks like a collection of a few Utility Functions. We’ll break them out. First, the “clocks” function:

OK, so it gets run times of executions. Might need to fiddle with just what function is called, but the Mac, being Mach based and using gfortran build likely uses a Linux compatible call. And, as the comment notes, not really important to the actual model. Likely used just to display run time info in the presentation phase of the GUI anyway (or annotated into a run log file.).

      SUBROUTINE CLOCKS(IHSC)
c  THIS VERSION OF CLOCKS RETURNS PROCESS TIME OF USER AND
c  SYSTEM TIME OF CHILD PROCESSES
c  NOTE: MCLOCK IS REALLY IN HUNDREDTHS OF A SECOND, NOT SIXTIETHS.
      IHSC = secnds(0.0)
c  ** Windows should use
c      IHSC = clock()
      RETURN
      END

THBAR looks like some thermobaric calculations. The top comment block presents what they think they are doing. I note that they commented out an older FORTRAN style of the DATA statement and replaced it with the newer PARAMETER form. Nothing like gratuitous changes to a language spec over time to keep programmers employed…

      FUNCTION THBAR (X,Y)
c  **
c  ** TH-mean used for vertical differencing (Arakawa)
c  ** THBAR(T1,T2) = (ln(T1) - ln(T2))/(1/T2 - 1/T1)
c  **              = T1*g(x) with x=T1/T2 , g(x)=ln(x)/(x-1)
c  **      g(x) is replaced by a rational function
c  **           (a+bx+cxx+dxxx+cx**4)/(e+fx+gxx)
c  **      approx.error <1.E-6 for x between .9 and 1.7
c  **
c     REAL*8 A,B,C,D,E,F,G,Q,AL
      IMPLICIT REAL*8 (A-H,O-Z)
      PARAMETER (
     *  A=113.4977618974100d0,B=438.5012518098521d0,
     *  C=88.49964112645850d0,D=-11.50111432385882d0,
     *  E=30.00033943846368d0,F=299.9975118132485d0,
     *  G=299.9994728900967d0)
c     DATA A,B,C,D,E,F,G/113.4977618974100,438.5012518098521,
c    *  88.49964112645850,-11.50111432385882,
c    *  30.00033943846368,299.9975118132485,299.9994728900967/
      Q=X/Y
      AL=(A+Q*(B+Q*(C+Q*(D+Q))))/(E+Q*(F+G*Q))
      THBAR=X*AL
      RETURN
      END

No idea at this point what EXPBYK does. Send it X, it raises X to the power 0.286, but why?

(“Why? Don’t ask why. Down that path lies insanity and ruin. -E.M.Smith”… we will be exploring ‘why’ when we get to the code that calls EXPBYK …

      FUNCTION EXPBYK (X)
      IMPLICIT REAL*8 (A-H,O-Z)
      EXPBYK=X**.286
      RETURN
      END

DREAD function looks like it just does a REAL ARRAY of 4 bytes to REAL 8 byte length conversion. Ah, the joys of data type mismatch… With 64 bit machines common now, one could likely get a speed up by eliminating this function and making all such things 8 bytes long in the mainline code. Change “reals” to “doubles”.

      SUBROUTINE DREAD (IUNIT,AIN,LENGTH,AOUT)
c  **
c  ** READ IN REAL*4 ARRAY AND CONVERT TO REAL*8
c  **
      REAL*4 AIN(LENGTH)
      REAL*8 AOUT(LENGTH)
      READ (IUNIT) AIN
      DO 10 N=LENGTH,1,-1
   10 AOUT(N)=AIN(N)
      RETURN
      END

And the same thing for Integers…

      SUBROUTINE MREAD (IUNIT,M,NSKIP,AIN,LENGTH,AOUT)
c  **
c  ** READ IN INTEGER & REAL*4 ARRAY AND CONVERT TO REAL*8
c  **
      REAL*4 AIN(LENGTH),X
      REAL*8 AOUT(LENGTH)
      READ (IUNIT) M,(X,N=1,NSKIP),AIN
      DO 10 N=LENGTH,1,-1
   10 AOUT(N)=AIN(N)
      RETURN
      END

Then again, the same idea for the TITLE… Title of what? Maybe later… ;-)

      SUBROUTINE READT (IUNIT,NSKIP,AIN,LENGTH,AOUT,IPOS)
c  **
c  ** READ IN TITLE & REAL*4 ARRAY AND CONVERT TO REAL*8
c  **
      REAL*4 AIN(LENGTH),X
      REAL*8 AOUT(LENGTH)
      CHARACTER*80 TITLE
      DO 10 N=1,IPOS-1
   10 READ (IUNIT,END=920)
      READ (IUNIT,ERR=910,END=920) TITLE,(X,N=1,NSKIP),AIN
c     IF(LEN.LT.4*(20+NSKIP+LENGTH)) GO TO 930
      DO 100 N=LENGTH,1,-1
  100 AOUT(N)=AIN(N)
      WRITE(6,'('' Read from Unit '',I2,'':'',A80)') IUNIT,TITLE
      RETURN
  910 WRITE(6,*) 'READ ERROR ON UNIT',IUNIT
      STOP 'READ ERROR'
  920 WRITE(6,*) 'END OF FILE ENCOUNTERED ON UNIT',IUNIT
      STOP 'NO DATA TO READ'
c  30 WRITE(6,*) LEN/4,' RATHER THAN',20+NSKIP+LENGTH,' WORDS ON UNIT',
c    *  IUNIT
c     STOP 'NOT ENOUGH DATA FOUND'
      END

Then we have a ‘timer’ routine. So it is keeping track of run times internally. OK, I’d likely put that external, but whatever. Key bit is it isn’t critical to the actual model nor understanding it.

      SUBROUTINE TIMER (MNOW,MINC,MSUM)
c  **
c  ** OUTPUT: MNOW (.01 S) = CURRENT CPU TIME
c  **         MINC (.01 S) = TIME SINCE LAST CALL TO SUBROUTINE TIMER
c  **         MSUM (.01 S) = MSUM + MINC
c  **
      SAVE MLAST
      MNOW  = secnds (0.0)      
c  ** Windows should use
c      MNOW = clock()
      MINC  = MNOW - MLAST
      MSUM  = MSUM + MINC
      MLAST = MNOW
      RETURN
      END

Forcings? There MUST be FORCINGs…

Next up is that FORCINGSjalC9.f file. It is 175 lines long. Hopefully not too much density in them… I suspect, though, that this will tip the hand about what is expected to produce the desired results from the model.

sh-4.3$ cat FORCINGSjalC9.f 
c  *********************************************************************
c  *********************************************************************
c  **
c  ** Model IImac
c  ** Based on GCMII code for IBM RS/6000 computers created at GISS
c  ** Modified to compile under Absoft Pro Fortran 7.0 for MacOS 9/X.  
c  ** Code to do trends
c  ** 
c  ** CHANGE HISTORY:
c  ** 
c  ** 05/27/02 new S0X code (MSC/MFS)
c  ** 06/03/02 new greenhouse gas trend code (MSC/MFS)
c  ** 06/10/02 fixed bug so it reads the first year (MFS)
c  ** 06/17/02 fixed logic error in code (MFS)
c  ** 06/19/02 moved joldyear to the common block (MFS)
c  ** 05/06/04 added fixed var to include END (MAC)
c  ** 05/27/04 changed JOLDYEAR to array with 5 values (=NGAS) (MAC)
c  ** 06/22/04 removed extra defined jyear (MFS)
c  ** 03/16/05 fix format statement (MFS/Patrick Lee/JAL)
c  ** 
c  ** NOTES:
c  ** This code replaces RFRC
c  ** 
c  *********************************************************************
c  *********************************************************************

Hmmm… there is also a RFRCmacDBL.f program, so one presumes RFRC is short for Radiative FoRCing or some such. OK, we’ve got Sulphur Oxides SOX, a Greenhouse Gas Trend setting, and some things about radiative forcing. Wonder if we’ll find anything else…

      SUBROUTINE SOLARFORCING
c  ** reads the solar trend, replaces code in RFRC
c  ** does both trends and fixed
      INCLUDE 'BA94jalC9.COM'
      INCLUDE 'FORCINGSmac.COM'
c  ** var
      INTEGER*4 JDATAYEAR
      REAL*8 DATAVALUE
      REAL*8 XXGAS
      INTEGER*4 OLDYEAR
      DATA OLDYEAR/-999/
      
      IF((IS0XDATA.GT.0).AND.(JYEAR.GE.IS0XDATASTART))THEN
        IF(OLDYEAR.NE.JYEAR)THEN
          XXGAS=GREENHOUSEGASFORCING(IS0XDATA,IS0XDATASTART,
     *      IS0XDATAEND)
          OLDYEAR=JYEAR
         END IF
        S0X=XXGAS
      END IF
      END

So it DOES have a “Solar Forcing” aspect. Here it reads in 2 COMmon blocks for sharing data. We’ll look at those just below this program. It looks like it uses Julian Date (JDATEYEAR) to maybe drive a solar orbital mechanics variation in sunshine? Nice to have that in, now just to get the values right ;-) Or perhaps it is just to puck up gas forcing based on year… We’ll need to read more of the guts of it to see what it really does.

Then it does a VERY direct “make greenhouse gasses force things this much based on year” near as I can tell (at this point and from function names…). Note to self: Find “GREENHOUSEGASFORCING” function and see what it does… (a ‘grep’ of all things .f shows it is only in this program… so down below somewhere).

DATA-REF-Year

I like the “goes very weird” comment ;-) So water vapor, CO2, Ozone, Oxygen (why oxygen?, NOx, Methane, and some Freons… The 4211, 12, and 13 are line numbers in the original file.

Again, it includes the COMmon block for sharing data.

Overall, looks like it just forces XGAS to 1958 values to “avoid weirdness”… Then packs JOLDYEAR with a bad data value of -999 (common marker in FORTRAN era stuff to show it isn’t zero but empty).

      SUBROUTINE DATAREFYEAR(XGAS,YEAR,NGAS)
c  ** for reference purposes 1958 values always have to be certian
c  ** constants or the scaling goes very weird, Andy warned me
c  **
c  ** Here are the original lines from R83ZAmacC9
C                 H2O   CO2  O3      O2 NO2   N2O   CH4   CCL3F1 CCL2F2 4211.   
C     DATA FULGAS/1.0,  1.0,1.0,    1.0,1.0,  1.0,  1.0,    1.0,    1.0/4212.   
c     DATA PPMV58/0.0,315.0,0.0,210000.,0.0,0.295,1.400,8.00E-6,25.0E-6/4213.   
      INCLUDE 'FORCINGSmac.COM'
c  ** var
      REAL*8 XGAS(5)
      REAL*8 YEAR
      INTEGER*4 NGAS
c  ** set xgas to 1958 values
      XGAS(1) = 315.
      XGAS(2) = 0.295
      XGAS(3) = 1.400
      XGAS(4) = 8.00E-6 * 1000.D0
      XGAS(5) = 25.0E-6 * 1000.D0
c  ** setup joldyear
      DO 100 I=1,NGAS
      JOLDYEAR(I) = -999
  100 CONTINUE
      END

This next bit lets you load in any ‘trend’ you would like in a data stream. It is to avoid hard coding trends. So it will tell us the format of the “trend” files… that look to have a year marker and then what the trend ought to be in that year. Again, the two common COMMON blocks… I note in passing the use of lots of *GAS* variables, solar and tidal and cosmic rays and orbital not so much… Gee, I wonder why it finds GH GAS as an important driver and not solar…

So basically this reads in the trends in GHG that you set, then down below it calculates what temperature “forcing” that would make, then eventually you get the temperature increase at the end…

      SUBROUTINE DATAFILETREND(XGAS,YEAR,NGAS)
c  ** file based trend code to run any trend you want without having to
c  ** recompile the model. updates the trends from the file once a year
c  ** and caches the values inbetween. 
      INCLUDE 'BA94jalC9.COM'
      INCLUDE 'FORCINGSmac.COM'

      REAL*8 XGAS(5)
      REAL*8 XXGAS(5)
      REAL*8 YEAR
      INTEGER*4 NGAS
        
      IF((ICO2DATA.GT.0).AND.(JYEAR.GE.ICO2DATASTART))THEN
        IF(JOLDYEAR(1).NE.JYEAR)THEN
          XXGAS(1)=GREENHOUSEGASFORCING(ICO2DATA,ICO2DATASTART,
     *      ICO2DATAEND)
          JOLDYEAR(1)=JYEAR
         END IF
        XGAS(1)=XXGAS(1)
      ELSE
        XGAS(1)=CO2
      END IF
        
      IF((IN2ODATA.GT.0).AND.(JYEAR.GE.IN2ODATASTART))THEN
        IF(JOLDYEAR(2).NE.JYEAR)THEN
          XXGAS(2)=GREENHOUSEGASFORCING(IN2ODATA,IN2ODATASTART,
     *      IN2ODATAEND)
          JOLDYEAR(2)=JYEAR
        END IF
        XGAS(2)=XXGAS(2)
      ELSE
        XGAS(2)=ZN2O
      END IF
        
      IF((ICH4DATA.GT.0).AND.(JYEAR.GE.ICH4DATASTART))THEN
        IF(JOLDYEAR(3).NE.JYEAR)THEN
          XXGAS(3)=GREENHOUSEGASFORCING(ICH4DATA,ICH4DATASTART,
     *      ICH4DATAEND)
          JOLDYEAR(3)=JYEAR
        END IF
        XGAS(3)=XXGAS(3)
      ELSE
        XGAS(3)=CH4
      END IF
        
      IF((IF11DATA.GT.0).AND.(JYEAR.GE.IF11DATASTART))THEN
        IF(JOLDYEAR(4).NE.JYEAR)THEN
          XXGAS(4)=GREENHOUSEGASFORCING(IF11DATA,IF11DATASTART,
     *      IF11DATAEND)
          JOLDYEAR(4)=JYEAR
        END IF
        XGAS(4)=XXGAS(4)
      ELSE
        XGAS(4)=F11
      END IF
      
      IF((IF12DATA.GT.0).AND.(JYEAR.GE.IF12DATASTART))THEN
        IF(JOLDYEAR(5).NE.JYEAR)THEN
          XXGAS(5)=GREENHOUSEGASFORCING(IF12DATA,IF12DATASTART,
     *      IF12DATAEND)
          JOLDYEAR(5)=JYEAR
        END IF
        XGAS(5)=XXGAS(5)
      ELSE
        XGAS(5)=F12
      END IF
        
      END

Once more, the two common blocks for sharing data. For a given JDATAYEAR (line 10) it reads in a given DATAVALUE, then sets the GREENHOUSEGASFORCING to that value. Nice…

      FUNCTION GREENHOUSEGASFORCING(IDATAUNIT,ISTARTDATA,IENDDATA)
c  ** reads a greenhouse gas trend and gives the result back
c  ** to the rest of the code, replaces code in RFRC
      INCLUDE 'BA94jalC9.COM'
      INCLUDE 'FORCINGSmac.COM'
c  ** var
      INTEGER*4 IDATAUNIT,ISTARTDATA,IENDDATA
      INTEGER*4 JDATAYEAR
      REAL*8 DATAVALUE
      REAL*8 GREENHOUSEGASFORCING
      
      IF(IDATAUNIT.GT.0)THEN
   10   READ(IDATAUNIT,900,ERR=100,END=100) JDATAYEAR,DATAVALUE
        IF(JDATAYEAR.EQ.JYEAR)THEN
          GREENHOUSEGASFORCING=DATAVALUE
        ELSE IF(JDATAYEAR.LT.JYEAR)THEN
          GO TO 10
        ELSE
          GO TO 110
        END IF
      ELSE
c  ** default is to do nothing        
      END IF 
c  ** sucess      
      RETURN
c  ** errors     
  100 STOP 'Error: Data file ends before current year.\n'
  110 STOP 'Error: Data file begins after current year.\n'
c  ** format
  900 FORMAT(I4,T6,F15.8)
      END

The COMMON blocks

OK, just for completeness, here are those COMMON blocks. Note that this just says what variables are global to the whole program. Any code that has an include of these variables can change them and share the results with others. This can cause no end of grief in debugging if you are not careful, but is very useful for sharing data structures.

sh-4.3$ ls -l *COM* 
-rw-r--r-- 1 chiefio chiefio 3926 Aug  2  2005 B83XXDBL.COM
-rw-r--r-- 1 chiefio chiefio 3164 Aug  2  2005 BA94jalC9.COM
-rw-r--r-- 1 chiefio chiefio 1333 Aug  2  2005 FORCINGSmac.COM
-rw-r--r-- 1 chiefio chiefio  132 Aug  2  2005 pd_COMMON

So there are 3 total. Note that “pd_COMMON” is not a FORTRAN common block like the others, involved in the model operation:

sh-4.3$ cat pd_COMMON 
      character*80 clabel
      equivalence (clabel,xlabel)
      common/pd_com/iprint_pd(12),iu_pd(12),iform_pd(12),iNetcdf_pd(12)

It has to do with printing out some things…

The FORCINGSmac.COM file

So what does FORCINGSmac.COM look like? BTW, the comments indicate changes over time. That implies strongly some other code that USED this common block to pass data changed then too.

sh-4.3$ cat FORCINGSmac.COM 
c  *********************************************************************
c  *********************************************************************
c  **
c  ** Model IImac
c  ** Based on GCMII code for IBM RS/6000 computers created at GISS
c  ** Modified to compile under Absoft Pro Fortran 6.2 for MacOS.  
c  ** Based on BRCRFmac.COM
c  **
c  ** CHANGE HISTORY:
c  **
c  ** 05/27/02 new S0X code (MFS)
c  ** 06/07/02 added ktrend (MFS)
c  ** 06/15/02 renamed ktrend to ktrendext(MFS)
c  ** 06/19/02 moved joldyear to here (MFS)
c  ** 05/27/04 changed JOLDYEAR to array with MGAS values (=NGAS) (MAC)
c  **
c  ** NOTES:
c  **
c  *********************************************************************
c  *********************************************************************

c  ** force reals to be real*8
c      IMPLICIT REAL*8 (A-H,O-Z)
c  ** new common for INPUTFORCINGS
      PARAMETER (MGAS=5)
      COMMON/IFORCINGS/
     *  KTRENDEXT, JOLDYEAR(MGAS),
     *  ICO2DATA, ICO2DATASTART, ICO2DATAEND,
     *  IN2ODATA, IN2ODATASTART, IN2ODATAEND,
     *  ICH4DATA, ICH4DATASTART, ICH4DATAEND,
     *  IF11DATA, IF11DATASTART, IF11DATAEND,
     *  IF12DATA, IF12DATASTART, IF12DATAEND,
     *  IS0XDATA, IS0XDATASTART, IS0XDATAEND,
     *  IVOLDATA, IVOLDATASTART, IVOLDATAEND
      COMMON/RFORCINGS/
     *  ZN2O, CH4, F11, F12, VOL

So the block is all REAL*8 or 64 bit values. I wonder if MGAS stands for Magic Gas ;-)

The forcings look like a trend external file, CO2, NOx, Methane, Freons, SOx and “IVOLDATA”… Volume? In any case, it’s pretty clear what is going to drive ANY temperature change in this “model”. It is just looking for Magic Gas effects, nothing else.

The BA94jalC9.COM file

That BA94jalC9.COM file has more meat in it, but we don’t know what it is used for yet. The comment about “to change the grid” in the second comment (after the intro block) implies it is a data structure for the actual grid status. We’ll see if that speculation holds. Remember that in FORTRAN, varables named starting with I through N are INTEGER types, so something like IFROG is being cast as an INT with the leading I and it likely does NOT have meaning beyond that if the rump has meaning alone. You will see a lot of varuables like JM and KTD that are likely things like (integer)M and (integer)TD. But who knows. Folks often play games with it and you can change those defaults with an explicit type assignmnet (though it is considdered a bit rude…)

sh-4.3$ cat BA94jalC9.COM 
c  *********************************************************************
c  *********************************************************************
c  **
c  ** Model IImac
c  ** Based on GCMII code for IBM RS/6000 computers created at GISS
c  ** Modified to compile under Absoft Pro Fortran 6.2 for MacOS.  
c  ** Based on MP008macC9, BA94C9 and MA94DC9
c  **
c  ** CHANGE HISTORY:
c  **
c  ** 07/27/99 First Successful Compile! (DCH)
c  ** 06/14/02 as original (MFS)
c  **
c  ** NOTES: 10/2002 Modernized by J.Lerner
c  **
c  *********************************************************************
c  *********************************************************************

C**** COMMON BLOCK (B35V)  FINE MODEL II DBLE.PREC. RS6000 10/29/91
C**** TO CHANGE THE GRID, MODIFY THE NEXT LINE ONLY
      PARAMETER (IM=36,JM=24,LM=9, KTD=6,KAIJ=80,KAJK=50)
C**** IM,JM,LM LIMITED TO 72,46,36 RESPECTIVELY BY RADCOM & SIGmas
      IMPLICIT REAL*8 (A-H,O-Z)
      REAL*8 LHE,LHM,LHS,KAPA,LAT,lat_dg
C**** THERE ARE 100 INTEGER PARAMETERS IN COMMON (JC-ARRAY)
      COMMON /IPARMB/IM0,JM0,LM0,JMM1,LMM1,   LS1,LTM,LBLM,LMCM,LSSM,
     *  KOCEAN,KDISK,KEYCT,KACC0,KCOPY,  IRAND,IJRA,MFILTR,NDYN,NCNDS,
     *  NRAD,NSURF,NGRND,NFILTR,NDAA,   NDA5D,NDA5K,NDA5S,NDA4,NDASF,
     *  MLAST,MDYN,MCNDS,MRAD,MSURF,    MDIAG,MELSE,MODRD,MODD5K,MODD5S,
     *  IYEAR,IDAY,IDAY0,JYEAR,JYEAR0,  JDAY,JDATE,JDATE0,NSTEP,MRCH,
     *  IDUM(4),NDZERO(13),NDPRNT(13),  IJD6(2,4),IDACC(12)
C**** THERE ARE 161 REAL NUMBERS IN COMMON (RC-ARRAY)
      COMMON /RPARMB/
     *  TAU,TAU0,TOFDAY,TOFDY0,DT,      TAUP,TAUI,TAUE,TAUT,TAUO,
     *  TWOPI,SDAY,LHE,LHM,LHS,         RADIUS,GRAV,RGAS,KAPA,OMEGA,
     *  CCMCX,ETA,S0X,CO2,SRCOR,        PTOP,PSF,PSL,PTRUNC,AREAG,
     *  XCDNST(2),XINT,DLAT,DLON,       SKIPSE,USESLP,USEP,USET,FIM,
     *  RSDIST,SIND,COSD,DOPK,SIG(36),SIGE(37),RDM2(44)
      CHARACTER*4 XLABEL,NAMD6,JMONTH,JMNTH0
      COMMON /TEXT/ XLABEL(33),NAMD6(4),JMONTH,JMNTH0
      COMMON /GEOMCB/ RAPVS(JM),RAPVN(JM),RAVPS(JM),RAVPN(JM),F(JM),
     *  DXYP(JM),DXP(JM),DYP(JM),DXYS(JM),SINP(JM),LAT(JM),
     *  DXYV(JM),DXV(JM),DYV(JM),DXYN(JM),COSP(JM),COSV(JM),lat_dg(jm,2)
      COMMON /BNDYCB/ FDATA(IM,JM,3),ODATA(IM,JM,5),GDATA(IM,JM,14),
     *  BLDATA(IM,JM,8),VDATA(IM,JM,10),
     *  Z1O(IM,JM),Z12O(IM,JM)
      COMMON /RADNCB/ RQT(IM,JM,3),SRHR(IM,JM,LM+1),TRHR(IM,JM,LM+1)
      COMMON /LAYACB/ DSIG(37),DSIGO(36)
      DIMENSION U(IM,JM,LM),V(IM,JM,LM),T(IM,JM,LM),P(IM,JM),Q(IM,JM,LM)
C**** DIAGNOSTIC ARRAYS
      PARAMETER (IMH=IM/2,     KACC=JM*80*3 + 24*80 +
     *   JM*3 + JM*LM*54 + JM*3*4 + IM*JM*KAIJ +
     *   IM*LM*16                      + 20*100 +
     *   JM*36 + (IMH+1)*20*8 + 8*2 + 24*50*4 +
     *   2*62*10*12 + JM*LM*KAJK + IM*JM*LM*6)
      COMMON/ACCUM/AJ(JM,80),BJ(JM,80),CJ(JM,80),DJ(24,80),
     *  APJ(JM,3),AJL(JM,LM,54),ASJL(JM,3,4),AIJ(IM,JM,KAIJ),
     *  AIL(IM,LM,16),ENERGY(20,100),
     *  CONSRV(JM,36),SPECA((IMH+1),20,8),ATPE(8,2),ADAILY(24,50,4),
     *  WAVE(2,62,10,12),AJK(JM,LM,KAJK),AIJK(IM,JM,LM,6),
     *  TSFREZ(IM,JM,2),TDIURN(IM,JM,KTD)
      COMMON/REGION/JREG(IM,JM)
      COMMON/KEYS/KEYNR(42,50),KDIAG(12)
sh-4.3$

Overall, this looks to me like it is defining the GRID layout, and with JM and IM and LM as the size values for various other arrays. I suspect LM is layers as we know MODEL II has 9 layers in the later version. That would make IM and JM the Lat and Long sizes. (nuber of boxes each way). Don’t know yet what the KTD and KA* set do, but Kxxx is often used for an INTEGER counter (COUNT being a real or float value not being between I and N…)

So mostly this looks like it sets up a bunch of arrays sized to the global grid for tracking input values and results. Any more depth can come from looking at the code that uses the variables.

The B83XXDBL.COM file

The next one looks like it is devoted to input parameters. Likely that stuff like where there is land and ice and water and vegetation and all… So this is the one I need to find a way to fill at start time. All those basic settings that were tuned to make it run “just so”.

sh-4.3$ cat B83XXDBL.COM 
c  *********************************************************************
c  *********************************************************************
c  **
c  ** Model IImac
c  ** Based on GCMII code for IBM RS/6000 computers created at GISS
c  ** Modified to compile under Absoft Pro Fortran 6.2 for MacOS.  
c  ** Based on MP008macC9, BA94C9 and MA94DC9
c  **
c  ** CHANGE HISTORY:
c  **
c  ** 07/27/99 First Successful Compile! (DCH)
c  ** 12/21/00
c  **
c  ** NOTES:
c  **
c  *********************************************************************
c  *********************************************************************


C                                                                       
C                   RADCOM:      CONTROL/INPUT PARAMETERS
C
      IMPLICIT REAL*8 (A-H,O-Z)
      COMMON/RADCOM/VADATA(11, 4, 3),DLAT(46),DLON(72),TAUMIN,FULGAS(18)
     A             ,FRACSL,RATQSL,FOGTSL,PTLISO,TLGRAD,TKCICE,FGOLDH(18)
     B             ,FLONO3,FRAYLE,FCLDTR,FCLDSR,FALGAE,FMARCL,FEMTRA(6)
     C             ,WETTRA,WETSRA,DMOICE,DMLICE,LICETK,NTRACE,FZASRA(6)
     D             ,ID5(5),ITR(4),IMG(2),ILG(2),LAPGAS,KWVCON,NORMS0,NV
     E             ,KEEPRH,KEEPAL,ISOSCT,IHGSCT,KGASSR,KAERSR,KFRACC
     F             ,MARCLD,LAYRAD,NL,NLP,JMLAT ,IMLON ,KFORCE,LASTVC
C
C                                BASIC RADCOM INPUT DATA
C
     G             ,PLB(40),HLB(40),TLB(40),TLT(40),TLM(40),U0GAS(40,9)
     H             ,ULGAS(40,9),TRACER(40,4),CLDTAU(40),SHL(40),RHL(40)
     I             ,POCEAN,PEARTH,POICE,PLICE,AGESN,SNOWE,SNOWOI,SNOWLI
     J             ,TGO,TGE,TGOI,TGLI,TSL,WMAG,WEARTH,ZOICE,FSPARE(200)
     K             ,S0,COSZ,PVT(11),BXA(153),SRBXAL(15,2),FRC(5),LUXGAS
     L             ,JYEAR,JDAY,JLAT,ILON,MEANAL,KALVIS,ISPARE(25),PSIG0
C
C                                BASIC RADCOM OUTPUT DATA
C
     M             ,TRDFLB(40),TRUFLB(40),TRNFLB(40),TRFCRL(40),TRSLCR
     N             ,SRDFLB(40),SRUFLB(40),SRNFLB(40),SRFHRL(40),SRSLHR
     O             ,SRIVIS,SROVIS,PLAVIS,SRINIR,SRONIR,PLANIR,SRXATM(4)
     P             ,SRDVIS,SRUVIS,ALBVIS,SRDNIR,SRUNIR,ALBNIR,FSRNFG(4)
     Q             ,SRTVIS,SRRVIS,SRAVIS,SRTNIR,SRRNIR,SRANIR,FTRUFG(4)
     R             ,TRDFGW,TRUFGW,TRUFTW,BTEMPW,TRDFSL,TRUFSL,DTRUFG(4)
     S             ,TRSLTS,TRSLTG,TRSLWV,TRSLBS,TTRUFG,LBOTCL,LTOPCL
C
C                                BLOCKD INITIALIZED DEFAULT DATA
C
      COMMON/BLOCKD/AGOLDH(11, 5),BGOLDH(11, 5),CGOLDH(11, 5)
     T             ,TRAQEX(25,11),TRAQSC(25,11),TRACOS(25,11)
     T             ,TRCQEX(25, 2),TRCQSC(25, 2),TRCCOS(25, 2)
     S             ,SRAQEX( 6,11),SRAQSC( 6,11),SRACOS( 6,11)
     S             ,SRCQEX( 6, 2),SRCQSC( 6, 2),SRCCOS( 6, 2)
     X             ,AOCEAN(25   ),AGSIDV(25, 4),CLDALB(25, 2)
     Y             ,CMANO2(42   ),TRACEG(25,16),PPMV58(9),Z0(9),ZH(9)
     Z             ,ASNALB(15),AOIALB(15),ALIALB(15),NAERO,NGOLDH,NKSR
C
      COMMON/WORK4/ ITLB(40),ITLT(40),PL(40),DPL(40),UO3L(40),PSIG(40)
     T           ,COSLAT(46),TRCALB(40),TRGALB(40),BGFEMT(40),BGFEMD(40)
     T             ,TRAEXT(40,25),TAUN(1000),TAUSL(25),FTAUSL(25)
     T             ,ENA(40),ENB(40),ENC(40),TRA(40),TRB(40),TRC(40)
     T             ,WTLB(40),WTLT(40)
     T             ,DFLB(40,25),UFLB(40,25),WFLB(40,25)
     T             ,DFSL(25),UFSL(25),WFSL(25)
     S             ,EXTAER(40,6),SCTAER(40,6),COSAER(40,6),PI0AER(40,6)
     S             ,RNB(40),RNX(40),TNB(40),TNX(40),XNB(40),XNX(40)
     S             ,SRB(40),SRX(40),VRU(40),VRD(40),FAC(40),O3A(40)
     S             ,BVSURF,BNSURF,XVSURF,XNSURF
     X             ,UXGAS(40,9),SRTAU(600)
C
C
      COMMON/TRDCOM/TRAX(40,25,5),TRCX(25,2),PLANCK(6250),TAUTBL(80000)
     A             ,TAULAP(1000),TKPFW(630)
     B             ,ITRHDR(100),MLGAS(30),MLLAP(30),NKTR,IT0,ITNEXT
     C             ,JNORTH,ALVISD(22),ALNIRD(22)
C$   D             ,ISRHDR(100),SRTBL(44800)
C

in Conclusion

OK, that’s enough for this one posting. The others will most likely get into the actual formulas and operations applied. There will be some kind of “load the data into the arrays” process, then a “stir the pot” and finally a “dump out the stew”, but at this point it is likely we have some clue about the goals and drivers of the program. It ASSUMES that FORCING will be via “Greenhouse Gasses” and that not much else is a driving parameter. Much of the rest will be ‘tuned’ values to let the GHG fantasy unfold as desired / expected.

Having read the Hansen paper about the model, that is much of what it says, reading between the lines. Things like “vegetation has to be like this or things are not right” and “temperatures were 15 degrees too high in the arctic until we tuned FOO”. More on that paper in a later posting too. (It is a PDF and quoting them can be a pain, so I put it off…)

For now, We’ve got a pretty good handle on the nature of the model.

Left to do?

-rw-r--r-- 1 chiefio chiefio 240095 Apr 17  2008 DB11pdC9.f
-rw-r--r-- 1 chiefio chiefio  13208 Aug  2  2005 FFT36macDBL.f
-rw-r--r-- 1 chiefio chiefio 204365 Mar 23  2006 Mjal2cpdC9.f
-rw-r--r-- 1 chiefio chiefio 331692 Jan 17  2006 Pjal0C9.f
-rw-r--r-- 1 chiefio chiefio 555793 Aug  2  2005 R83ZAmacDBL.f
-rw-r--r-- 1 chiefio chiefio 128314 Aug  2  2005 RFRCmacDBL.f

The FFT* program (that does a Fast Fourier Transform… I peeked ;-) and then 5 other large chunks. Each of them likely to take a whole posting just by themselves. They range from 1600 to just under 7000 lines each, so I’m unlikely to quote them in their entirety…

With that, I’m off for a cupp-a and some sofa time… ;-)

Subscribe to feed