WORKING GROUP 2: SOFTWARE ARCHITECTURE, STANDARDS AND IMPLEMENTATION

Representatives:

Tiger Team

Please click here for information on the WRF Software Training and Documentation Team.

The WRF f90tohtml code browser designed by Brian Fiedler et al. is set up to run with the NCAR development copy of the code. This browsable source code is kept fairly up-to-date with the WRF repository (check the date/time stamp in the top left frame on the WRF code browser).

Status:

Work for the group is proceeding in four main areas:
  1. code development
    • The original design of the WRF model is found in this ECMWF preprint (Michalakes et al., 1998). Users may choose either the PostScript version or the MS Word version of this document. Much of the intent of the early design of WRF (automated variable registry, separate program layers, naming conventions) is explained in detail.
    • Timing results for WRF with the (i,j,k) and (K,i,j) ordering are still preliminary. These timings reflect array index ordering (identical to array storage ordering) for a prototype of the WRF model using the Runge-Kutta second order time differencing scheme, Kessler explicit moisture (basically, a cloud model). No other physical parameterizations are included (i.e., cumulus, PBL, radiation, surface processes, soil, etc.).
  2. scalable I/O
    • The groupd is working on a draft I/O architecture for WRF, covering the issues of software layers and interfaces between layers.
    • There is also the issue of meta-data conventions and data formats; we can discuss what our group's position on this will be. My view is that a reasonable position will be that we defer the actual decision making to the Standard Initialization gorup, who volunteered to lead on this one, but that the I/O architecture will be such that it will be adaptable (by design) to different implementations of data format layers.
  3. coding standards
  4. source code control - maybe CVS with pserver option
    • most of the group's members use cvs for source management control
    • new cvs with pserver has significant advantages
    • client-server connection, no longer need cross mounted (NFS mounted) disks, such as for the repository
    • non-NFS "fixes" Linux 2.2 bug implicitly (corrupting file system with NFS mounts)
    • permits cvs checkout and commit from outside firewall (tested and running currently at NCAR/RAP)
    • does not require an exposed host

Plans:

For the March 29 and 30 meetings in Boulder CO:
  1. code development: present recommendations on code ordering for prototype
  2. scalable I/O:
  3. coding conventions: present coding conventions doc for review by WRF group
  4. source code control: present list of issues to consider and possible packages

Interaction with other WRF Groups: