Go to the bottom of this page. See the search engine and sub-section links.
Go to next page Go to previous page Go to top of this section Go to top page Go to table of contents

Previous Section Headers

User's Guide to NCAR CCM3.6 Search Page


3. CCM3.6 Internals
    3.3 Data Structures


3.3.2 Gridpoint Data Structures

Prognostic variables held in gridpoint space (as opposed to spectral space) and many arrays associated with the semi-Lagrangian transport scheme (SLT) are maintained in-core. Other gridpoint fields exist either in one of the three buffers (main model buffers, radiation buffer, history buffer), or as local workspace in individual routines. All gridpoint data are stored with longitude as the fastest varying (innermost) subscript, followed by (if applicable) level, constituent, latitude, and finally time. Longitude indices start at Greenwich and proceed from west to east around the globe. Level indices run from the top of the atmosphere to the bottom. Latitudinal ordering is from south to north.

The term "constituent" used above refers to water vapor plus an arbitrary number of user-defined advected or non-advected species. The number of advected constituents, defined by Fortran parameter pcnst, will always be at least one since water vapor is always transported in the default configuration. The number of non-advected constituents is defined by Fortran parameter pnats. The variable lat is used throughout to represent the current latitude index. Two time-level indices are necessary for the prognostic variables due to the leapfrog time integration scheme.

Gridpoint arrays are almost universally declared with longitude dimension plond, where plond = plon + 1 + 2*nxpt. Parameters plond, plon, and nxpt are all defined in header file pmgrid.h.

Parameter plon is the number of actual data points in the longitudinal direction. nxpt is a wrapping number required by the SLT package. Arrays that go through the Fourier transform require two additional longitude points to accommodate storage of the wave 0 (mean) information. Arrays used by the SLT code require at least 1 additional longitude point at the beginning of most arrays, and at least 2 additional points at the end. To avoid proliferation of a dizzying assortment of longitude dimensions,  plond is used wherever possible, whether or not the full dimensionality is required.

Actual data start at longitude location 1 + nxpt for all of the prognostics except surface pressure (zonal and meridional wind components, temperature, moisture) and location 1 for all other non SLT-specific arrays. Surface pressure data (in /com3d/) start at location 1 because this array is not used in the SLT package. This difference in starting location of the physical data poses an indexing problem for non-SLT routines which operate in gridpoint space. It is undesirable to have to keep track of where the physical data start in every array. The solution chosen was to pass the address of where the data start to non-SLT routines at a very high level in the calling tree. For example, consider the call to linemsbc from scan1bc (this is very high in the calling tree: refer to Figure B ). Some of the calling and declaration sequence looks like:



scan1bc:

    call linemsbc(...,ps(1,lat,n3m1),
$                 u3(i1,1,j,n3),...) linemsbc:
 
    subroutine linemsbc(...psm1,u3,...)
    real psm1(plond)
    real u3(plond,plev)
In scan1bc, each argument passed to linemsbc represents the starting location of the physical data for that field (i.e. the variable i1 is equal to 1 + nxpt, which is the starting index for the physical data in array u3). Thus all references to fields in linemsbc and below can begin at array element 1. The user need not be concerned with offsets unless they are working with code at the scan1bc level or higher where the full data structures are available.

Analogous to the longitudinal case, additional nonphysical gridpoints are needed by the SLT package in the latitudinal dimension. Some arrays are therefore dimensioned platd, where platd = plat + 2*nxpt + 2*jintmx. Fortran parameter plat is the number of actual latitudes, while nxpt and jintmx are extensions beyond the southernmost and northernmost physical locations (as defined in pmgrid.h). The starting latitude index for physical data in these arrays is 1 + nxpt + jintmx.  Routine scan1bc, for example, passes the array addresses corresponding to the latitude indices for which physical data actually exist.

In the above example, at the level of linemsbc latitude indices are no longer present because all computations in linemsbc and below are independent of latitude. A similar approach is used with the array that contains water vapor plus other advected constituents. In the radiation code for example, water vapor is the only relevant constituent. Therefore, array h2ommr in the radiation package has no constituent index. 


Sub Sections

    3.3.2.1 Model Buffers
    3.3.2.2 History Buffer
    3.3.2.3 Absorptivity/Emissivity Arrays
    3.3.2.4 Out-of-Core Data Storage: The SSD Work Units
    3.3.2.5 Local Workspace
    3.3.2.6 In-Core Grid-point Arrays


 Go to the top of this page. See links to previous section headers.
Go to next page Go to previous page Go to top of this section Go to top page Go to table of contents

 Search for keywords in the CCM3.6 Users GuideSearch page

Questions on these pages can be sent to... erik@ucar.edu .


$Name: ccm3_6_6_latest2 $ $Revision: 1.41.2.1 $ $Date: 1999/03/25 21:38:23 $ $Author: erik $