Global Warming - GCM Model-E - Basic Source Code Modifications

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

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,

A script reads the rundeck and creates
- A script to link the files
- A script to unlink the files
- A script to run the model
Then the RunScript is executed and it
- Calls the script to link the files
- Executes the program
- Calls the script to unlink the files

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.)

      subroutine openalias( filealias, iunit, qbin, qold )
      USE PARAM

!@sum openalias calls openunit with the filename associated with the provided alias
      implicit none
!@var unit - unit of opened file, used in read and write commands
      integer, intent(out) :: iunit
!@var filealias - alias use the find the name of the file to open
      character*(*), intent(in) :: filealias
!@var qbin - .true. if file is binary (.false. by default)
!@var qold - .true. if file is old (.false. by default)
      logical, optional, intent(in) :: qbin, qold
      character*255 filename

      call get_param( filealias, filename )
      call openunit( filename, iunit, qbin, qold )

      end subroutine openalias

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.

RADIATION.f

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.

      character*255 filename ! added 11-08-08 rlc

c          inquire (file=ddfile(n),exist=qexist)  ! fails with the aliases - 11-08-08 rlc
          call get_param( ddfile(n), filename )   ! added 11-08-08 rlc

          inquire (file=filename,exist=qexist)    ! added 11-08-08 rlc

c          call openunit (ddfile(n),ifile,qbinary)
          call openalias (ddfile(n),ifile,qbinary) ! 11-08-08 rlc

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.

      inquire (file=dtfile,exist=qexist)
      if(.not.qexist) dtfile='RH_QG_Mie  ' ! generic name used by GCM
      inquire (file=dtfile,exist=qexist)
      if(.not.qexist) call stop_model('setrel: no RH_QG files',255)

"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.)

At line 1839 of file SEAICE.f (unit = 51, file = 'GIC.E046D3M20A.1DEC1955')
Fortran runtime error: End of file

This problem was fixed by adding the following to the command line.

-DCONVERT_BIGENDIAN

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

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.

      SUBROUTINE sys_signal (sig, prog)
!@sum system call to "signal"
!@auth I. Aleinov
!@ver  1.0 (SGI,IBM,Linux,Dec) !! should check if works with DEC !!
      IMPLICIT NONE
!@var unit signal number to catch
      INTEGER, INTENT(IN) :: sig
!@var prog handler subroutine for given signal
      EXTERNAL prog
#if defined(MACHINE_SGI) || defined(MACHINE_Linux) || defined(MACHINE_DEC) || defined(MACHINE_MAC)
      call signal( sig, prog, -1 ) 
#elif defined( MACHINE_IBM ) || defined(MACHINE_XP)
      call signal( sig, prog )
#else
      None of supported architectures was specified.
      This will crash the compiling process.
#endif
      RETURN
      END SUBROUTINE sys_signal

Success

Possible success - the run produced the following message.

  Program terminated due to the following reason:
  >>  Terminated normally (reached maximum time)  <<

Now the fun begins.

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

 &INPUTZ
   YEARI=1949,MONTHI=12,DATEI=1,HOURI=0, ! IYEAR1=YEARI (default)
   YEARE=1956,MONTHE=1,DATEE=1,HOURE=0,     KDIAG=0,2,2,9*0,9,
   ISTART=2,IRANDI=0, YEARE=1949,MONTHE=12,DATEE=1,HOURE=1,
 &END

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.

  error = convective cloud opt. depth less than zero
 ISCCP CLOUD TYPING ERROR

  Program terminated due to the following reason:
  >>  ISCCP CLOUD TYPING ERROR  <<

The error can be ignored by changing this line in the rundeck.

isccp_diags=1   ! use =0 to save cpu time

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

  Program terminated due to the following reason:
  >>  In Radia: Q<0  <<

At the command prompt
 In Radia: Time,I,J,L,QL<0  8661   63  25   9  -2.95842105406229798E-025 ->0

This looks like round off error to me.

Apparently, several files write the errors only to zero.

          WRITE(0,*)'In Radia: Time,I,J,L,QL<0',ITime,I,J,L,shl(L),'->0'

Optimization

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