Global Warming - GCM Model-E
Basic Source Code Modifications

On another page, I described the steps necessary to get the model to compile and run. Unfortunately, there were a number of additional problems discussed here.

Data Files | "End of file" Error | SYSTEM.f | Success | Long Run | Optimization | Other Issues

Data Files

The model comes with a number of data files. Scripts are provided to create links to these. On Unix systems, the program accesses the files by opening the links in the current directory.

On Unix systems,

I know, this is very complicated ... in addition, it will not work on Windows. Sure, Windows XP supports creating links to files, but, unfortunately, the links are themselves files that must end in the extension lnk. As a result, the alias names in the code will never match those created in Windows.

A much simpler system is to just have the program get the filenames directly from the rundeck (configuration file). For test purposes, I modified the rundeck so that the filenames and aliases would be processed like the other parameters. Then I wrote a small subroutine to lookup the file names. (I just copied and modified the beginning of the openunit subroutine.)

Of course, I had to locate and change the calls to openunit and, in a few files, I had to add openalias to the list of used subroutines.


In RADIATION.f, there was also a call to inquire (to check if the file exists) that had to be modified to use the aliases. The following is a potential model error - if the hardcoded file sep2003_PRE_Koch_kg_m2_ChinSEA_Liao_1850 does not exist, then it looks in the rundeck (uses the linked file). It seems to me that it should try the rundeck first so that the user can control which file is used.

"End of file" Error

The program started, processed the rundeck, one data file ... then crashed with the following error. (This was only visible when running in a command Window, not when double clicking a link.) This problem was fixed by adding the following to the command line. At this point, the model ran until there was another crash - this time it wanted to send a report to Microsoft. See SYSTEM.f for the fix.

Little Endian / Big Endian

When computers store numbers in multiple bytes, some systems store the big parts first and others store the small parts first. As a result, it is a common hassle to move data from one type of system to another.

Fortunately, GNU Fortran provides a command extension to specify how binary data is read ... which is real useful if you know how the data is stored.

Reviewing the support scripts and the source code indicated that Big Endian should be specified via the command line.


SYSTEM.f is the source file that needs customization for various compilers. The program would not even run until multiple defined(MACHINE_XP) statements were added. Since I didn't know what I was doing, I just guessed where to place these. In general, I added them to the first option ... generally the option that supported the most other compilers.

I had to change that guess for the following subroutine - gfortran requires a variable for signal's optional third parameter ... a constant causes a system crash.


Possible success - the run produced the following message. Now the fun begins.

The initial rundeck - E001.R - only simulates 1 hour.

On the one hand, this is good because it made debug a lot faster. Change Ending Year - YEARE - etc as appropriate.

Long Run

As a test, I just commented out the test parameters and let the model run from 12-01-1949 till 01-01-1956 (about 6 years). After running for 10 hours 23 minutes (and only simulating about 7 months), there was an error. The error can be ignored by changing this line in the rundeck.

I recompiled with the -O2 switch and ran it for only one month, it crashed with the following after 57 minutes.

This looks like round off error to me.

Apparently, several files write the errors only to zero.


The original compiles did not include the -O2 optimization flag (mainly so the program would compile faster while performing basic debug). Using this configuration, 7 months of simulation ran in 10.5 hours, providing an estimate of 1 hour 30 minutes per month of simulation.

Adding -O2 optimization reduced the runtime to 57 minutes per month. (Actually it crashed at 57 minutes.)

 1.92395 minutes per day
57.7     minutes per 30-day month
11.7     hours per year

compile w/o -O2 :24 to :28 - 4 minutes to compile
compile w/  -O2 :42 to :48 - 6 minutes to compile

Other Issues

There are 2 issues that I haven't had to address.

crlf issues - The software reads one line at a time, but how are lines defined? Unix and Windows systems use different characters to indicated the end of a line. Apparently, the Fortran libraries correctly handle the Unix codes on a Windows system ... or not. The model still crashes and this is a possible cause.

The notes that come with the model indicate that some systems crash if the stack size is not manually set. So far, I have not had a problem with this.

Author: Robert Clemenzi
URL: http:// / Global_Warming / Model_E / Basic_Sourcecode_Mods.html