Jeff:

I've been thinking lately about how to rewrite/improve the time-gcm 
(tgcm) model, and have written up some goals and first thoughts.
Would you mind reading the below and send me your comments/suggestions.

I have not shown this to anyone else yet. I think that the current
ccm2 or ccm3 is a good "model" to follow in this process, especially
since we are currently coupling the two models together and may 
eventually introduce tgcm mesospheric/thermospheric physics and chemistry
directly into the ccm.

--Ben


5/7/96:
Considerations for a rewrite of the time-gcm source code:


Overall Goal:

To improve readability, modification and version control, portability,
"plug compatability", and i/o and memory structure without sacrificing
(and possibly improving) current levels of efficiency and performance.

All changes here proposed must have no affect on model results, i.e.,
no changes to numerical techniques, physics, or chemistry are proposed. 
This would be accomplished by freezing a current version of the model 
(e.g., the upcoming new tgcm20), and make changes while maintaining 
identical results between the new and the frozen versions. Although no
specific changes to history file format are proposed at this time,  
history file structure may be improved later as a result of some of
the long term goals (e.g., portability).

Some of the below proposed changes can be accomplished soon (over
a period of several weeks), whereas others are longer term goals
(over a period of 1-4 years).  In general, except where noted, proposed 
changes are given below in order of increasingly long-term goals.

Note that CRI has several performance and source code analysis tools
to assist in this process, e.g., flint, flowtrace, perftrace, hpm, 
profiler, etc.


Proposed changes:


1. Source code and version maintenance:

   a) Elimination of the update method of modification and version 
      control (nupdate is going away!).

   b) Maintain multi-file source with *.f and *.h or *.com files.
      Use fortran include statement.

   c) Use either "make", or compile and load modified code ahead
      of fixed (frozen) object.

   d) Consider use of a source code control package, although this 
      may not be necessary given the relatively small size of our
      research group.

   e) Build user libs for unchanging code, e.g., numerical packages.
      (probably also not necessary initially).


2. User Interface:

   a) Convert from lexrd to namelist (can be done almost immediately,
      with 1a above).

   b) Minor changes to inputs, e.g., more flexible history mss path
      specification and specification of external file paths for data 
      import (e.g., boundary conditions, geophysical indices, orography, 
      etc). 


3. Memory structure:

   a) Eliminate dependency on SSD for production runs, but retain SSD 
      as an option (current memory resident assign of SSD units results 
      in a total memory requirement of about 16Mw vs 6Mw with SSD)
       
   b) Develop an in-core version that would consume less than the 
      current memory resident useage of 16Mw (e.g., in-core progostics,
      out-of-core diagnostics, as in ccm). 

   c) Use of stack rather than static memory allocation.
      (have to be careful with this one -- may have unforseen consequences)


4. I/O (see also 3a and 3b above):

   a) Consolidate use of external data files (e.g., boundaries, GPI's,
      data imports, etc). (See also 2b above).

   b) Standardize and modularize all model/OS interface (improvements
      have already been made in this area during the past few years).
      
   c) Check efficiency of pre-allocation, and compare various i/o methods.


5. Code restructure: 
   (a and b will probably require massive re-coding and are considered
    longer term goals)

   a) Array and common block restructuring. Eliminate  the "f-array",
      use of "pointers", and blank common. 

   b) Improve readability and in-code documentation.

   c) In-lining of small heavily used functions, and elimination of
      out-dated cray specific vector/CAL routines (e.g., the "Q"
      routines, "CVMxx" functions, etc.).

   d) Above changes should allow use of compiler options such as bounds 
      checking, and ease the use of debugger and other development tools.


6. Speed/performance:

   Goal: To accomplish the above proposed changes with no net decrease
         in current performance levels (current code runs about 16 Mflops,
         and is heavily vectorized).


7. Multi-tasking:

   Goal: To accomplish the above changes as a first step toward
         multi-tasking. I.e., multi-tasking must begin with a stable
         fortran-standard code. Multi-tasking can be accomplished
         at the latitude slice level (as in the ccm).


8. Portability:

   Goal: As in multi-tasking above, establish a stable standardized
         source with as little dependence on Cray specific code as
         possible as a first step toward running the model on workstation
         clusters or parallel machines.