Notes based on the acpi-atm meeting may 4-5 2000.
Byron Boville

There was a surprising (to me) level of consensus on adopting true
object oriented methods, at least for the upper layers of the
ccm. What follows is a summary of the reasons for that consensus. 

The code would be entirely implemented in fortran 90, at least
initially. 
  This causes problems with debuggers when using user
  defined data types.


-> It is essential that the T42 ccm be able to use more than 32
processors effectively. The execution (wall clock) time for the
prototype ccm4 is about 2.5 minutes/day using 16 processors on the IBM
SP (babyblue). This is worse than CCM0 on a CRAY1 in 1980, when 120
day rather than 5 year runs were fairly standard.

-> Load balance requirements mandate different data decompositions
between the dynamics and column physics sections of the model for
scaling. 
  + Scaling effectively beyond 32 processors REQUIRES a transpose 
    between dynamics and physics.

-> Supporting multiple dynamics algorithms requires isolating the
dynamics and column physics as completely as possible, with a well
defined interface. However, one cannot define the data requirements of
all future physics parameterizations.  
  + Extensibility of the interface is required.
  + A procedural interface, with all communication through argument
    lists will be difficult to maintain and extend for multiple
    dynamics/physics combinations.


-> The most obvious solution is to adopt true object oriented
programming for upper layers of model. No weasel words like "adopt
elements of".

-> Assume that the data decomposition requirements for the
paramaterizations are relatively invariant, because they are column
oriented. 
  + The decomposition will be in lists of columns.
  + The mapping of the lists to the globe will be problem dependent. 

-> The data decomposition requirements for the dynamics are strongly
dependent of the dynamics algorithm.

-> Communication between dynamics and physics will be through a state
object, consisting of state data and methods for moving the data
between the dynamics and paramterization data structures.
  + The required methods may include: 
	changing the data decomposition;
	regridding (e.g. Lin-Rood)
	calculation of derived variables (e.g geopotential, omega)
	conversion between updated states and tendencies
  + Implementation of the methods in the state object will be supplied
    with the dynamics code. 

-> The working layers of the models will remain as procedural code for 
the time being (indefinitely). 
  + Use of the state object will propagate down to the interface
    routine for each parameterization.
  + Use of the state object in the dynamics will probably be confined
    to its top level interface.

-> The initial implementation will require changing code down to the
parameterization interfaces.
  + Interface routines will use inquiry functions to obtain data from
    the state structure and will pass arrays to the working code.
  + Only pointers and sizes will be returned by inquiry functions,
    no data will be copied.
  + Performance tests will be required for the inquiry functions and
    associated pointer variables.
    - If the cost is too high, the inquiry would be pushed up from the 
      individual parameterization interface to the pyhsics interface
      (from xxinter to tphys).