00-ww3v607手册

<center>Manual v6.0.7</center>

手册下载

https://github.com/NOAA-EMC/WW3/wiki/Tech-Docs

• 
• 链接：https://pan.baidu.com/s/1Db2a46SGijSh5TOmUeB6rg
  提取码：l2zm
  –来自百度网盘
• fi
• 

Contents

1 Introduction

2 Governing equations

3 Numerical approaches

4 Wave Model Structure and Data Flow

4.1 Program design

The core of WAVEWATCH III is the wave model subroutine, which can be called by either a stand-alone program shell or any other program that requires dynamically updated wave data. Two such programs are provided with the WAVEWATCH III release (e.g., ww3_shel and ww3_multi). Auxiliary programs include a grid preprocessor ww3_grid, a program to generate artificial initial conditions ww3_strt, generic program shells for individual ww3_shel or multi-grid ww3_multi applications, two input pre-processors (ww3_prep and ww3 prnc), and post-processors for gridded (ww3_outf and ww3_ounf) and point (ww3_outp and ww3_ounp) output data.

In this section, note that file names will be identified by the file type font, the contents of a file by the code type font and fortran program elements by the fortran type font. The main wave model subroutine is w3wave. Data files are identified with the file extension .ww3, except in the multi-grid wave model ww3_multi, where the file extension identifies individual grids part of a chosen multi-grid mosaic. For simplicity, the file extension .ww3 will be used throughout this chapter.

A relational diagram including the basic data flow is presented in Fig. 4.1. The figure illustrates a typical workflow, as follows. The grid pre-processor ww3_grid writes a model definition file mod_def.ww3 with bottom and obstruction information and parameter values defining the physical and numerical approaches. The wave model may have cold or hot starts. Hot starting requires a restart file restart.ww3, created either by the wave model itself in a previous run, or by the initial conditions program ww3_strt. If a restart file is not available, the wave model will be initialized automatically. If linear growth or spectral seeding is switch on, the model may start from a flat ocean ( Hs = 0 ), otherwise the initial conditions will consist of a parametric fetch-limited spectrum based on the initial wind field (see the corresponding option in the initial conditions program).

The wave model routine (w3wave) optionally generates up to 9 restart files restartn.ww3, where n represents a single digit integer number. For telescoping nest applications, the wave model also optionally reads boundary conditions from the file nest.ww3 and generates boundary conditions for con-secutive nested runs in nestn.ww3. The model furthermore dumps raw data to the output files out_grd.ww3 , out_pnt.ww3, track_o.ww3 and partition.ww3 (gridded mean wave parameters, spectra at locations, spectra along tracks, and partitioned wave data, respectively). The tracks along which spectra are to be presented is defined in the file track_i.ww3. Note that the wave model does not write to standard output, because this would be inconvenient if WAVEWATCH III is part of an integrated model. Instead, it maintains its own log file log.ww3 and optionally a test output files test.ww3 for a shared memory version of the model, or testnnn.ww3 for distributed memory versions, where nnn is the processor number starting with 1. Finally, various output post-processors are available (binary post-processing of raw gridded fields, point output and track output files; NetCDF and GRIB(2) packing of wave data; post-processing for later GrADS graphical processing of gridded and spectral data). A more detailed description of all program elements and their input files is given below. Note that the source codes of each routine are fully documented. This documentation is an additional source of information about WAVEWATCH III.

Files specific to WAVEWATCH III are opened by name within program subroutines. The unit numbers, however, are defined by the user within each inp, guaranteeing the largest possible flexibility for implementation in integrated models.

In addition to the wave model subroutine, an initialization routine and an interface routine for data assimilation are provided. The routine includes a generic interface that provides all necessary model components to perform full spectral data assimilation. This routine is integrated into the generic wave model shell, which is set up to perform time step managements for a wave model with or without data assimilation. The shell also provides a simple yet flexible way to provide the data assimilation scheme with various types of data. Data assimilation has not yet been included in the multi-grid wave model shell.

4.2 The wave model routines

The wave model driver is a subroutine within the WAVEWATCH III framework package. To run the model driver subroutine, a program shell is needed. WAVEWATCH III is provided with a simple stand-alone shell as will be discussed in Section 4.4.10, and with a more complex multi-grid model shell as will be discussed in Section 4.4.12. The present section concentrates on the wave model driver subroutines.

The wave model initialization routine w3init performs model initialization for a single wave model grid. This includes setting up part of the I/O system by defining unit numbers, initializing internal time management, processing the model definition file (mod_def.ww3), processing initial conditions (restart.ww3), preparing model output, and calculating grid-dependent parameters. If the model is compiled for an MPI environment, all necessary communication for both calculations and output are determined and initialized (the model uses persistent MPI communication throughout).

The wave model routine w3wave can be called any number of times to propagate the wave field for a single grid in time after the initialization has taken place. After some initial checks, the subroutine interpolates winds and currents, updates ice concentrations and water levels, propagates the wave field, and applies the selected source terms for a number of time steps. The internal time step is defined by the interval for which the calculations are to be performed, and by the requested output times. At the end of the calculations, the routine provides the calling program with the requested fields of wave data. A documentation of the interface of w3wave can be found in the source code (w3wavemd.ftn).

Apart from the raw data files as described above, the program maintains a log file log.ww3. This file is opened by w3init (contained in w3wave in w3wavemd.ftn), which writes some self-explanatory header information to this file. Each consecutive call to w3wave adds several lines to an ‘action table’ in this log file as is shown in Fig. 4.2. The column identified as ‘step’ shows the discrete time step considered. The column identified as ‘pass’ identifies the sequence number of the call to w3wave; i.e., 3 identifies that this action took place in the third call to w3wave. The third column shows the ending time of the time step. In the input and output columns the corresponding actions of the model are shown. A X identifies that the input has been updated, or that the output has been performed. A F indicates a first field read, and an L identifies the last output. The seven input columns identify boundary conditions (b), wind fields (w), water levels (l), current fields (c), ice concentrations (i), and data for assimilation (d), respectively. Note that data assimilation takes place at the end of the time step after the wave routine call. The seven output columns identify gridded output (g), point output (p), output along tracks (t), restart files (r), boundary data (b), and partitioned spectral data (f), and output for coupling (c), respectively.

For the multi-grid wave model (Tolman, 2008b, ww3_multi) a set of rou-tines is build around the basic wave model routines. The three main routines are the initialization routine wminit, a time stepping routine wmwave and a finalization routine wmfinl, with similar functions as the routines for a single grid as described above. Note that the raw input and output files are generated for separate grid in the mosaic, and are identified by replacing the standard file extension .ww3 with a unique identifier for each individual grid as chosen by the user in the ww3_grid.inp file. Log files are maintained for each individual grid, as well as an overall log file log.mww3.

4.3 The data assimilation interface

As discussed above, the wave model subroutine is supplemented with a data assimilation interface routine (w3wdas in w3wdasmd.ftn). This routine is integrated in the stand-alone shell (see Section 4.4.10) to provide time step management of a combined wave model / data assimilation scheme. It has not yet been integrated in the multi-grid model driver, although it is accounted for in the multi-grid model management algorithm.

In this a fairly simple approach is assumed where data assimilation is performed at selected times, while the wave model marches forward in time. In the setup of the shell, the data assimilation is performed after the model has reached the target time, but has not yet produced output. After the data assimilation is performed, the wave model routine is called again only to generate output as requested. Thus, the wave model output for a given time will include the effects of data assimilation for that specific target time.

The generic program shell also processes several types of data to be assimilated, and passes it on to the data assimilation interface routine. All data needs to be preprocessed using the wave model input preprocessor (see Section 4.4.7), and will be recognized by the generic shell by file name. Presently, up to three different data files can be used. Tentatively, these could be mean wave parameters, one dimensional spectral data, and two dimensional spectral data, respectively. This is, however, not hardwired to the model and in fact needs to be defined by the user.

Presently, no data assimilation packages are available. Therefore, user supplied data assimilation schemes are required, and may be included in the wave model using the interface routine (w3wdas in w3wdasmd.ftn), the documentation of which should be sufficient for the necessary programming. Details on how to add user supplied software to the WAVEWATCH III compilation system can be found in the following chapter. Although NCEP is presently working on wave data assimilation techniques, there are no plans to distribute wave data assimilation software as part of the WAVEWATCH III package.

4.4 Auxiliary programs

4.4.1 General concepts

All auxiliary programs presented here, with the exception of the track output post-processor, read input from a pre-defined input file. Contents of that file determine user choices for each auxiliary program. Comment lines are allowed using a character determined by the user as follows: the first character on the first line of the input file will be considered to be the comment character, identifying comment lines throughout the input file. This comment character has to appear on the first position of input lines to be effective. In all examples in the following sections, the first character of the first line is $. Therefore, all lines starting with $ contain only comments that are not parsed into the auxiliary program. As a standard, auxiliary programs all write formatted output to the standard output unit.

注释问题~~

In the following sections, all available auxiliary programs are described using an example input file. These are found in the directory inp within the WAVEWATCH III package. Inside each sample input file, all possible options that can be activated by the user are included, most of them feature as comment lines starting with ’$’. Files in the current section reflect actual contents of sample files. The sections below also show the name of the executable program associated with the displayed input file, the program name (as appears in the program statement), the source code file and input and output files and their unit numbers (in brackets behind the file name). Input and output files marked with ∗ are optional. The intermediate files mentioned below are all unformatted, and are not described in detail here. Each file is written and read by a single routine, to which reference is made for addi -tional documentation.

这个图好像跟上面的内容不是很对应~~

Preprocessing and compilation of the programs is discussed in the following two chapters. Examples of test runs of the model are provided with the source code.

4.4.2 Configuration file

All auxiliary programs presented here read parameters and configuration from either a namelist file (new form) or an input file (legacy form). Although most auxiliary programs provide the option of a namelist file, some are still limited to using the legacy input file form. Namelist files for the latter programs will become available in future public releases. For programs which already use namelists, template files are stored in model/nml directory. It is also possible to convert the traditional inp file to new nml format using bash tools stored in the model/aux/bash directory. If inp and nml files are both present in the run directory, the priority will be given to the namelist file. For regtests, the default behavior is to run all the programs with inp file, the option -N must be added to rather use nml file. Some new features are only available with namelists and the future developments will mainly be designed for namelist use.

The namelist configuration file dedicated to a program provides a more readable and adaptative file. A nml file contains one or more namelists with default values for each parameter with the possibility to overwrite them by a user-defined value. There is no mandatory order to defined namelists in the nml file. A namelist starts by &SOMETHING NML and stops by /. If a section is skipped from the namelist file, all the default values will be used. When a program read its namelist file, all the default and user-defined values for all namelists will be outputted in a log file for more tracability.

The traditional way to read the program configuration is from a predefined input file. The first character on the first line of the input file will be considered to be the comment character, identifying comment lines in the input file. This comment character has to appear on the first position of input lines to be effective. In all examples in the following sections lines starting with $ therefore only contain comment. The programs furthermore all write formatted output to the standard output unit.

Below is the part of an inp file with the corresponding part of nml file:

4.4.3 ww3_grid: The grid preprocessor

输入是 5 个文件，我TMD在2022寒假里总结的 5+1，其实这里已经包含了，┭┮﹏┭┮

但貌似验证了 ww3_grid 的输入确实是 5 个文件，o(￣▽￣)ブ

Note that bottom and obstruction data may be in same file.

4.4.4 ww3_strt: The initial conditions program

4.4.5 ww3_bound: The boundary conditions program

inout 教程里~~spectra file

4.4.6 ww3_bounc: The NetCDF boundary conditions program

4.4.7 ww3_prep: The input field preprocessor

Note that the optional output files are specific to ww3_shel and ww3_multi, but are not processed by the actual wave model routines. These files are consequently not needed if the wave model routines are used in a different shell or in an integrated program. However, the routines reading and writing these files are system-independent and could therefore be used in customized applications of the basic wave model. The reading and writing of these files is performed by the subroutine w3fldg (w3fldsmd.ftn). For additional documentation and file formats reference if made to this routine.

4.4.8 ww3_prnc: The NetCDF input field preprocessor

See note at the end of the previous section (4.4.7) for tools that can be used to pack input files in custom programs.

4.4.9 ww3_prtide: The tide prediction program

The user-provided file current.ww3_tide or level.ww3_tide is a binary file that can be obtained by running ww3_prnc with the AT option and then renaming the resulting file current.ww3 or level.ww3 into current.ww3_tide or level.ww3_tide . The choice of tidal constituents used for the tidal prediction can be a subset of the ones present in these files or all of them.

Because of wetting and drying or grid mismatches, the tidal constituents may be erroneous or absent for some of the WAVEWATCH III nodes. The erroneous ones can be detected using a maximum amplitude on particular components. When the amplitudes exceeds these maxima, then the tidal constituents are extrapolated from the nearest nodes. This feature has only been tested on triangular meshes.

4.4.10 ww3_shel: The generic shell

终于知道你这个 shell了；

4.4.11 ww3_gspl: Automated grid splitting for ww3_multi (ww3_gspl)

To further automate the splitting of the grid, a script ww3_gspl.sh is provided. This script runs ww3_gspl, and subsequently generated the mod_def files for all sub-grids. If a file ww3_multi.inp is provided, then this file is updated too. The workings of the script are shown with the -h command line flag, which results in the output of the script as shown in Fig. 4.3.

4.4.12 ww3_multi: The multi-grid shell

This wave model program requires and produces a plethora of input and output files consistent with those of ww3_shel in Section 4.4.10, where file extensions .ww3 are replaced by an identifier for a specific grid. Note that all files are opened by name, and that the unit number assignment is dynamic and automatic.

In order to make all existing features available there is a new version of the input file that uses namelists. This is the version that will be supported in the future as it allows a more flexible addition of new features. Please note that the namelist form is not supported by GCC compilers before version 4.8.2.

4.4.13 ww3_gint: Grid Integration

This post processor program takes field data from several overlapping grids and produces a unified output file. The different model definition and field output files are identified by the unique identifier associated with each specific grid. At this moment the program works with curvilinear and rectilinear grids. A weights file WHTGRIDINT.bin is written that can be read in subsequent runs using identical origin-destination grids, saving substantial time in cases using large number of input grids and/or high-resolution target grids.

不是现场数据，是场数据

Note that this program can be used in concert with the grid splitting program ww3_gspl, and that ww3_gspl.sh has an option to produce a template input file for his program (see Section 4.4.11).

4.4.14 ww3_outf: Gridded output post-processor

The extension of the file name of transfer files for itype = 3 identifies the content of the file. The file extension for each data type is given in Table 4.1 on page 221.

4.4.15 ww3_ounf: Gridded output NetCDF post-processor

When a single field is put in the file, the abbreviated field name (file extensions from ww3_outf) for each data type is given in Table 4.1 on page 221.

4.4.16 gx_outf: Gridded output post-processor for GrADS

This post-processor generates input files with gridded model parameters for the Grid Analysis and Display System (GrADS, Doty, 1995). Although GrADS can also work with GRIB files, the present preprocessor is preferable, as the data file also gives access to a land-sea-ice map.

4.4.17 ww3_grib: Gridded GRIB output post-processor

This post-processor packs fields of mean wave parameters in GRIB format, using GRIB version II and NCEP’s w3 and bacio library routines, or in GRIB2, using NCEPS’s operational package. Additional packing data can be found in Table 4.1 on page 221.

The GRIB packing is performed using the NCEP’s GRIB tables as described in NCEP (1998). Because the w3 and bacio routine are not fully portable, they are not supplied with the code. The user will have to provide corresponding routines. It is suggested that such routines are activated with additional WAVEWATCH III switches in the mandatory switch group containing the ‘nogrb’ switch, as if presently the case with the NCEP routines. The GRIB2 packing is performed according to WMO (2001), and is performed with NCEP’s standard operational packages.

Table 4.1 shows the kpds(5) data values for GRIB packing. For the partitioned data, the first number identifies the wind sea, the second number identifies swell. Most data are packed as surface data (kpds(6) = 0). For the partitioned swell fields, however, consecutive fields are packed at consecutive levels, with the level type indicator set to (kpds(6) = 241). kpds(7) identifies the actual level or swell field number.

Table 4.1 shows several kpds data values for GRIB2 packing. The first number in the table represents listsec0(2), which identifies the discipline type (e.g., oceanography, meteorology, etc.) The second number represents kpds(1), which identifies the parameter category (e.g., waves, circulation, ice, etc.) within the discipline type. The third number represents kpds(2), which identifies the actual parameter. For the partitioned data, A/B means A for wind sea and B for swell. Additionally kpds(10) = 0 for surface data, and kpds(10) = 241 to pack consecutive swell fields at consecutive levels.kpds(12) identifies the actual level or swell field number.

Although the above input file contains flags for all 31 output fields of WAVEWATCH III, not all fields can be packed in GRIB. If a parameter is chosen for which GRIB packing is not available, a message will be printed to standard output. Table 4.1 shows which parameter can be packed in GRIB.
Note that at NCEP the conversions from GRIB to GRIB2 coincided with the introduction of partitioned wave model output. This required some duplicate definitions in GRIB and some apparent inconsistencies between GRIB and GRIB2 packing.

4.4.18 ww3_outp: Point output post-processor

4.4.19 ww3_ounp: Point output NetCDF post-processor

4.4.20 gx_outp: Point output post-processor for GrADS

4.4.21 ww3_trck: Track output post-processor

4.4.22 ww3_trnc: Track output NetCDF post-processor

4.4.23 ww3_systrk: Spatial and temporal tracking of wave systems

4.4.24 ww3_uprstr: The Restart File Processor

Table 4.1

5 Install, Compile and Run the wave model

5.1 Introduction

WAVEWATCH III is written in ANSI standard FORTRAN-90, with no machine-dependent elements, so that WAVEWATCH III can be installed without modifications on most platforms. WAVEWATCH III utilizes its own preprocessor to select model options at the compile level, and to switch test output on or off. This approach proved to be efficient during the development of WAVEWATCH III, but complicates its installation. To minimize complications, a set of UNIX/Linux scripts is provided to automate the installation in general and the use of the preprocessor in particular. Note this option is not supported for other operation systems like MS products. If the code is to be compiled on one of the latter platforms, it is suggested to extract a working code in a UNIX/Linux environment using the utility w3_source (see below), and then to port this clean code to the platform of choice.

机器相关 ➡ 机器依赖

If version 6.07 is implemented as an upgrade to previous versions of WAVEWATCH III, please note that this version may not be compatible with previous model versions. It is therefore prudent NOT to install the new version of WAVEWATCH III on top of the old version.

5.2 Distribution

Through version 5.16, WAVEWATCH III public releases were released as tarballs. After the public release of version 6.07, WAVEWATCH III will move to an open development paradigm and source code is distributed via Github.

5.3 Installing

5.4 Setting up

5.5 Directory Structure

After cloning the WAVEWATCH III repository, the following directories are found on the top level.

The following directories exist in the model directory of WAVEWATCH III.

The following directories are generated in the model directory after compiling the code.

The aux directory has various additional tools, see the actual directory for its contents. These include contributed Matlab codes, IDL tools, bash scripts and GrADS and FORTRAN programs.

Setting up WAVEWATCH III runs the installation the auxiliary programs will first process FORTRAN codes, using the compiler as defined in the setup file wwatch3.env. Note that these codes are still in fixed format FORTRAN77. The executables are stored in the directory bin. A more detailed description of these programs (including instructions on running the executables) can be found in the documentation included in the above source code files. After the compilation of these programs, several UNIX shell scripts and auxiliary files are installed in the bin directory.

w3adc.f	WAVEWATCH III FORTRAN preprocessor.
w3prnt.f	Print files (source codes) including page and line numbers.
w3list.f	Generate a generic source code listing.
w3split.f	Generate spectral bulletin identifying individual wave fields within a spectrum from the spectral output of the point output post-processor (seeSection 4.4.18). This is a legacy code superseded by generating bulletins directly from ww3_outp. It is retained here for historical reasons only.

The bin directory has various UNIX scripts to manage the WAVEWATCH III framework. The use of these scripts is explained in Section 5.7. Note that the following scripts acquire setup information from the WAVEWATCH III environment setup file defined by WWATCH3_ENV. Either defined by w3_setenv which read the local wwatch3.env or by the user environment file.

Main programs used :

install_ww3_tar	Script to install WAVEWATCH III from tar files.
w3_setup	Script for creating/editing the WAVEWATCH III environment setup file. The default setup file isbin/.wwatch3.env. switch and compiler are given in arguments. (see options)
w3_clean	Script to clean up WAVEWATCH III directories by removing files generated during compilation or test runs. 3 levels of clean-up. (see options)
w3_make	Script to compile and link components of WAVEWATCH III using a makefile. A list of programs can be given in arguments.
w3_automake	Script to automatically compile separately sequential and distributed programs in MPI, OMP or HYB depending on the switch file content. A list of programs can be given in arguments.
w3_new	Script to touch all correct source code files to account for changes in compiler switches in combination with the makefile.
ww3_gspl.sh	Script to automate use ofww3_gspl program (see Section 4.4.11).
arc_wwatch3_tar	Program to archive versions of WAVEWATCH III in the directoryarc.
ww3_from_ftp.sh	Script to download all the binary files not provided by git.

Examples files provided :

switch_xxx	Examples of preprocessor switches provided by users or developers. (Section 5.9)

Subprograms called :

w3_setenv	Script to setup the environment based on bin/.wwatch3.env. Called by all auxiliary programs.
comp.tmpl	Compiler script templatecomp used with cmplr.env.
link.tmpl	Link script templatelink used with cmplr.env.
cmplr.env	compiler options tested on intel, mpt, gnu, pgi with optimized and debugging options. used withcomp.tmpl and link.tmpl.
make_makefile.sh	Script to generate the makefile based on selections in the file switch.
ad3	Script to run the preprocessorw3adc and the compile script comp for a given source code file.
ad3_test	Test version ofad3, showing modifications to original source file. This script does not compile code.
all_switches	Generates a list of allw3adc switches present in the source code files.
find_switch	Script to find WAVEWATCH III source code files containing compiler switches (or arbitrary strings).
sort_switch	Order the switches present in the switch file.
sort_all_switches	Script to search all the switch files in WAVEWATCH III and call sort switch.

Extra programs :

comp.xxx	Compiler script comp for advanced setting.
link.xxx	Link scriptlink for advanced setting.
make_MPI	Script to separately compile MPI and non-MPI programs. (obsolete in future releases - usew3_automake)
make_OMP	Script to separately compile OpenMP and single threaded programs. (obsolete in future releases usew3_automake)
make_HYB	Script to separately compile hybrid MPI-OpenMP and single threaded programs. (obsolete in future releases - usew3_automake)
ln3	Script to make symbolic link of source code file to work directory. (not used)
list	Script to print source code listing using w3prnt. (not used)
w3_source	Script to generate a true FORTRAN source code for any of he WAVEWATCH III program elements. (not used)
WW3_switch_process	Perl script to process switch from a source file. (not used)

After installation in the bin directory, several GrADS scripts are installed in the aux directory.

cbarn.gs	Semi-standard GrADS script for displaying color bars.
colorset.gs	Script to define colors used in shading.
profile.gs	Script to display profiling data generated by ww3_multi.
source.gs	Script for composite plot of spectra and source terms (2-D polar or Cartesian plots in color or in black and white).
1source.gs	Script to plot single source term.
spec.gs	Script to plot spectra.
spec_ids.gen	Data file used by spectral / source scripts.

5.6 Optional environment settings

nf-config --version
nf-config --has-nc4

Compilation of the WAVEWATCH III with PDLIB for Domain Decompstion option for (Explicit/Implicit) triangular unstructed grids requires the environment variable METIS PATH be set to the path where Metis and ParMetis are compiled using the same compiler used for WW3.

Two additional remarks need to be made regarding parallel versions of the model (OpenMP and MPI versions). First, complications may occur when preparing executables for running in an MPI environment. Such complications are discussed in Appendix C. Secondly, the OpenMP code should be compiled using directives only, i.e., do not use compiler options that automatically thread the code.

5.7 Compiling and linking

For the first compilation, the WAVEWATCH III environment must be set up using the script w3_setup with the model directory path in argument. Some options are available to define the compiler options and the switch file located in the bin directory. For instance,

w3_setup /home/user/WW3/model -c <comp> -s <switch>

the <comp> keyword can be mpt, intel, gfortran, pgi for optimized compilation options or could be mpt_debug, intel_debug, gfortran_debug, pgi_debug for debugging compilation options. If system-dependant options are needed, it can be done by modifying the script cmplr.env. Some old comp/link templates from different clusters are still available but not recommended. The <switch> keyword can be the suffix of a provided switch file or your own one. Running this script will create these three scripts/files :

comp	Compiler script. This script is based on comp.tmpl with the provided definition of the compiler and its options.
link	Linker script. This script is based onlink.tmpl with the provided definition of the linker and its options.
switch	File containing a list of switches as recognized by the preprocessor w3adc. Copied from switch_<switch>.

The environment file wwatch3.env will be created or updated if it already exists. The auxiliary FORTRAN programs for code prepocessor will be compiled using by default the GNU FORTRAN compiler which can be different to the provided compiler for the WAVEWATCH III programs.

The easiest way to compile WAVEWATCH III is using the script w3_automake to automatically detect which programs to compile and to compile it. It will force pre- and post-processing programs to be compiled as sequential implementation and others depending on the switches from openMP, MPI or hybrid configurations. If the netCDF library is correctly set up, the netCDF dedicated programs will be also compiled. The same test is done for SCRIPNC, PDLIB, OASIS, ESMF, TRKNC and TIDE keywords to manage the program compilation in the best way. For instance,

w3_automake

or for a few programs

w3_automake ww3_grid ww3_shel ww3_ounf

the compiled programs will all be stored in the exe directory with a copy of the switch, comp and link files used.

In case of troubles during the compilation of a program, the log files will be stored in a temporary directory which will differs between sequential mode (tmp_SEQ) and distributed mode like MPI (tmp_MPI), OMP (tmp_OMP) or hybrid (tmp_HYB). There are usually three log files per program:

ww3_<prog>.l	full program with only the matching lines of codes based on the switches and at the end the compilation command line.
ww3_<prog>.out	warning messages
ww3_<prog>.err	error messages

To remove all user-created files from the WAVEWATCH III framework, the script w3_clean can be used by only cleaning up the model directory

w3_clean -m

or the full ww3 repository

w3_clean -c

5.8 Detailled compilation

Compilation of WAVEWATCH III is performed using the script w3_make in the bin directory (Note that before running w3_make several user interventions are needed as described in the remainder of this section.). If this script is used without parameters, all basic programs of WAVEWATCH III are compiled. Optionally, names of programs to be compiled can be given as part of the compile command. For instance, w3_make ww3_grid ww3_strt will compile the grid preprocessor and the initial conditions program only.

w3_make uses several of the scripts described in the previous section. A graphical representation is given in Fig. 5.1.

• If necessary, the script w3_make uses the scripts make_makefile.sh to generate a makefile. make_makefile.sh generates a list of modules to be linked, based on the program switches in the file switch (see Section 5.9), and checks all needed sources for module dependencies. If switches have been changed since the last call to w3_make, w3_new is used to touch relevant source code or to delete relevant object files.

  touch ➡ linux bash 创建文件用到时 touch，

  很好的解释了switch对于ww3_make的意义

• After the makefile has been completed, the standard UNIX make utility is used to compile and link the programs. Instead of directly using the FORTRAN compiler, the makefile invokes the preprocessor and compile scripts ad3 and comp, and the link script link. The script ad3 uses the extension of the file name to determine the necessary action. Files with extension .ftn are processed by w3adc, files with extension .f or .f90 are send to the script comp directly.

Although a user could try out several of these scripts interactively, he or she generally needs to run w3_make only.

The auxiliary scripts w3_make etc. use the switch, comp and link files from the ./bin directory under the WAVEWATCH III home directory, NOT from the local directory.

After the appropriate changes have been made, or the appropriate example scripts have been copied in, (parts of) WAVEWATCH III can be compiled and linked.

• When the program is compiled for the first time, it is suggested to compile program parts one-by-one to avoid lengthy errors messages, and to set up error capturing in comp.

• A good place to start is compilation of the simple test code ctest. First go to the directory work and make a link to the source code of this routine by typing ln3 ctest. This link is made to facilitate later inclusion of errors to test or set-up error capturing in the script comp. The inner workings of the preprocessor w3adc can be seen by typing the command ad3_test ctest which will show how the actual source code is constructed from ctest.ftn, include files and program switches.

• Next, the compilation of this subroutine can be tested by typing ad3 ctest 1 which invokes both the preprocessor w3adc and the compile script comp. The 1 at the end of this line activates test output. If it is omitted, this command should result in a single line of output, identifying that the routine is being processed.

  If ad3 works as expected, an object file obj/ctest.o is generated. If requested during the initial set up, a source code and listing file (ctest.f and ctest.l) can be found in the scratch directory. The listing file is also retained if compilation errors are detected by comp. At this time, it is prudent to test error capturing in the script comp by adding errors and warnings to ctest.ftn in the work directory. The error capturing is discussed in some detail in the documentation of comp. After comp has been tested, and the errors in ctest.ftn have been removed, the link to the work directory and the file obj/ctest.o can be deleted.

上面这段好难~~

After a single routine has been compiled successfully, the next step is to try to compile and link an entire program.

• The grid preprocessor can be compiled by typing w3_make ww3_grid. If the compilation appears successful, and if the input files have been installed (see above), the grid preprocessor can be tested by typing ww3_grid in the work directory. If the input files have been installed, a link to the input file ww3_grid.inp will be present in the work directory, and the grid preprocessor will run and send its output to the screen. Output files of the grid preprocessor will appear in the work directory. When a program is compiled for the first time, the operating system might not be able to find the executable. If this occurs, try to type rehash or open a new shell to work from. In this way all separate programs can be compiled and tested.
• To clean up all temporarily files (such as listings) and data files of the test runs, type w3_clean. Note that w3_make only checks the switch file for changes.
• If the user changes the compile options in the compile and link scripts comp and link, it is advised to force the recompilation of the entire program. This can be achieved by typing w3_new all or w3_new before invoking w3_make. This might also be useful if the compilation is unsuccessful for no apparent reason.

5.9 Selecting model options

The file switch in the bin directory contains a set of strings identifying model options to be selected. Many options are available. Of several groups of options it is mandatory to select exactly one. These mandatory switches are described in Section 5.9.1. Other switches are optional, and are described in Section 5.9.2. Default model setting are identified in Section 5.9.3. The order in which the switches appear in switch is arbitrary. How these switches are included in the source code files is described in Section 6.2.

5.9.1 Mandatory switches

Of each of the below groups of switches exactly one has to be selected.

The first group of switches controls the selection of machine-dependent code. With the introduction of FORTRAN-90 this set of switches should have become obsolete. Problems with some compilers have prompted the retention of the second switch.

F90	FORTRAN-90 style date and time capturing and program abort.
DUM	Dummy to be used if WAVEWATCH III is to be installed on previously untried hardware.

Hardware model (first group) and message passing protocol (second group). Note that these two groups share a switch. This implies that the mpi switch can only be used in combination with the dist switch.

SHRD	Shared memory model.
DIST	Distributed memory model.

SHRD	Shared memory model, no message passing.
MPI	Message Passing Interface (MPI).

Selection of propagation schemes and GSE alleviation method. These represent two sets of switches with some shared switches between the groups. Note that the second set of switches is secondary to the selection of program modules in the first set of switches, and therefore, does not have a user-defined option.

PR0	No propagation scheme / GSE alleviation used.
PR1	First order propagation scheme, no GSE alleviation
PR2	Higher-order schemes with Booij and Holthuijsen (1987) dispersion correction.
PR3	Higher-order schemes with Tolman (2002a) averaging technique.
PRX	Experimental (user supplied).

PR0	No propagation scheme used.
PR1	First-order propagation scheme.
UNO	Second-order (UNO) propagation scheme.
UQ	Third-order (UQ) propagation scheme.

Selection of flux computation:

FLX0	No routine used; flux computation included in source terms,
FLX1	Friction velocity according to Eq (2.56).
FLX2	Friction velocity from Tolman and Chalikov input.
FLX3	Idem, with cap of Eq (2.78) or (2.79).
FLX4	Friction velocity according to Eq (2.138).
FLXX	Experimental (user supplied).

Selection of linear input:

LN0	No linear input.
SEED	Spectral seeding of Eq (3.70).
LN1	Cavaleri and Malanotte-Rizzoli with filter.
LNX	Experimental (user supplied).

Selection of input and dissipation. stabn switches are optional and additional to corresponding stn switch:

ST0	No input and dissipation used.
ST1	WAM3 source term package.
ST2	Tolman and Chalikov (1996) source term package. See also the optional stab2 switch.
STAB0	No stability correction. Compatible with any source term (st) package. Including this switch has no effect.
STAB2	Enable stability correction (2.95) - (2.98). Compatible with st2 only.
ST3	WAM4 and variants source term package.
STAB3	Enable stability correction from Abdalla and Bidlot (2002). Compatible with st3 and st4 only.
ST4	Ardhuin et al (2010) source term package.
ST6	BYDRZ source term package.
STX	Experimental (user supplied).

Selection of nonlinear interactions:

NL0	No nonlinear interactions used.
NL1	Discrete interaction approximation (DIA).
NL2	Exact interaction approximation (WRT).
NL3	Generalized Multiple DIA (GMD).
NL4	Two-scale approximation (TSA).
NLX	Experimental (user supplied).

Selection of bottom friction:

BT0	No bottom friction used.
BT1	JONSWAP bottom friction formulation.
BT4	SHOWEX bottom friction formulation.
BT8	Dalrymple and Liu formulation (fluid mud seafloor).
BT9	Ng formulation (fluid mud seafloor).
BTX	Experimental (user supplied).

Selection of term for damping by sea ice:

IC0	No damping by sea ice.
IC1	Simple formulation.
IC2	Liu et al formulation.
IC3	Wang and Shen formulation.
IC4	Frequency-dependent damping by sea ice.

Selection of term for scattering by sea ice:

IS0	No scattering by sea ice.
IS1	Diffusive scattering by sea ice (simple).
IS2	Floe-size dependent scattering and dissipation.

Selection of term for reflection:

REF0	No reflection
REF1	Enables reflection of shorelines and icebergs

Selection depth-induced breaking of :

DB0	No depth-induced breaking used.
DB1	Battjes-Janssen.
DBX	Experimental (user supplied).

Selection of triad interactions:

TR0	No triad interactions used.
TR1	Lumped Triad Interaction (LTA) method.
TRX	Experimental (user supplied).

Selection of bottom scattering:

BS0	No bottom scattering used.
BS1	Magne and Ardhuin.
BSX	Experimental (user supplied).

Selection of supplemental source term:

XX0	No supplemental source term used
XXX	Experimental (user supplied).

Selection of method of wind interpolation (time):

WNT0	No interpolation.
WNT1	Linear interpolation.
WNT2	Approximately quadratic interpolation.

Selection of method of wind interpolation (space):

WNX0	Vector interpolation.
WNX1	Approximately linear speed interpolation.
WNX2	Approximately quadratic speed interpolation.

Selection of method of current interpolation (time):

CRT0	No interpolation.
CRT1	Linear interpolation.
CRT2	Approximately quadratic interpolation.

Selection of method of current interpolation (space):

CRX0	Vector interpolation
CRX1	Approximate linear speed interpolation.
CRX2	Approximate quadratic speed interpolation.

Switch for user supplied GRIB package.

NOGRB	No package included.
NCEP1	NCEP GRIB1 package for IBM SP.
NCEP2	NCEP GRIB2 package for IBM SP.

5.9.2 Optional switches

All switches below activate model behavior if selected, but do not require particular combinations.

The following switches control optional output for WAVEWATCH III programs.

o0	Output of namelists in grid preprocessor.
o1	Output of boundary points in grid preprocessor.
o2	Output of the grid point status map in grid preprocessor.
o2a	Generation of land-sea mask filemask.ww3 in grid preprocessor.
o2b	Output of obstruction map in grid preprocessor.
o2c	Print status map in format as read byww3_grid.
o3	Additional output in loop over fields in field preprocessor.
o4	Print plot of normalized one-dimensional energy spectrum in initial conditions program.
o5	Id. two-dimensional energy spectrum.
o6	Id. spatial distribution of wave heights (not adapted for distributed memory).
o7	Echo input data for homogeneous fields in generic shell. echo是linux的bash语言中的.
o7a	Diagnostic output for output points.
o7b	Idem inww3_multi.
o8	Filter field output for extremely small wave heights in wave model (useful for some propagation tests).
o9	Assign a negative wave height to negative energy in wave model. Used in testing phase of new propagation schemes.
o10	Identify main elements of multi-grid model extensions in standard output.
o11	Additional log output on management algorithm inlog.mww3.
o12	Identify removed boundary points in overlapping grids (center).
o13	Identify removed boundary points in overlapping grids (edge).
o14	Generate log file with buoy databuoy_log.ww3 for output type ITYPE = 0 in ww3_outp.
o15	Generate log file with time stamps of input data filetimes.XXX in ww3_prep.
o16	Generate GrADS output of grid partitioning inww3_gspl.

The following switches enable parallelization of the model using OpenMP directives, also known as ‘threading’. Before model version 5.01, threading and parallelization using the mpi switch could no be used simultaneously. With version 5.01, pure MPI,pure OMP and hybrid MPI-OMP approaches became available. Switches used in version 5.01 and higher are not compatible with switches used in previous model versions.

OMPG	General loop parallelization directives used for both exclusive OpenMP parallelization and hybrid MPI-OpenMP parallelization.
OMPX	Idem, but for directives used only for exclusive OpenMP parallelization.
OMPH	Idem, but for directives used only for hybrid MPI-OpenMP parallelization.
PDLIB	Domain Decomposition for Explicit and Implicit Solver on triangular unstructured grids. (ParMetis is required for this option)

Note that these switches can only be used in certain combinations, as enforced in the model installation scripts (particularly make_makefile.sh. A pure MPI approach requires the DIST and MPI switches. A pure OpenMP approach requires the SHRD, OMPG and OMPX switches, and the hybrid approach requires the DIST, MPI, OMPG,and OMPH switches.

The following switches are associated with the continuously moving grid options. The first switch activates the option, the other two are optional additions.

MGP	Activate propagation correction in Eq (3.45).
MGW	Apply wind correction in moving grid approach.
MGG	Activate GSE alleviation correction in Eq (3.48).

The following compiler dependent switches are available. They may not have been maintained for recent compiler versions.

C90	Compiler directives for Cray C90 (vectorization).
NEC	Compiler directives for NEC SX6/SX8 (vectorization).

Furthermore the following miscellaneous switches are available:

ARC	Arctic grid option for SMC grid. (Not yet fully tested according to author.)
COU	Activates the calculation of variables required for coupling
DSS0	Switch off frequency dispersion in diffusive dispersion correction.
FLD1	Sea-state dependent$\tau$ Reichl et al (2014) (Section 2.5.2).
FLD2	Sea-state dependent$\tau$ Donelan et al (2012) (Section 2.5.3).
IG1	Second-order spectrum and free infragravity waves (Section 2.4.9).
MLIM	Use Miche-style shallow water limiter of Eq (3.71).
MPIBDI	Experimental parallelization of multi-grid model initialization
MPIT	Test output for MPI initializations.
MPRF	Profiling of individual models and nesting inww3_multi.
NC4	Activates the NetCDF-4 API in the NetCDF pre- and post- processing programs.
NCC	NCEP coupler.
NCO	Code modifications for operational implementation at NCO (NCEP Central Operations). Mostly changes unit numbers and file names. Not recommended for general use.
NLS	Activate nonlinear smoother (Section 2.3.6).
NNT	Generate file test_data_nnn.ww3 with spectra and nonlinear interactions for training and testing of NNIA.
OASIS	Initializes OASIS Coupler (App. E.3).
OASACM	OASIS atmospheric model coupling fields(App. E.3).
OASOCM	OASIS oceanic model coupling fields (App. E.3).
OASICM	OASIS sea ice model coupling fields (App. E.3).
REFRX	Enables refraction based on spatial gradients in phase velocity (Section 2.4.3)
REFT	Test output for shoreline reflflection (which is activated with REF1).
RTD	Rotated grid option.
RWND	Correct wind speed for current velocity.
S	Enable subroutine tracing in the main WAVEWATCH III subroutines by activating calls to the subroutine strace.
SCRIP	Enable SCRIP remapping routines (App. D.3)
SCRIPNG	Enable storage of remapping weights in NetCDF files (App. D.3)
SEC1	Enable the use of global time steps less than 1 s, but does not allow output at time steps less than 1 s.
SMC	Activate SMC grid.
T	Enable test output throughout the program(s).
Tn	Id.
TDYN	Dynamic increment of swell age in diffusive dispersion correction (test cases only).
TIDE	Enables tidal analysis: used for pre-processing of input files, run-time tidal prediction in ww3_shel or tidal prediction with ww3_prtide.
TIDET	test output for tidal analysis.
TRKNC	Activates the NetCDF API in the wave system tracking post-processing program. Selecting TRKNC alone will generate NetCDF-3 files. Selecting both TRKNC and NC4 will generate NetCDF-4 files.
UOST	Enable the unresolved obstacles source term.
XW0	Swell diffusion only in ULTIMATE QUICKEST scheme
XW1	Id. wave growth diffusion only.

5.9.3 Default model settings

Up to model version 3.14, the NCEP operational model setup was considered as the default model setup. However, with subsequent versions of WAVEWATCH III, the model has evolved into a modeling framework rather than a single model. With this, WAVEWATCH III is run differently at various centers, and a clear “default” model version can no longer be identified. Nevertheless, in order to be able to concisely identify in publications exactly which model setup is used, “default” configurations of various centers are now provided in the bin directory. These configurations are provided in example switch files and README files, such as switch NCEP_st2 and README.NCEP. Note that these files are provided to simplify referring to model version, but do not imply an endorsement of the specific model configuration; in this context, it should be noted that by nature, model versions at operational centers are in a continuous state of development.

默认配置，真香，论文中，太香了~~

5.10 Modifying the source code

5.11 Running test cases

Up to version 3.14, WAVEWATCH III was provided with a set of simple tests to established assess the proper behavior of the basic functionality of the model. In the early development of the next release of the model, Erick Rogers and Tim Campbell converted these in regression tests that could be run more easily in an automated version. Up to model version 4.06, these modified tests were gathered in the nrltest directory, while keeping the old tests in the test directory. In model version 4.07, the nrltest were adopted as the new test cases for WAVEWATCH III in a new regtests directory, while eventually the remaining real-world test cases in test were moved to the cases directory, while discontinuing the test directory completely. The following regression tests are available in the regtests directory.

ww3_tp1.1	1D propagation around the world along the equator (no land).
ww3_tp1.2	1D propagation, along meridian (no land).
ww3_tp1.3	1D propagation, shoaling test.
ww3_tp1.4	1D propagation, spectral refraction (x).
ww3_tp1.5	1D propagation, spectral refraction (y).
ww3_tp1.6	1D propagation, wave blocking by current.
ww3_tp1.7	1D propagation, IG wave generation.
ww3_tp1.8	1D propagation, wave breaking on a beach.
ww3_tp1.9	1D propagation, Beji and Battjes (1993) barred flume case.
ww3_tp2.1	2D propagation under angle with grid.
ww3_tp2.2	2D propagation over half the globe without land (with directional spread).
ww3_tp2.3	2D propagation, GSE test.
ww3_tp2.4	2D propagation, East Pacific curvilinear grid test.
ww3_tp2.5	2D propagation, Arctic Grid, curvilinear grid test.
ww3_tp2.6	2D propagation, Limon Harbor unstructured grid test.
ww3_tp2.7	Reflection on a 2D unstructured grid.
ww3_tp2.8	Tidal constituents on a 2D regular grid.
ww3_tp2.9	Tests for obstruction grids.
ww3_tp2.10	Tests for SMC grid.
ww3_tp2.11	Tests for rotated grid.
ww3_tp2.12	Test for system tracking.
ww3_tp2.13	Test for propagation under angle with grid (tripole)
ww3_tp2.14	Test for toy-model using OASIS coupler.
ww3_tp2.15	Test for space-time extremes parameters.
ww3_tp2.16	Two-dimensional propagation on SMC grid with ARC option
ww3_tp2.17	Unstructured grid with Card Deck vs Domain Decompostion for Explicit vs Implicit schemes
ww3_tp2.18	Test for two-dimensional SMC propagation with Arctic pole handling
ww3_ts1	Source term test, time limited growth.
ww3_ts2	Source term test, fetch limited growth.
ww3_ts3	Source term test, hurricane with single moving grid.
ww3_ts4	Source term test, unresolved obstacles.
ww3_tic1.1	Wave-ice interaction, 1D test of$S_{ice}$.
ww3_tic1.2	Wave-ice interaction, 1D test of “shoaling” effect.
ww3_tic1.3	Wave-ice interaction, 1D test of refraction effect.
ww3_tic1.4	Wave-ice interaction, 1D test with ice flfloes and ice thickness.
ww3_tic2.1	Wave-ice interaction, 2D test of$S_{ice}$.
ww3_tic2.2	Wave-ice interaction, 2D test with non-uniform ice.
ww3_tic2.3	Wave-ice interaction, 2D test with uniform ice with increasing thickness.
ww3_tbt1.1	Wave-mud interaction, 1D test of$S_{mud}$.
ww3_tbt2.1	Wave-mud interaction, 2D test of$S_{mud}$.
ww3_tpt1.1	Tests for alternative spectral partitioning methods.
ww3_ta1	ww3 uprstrt, update the restart file of homogeneous conditions (1 point model)
mww3_test_01	Test for expanded grid mask with wetting and drying, etc.
mww3_test_02	Two-way nesting test with single inner grid.
mww3_test_03	Overlapping grids and two-way nesting tests (6-grid version with beach in high-resolution grids.)
mww3_test_04	Current or sea-mount test for two-way nesting with stationary swell conditions.
mww3_test_05	Three nested hurricane grids with moving grids test.
mww3_test_06	Tests for irregular grid(s) w/ww3_multi.
mww3_test_07	Tests for unstructured grid(s) w/ww3_multi.
mww3_test_08	Tests with wind and ice input.

mww3_case_01	Atlantic case with five grids focusing on Trondheim.
mww3_case_02	Pacific case with three grids focusing on Alaska.
mww3_case_03	Original multi-grid case used as global model at NCEP.
mww3_data_00	Wind fields and ice data used by all example cases.
mww3_data_xx	Specific data needed for scriptmww3_case_nn.

6 System documentation

6.1 Introduction

In this chapter a brief system documentation is presented. Discussed are the custom preprocessor used by WAVEWATCH III (Section 6.2), the contents of the different source code files (Section 6.3), optimization (Section 6.4), and the internal data storage (Section 6.5). For a more elaborate documentation, reference is made to the source code itself, which is fully documented.

6.2 The preprocessor

The WAVEWATCH III source code files are not ready to use FORTRAN files; mandatory and optional program options still have to be selected, and test output may be activated. （Exceptions are some modules that are not originally part of WAVEWATCH III, like the exact interaction modules. Such modules with the extension .f of .f90 bypass the preprocessor and get copied to the work directory with the .f extension.）

Compile level options are activated using “switches”. The arbitrary switch ’SWT’ is included in the WAVEWATCH III files as comment of the form !/SWT, where the switch name SWT is followed by a space or by a ’/’. If a switch is selected, the preprocessor removes the comment characters, thus activating the corresponding source code line. If ’/’ follows the switch, it is also removed, thus allowing the selective inclusion of hardware-dependent compiler directives etc. The switches are case sensitive, and available switches are presented in Section 5.9. Files which contain the switch C/SWT can be found by typing:

find switch ’!/SWT’

A list of all switches included in the WAVEWATCH III fifiles can be obtained by typing:

all_switches

Pre-processing is performed by the program w3adc. This program is found in the file w3adc.f, which contains a ready to compile FORTRAN source code and a full documentation (Presently still in fifixed-format FORTRAN-77). Various properties of w3adc are set in PARAMETER statements in w3adc.f, i.e., the maximum length of switches, the maximum number of include files, the maximum number of lines in an include file and the line length. w3adc reads its ‘commands’ from standard input. An example input file for w3adc is given in Fig. 6.1. Line-by-line, the input consists of:

• Test indicator and compress indicator.
• File names of the input and output code.
• Switches to be turned on in a single string (see Section 5.9).
• Additional lines with include files can be given, but these are no longer used in the automated compile system.

A test indicator 0 disables test output, and increasing values increase the detail of the test output. A compress indicator 0 leaves the file as is.

A compress indicator 1 results in the removal of all comment lines indicated by ’!’, except for empty switches, i.e., lines starting with ’!/’. A compress indicator 2 results in the subsequent removal of all comments. Comment lines are not allowed in this input file.

The above input for w3adc is read using free format. Therefore quotes are needed around strings. Echo and test output is send to the standard output device. To facilitate the use of the preprocessor, several UNIX scripts are provided with WAVEWATCH III as discussed in Section 5.7. Note that compiler directives are protected from file compression by defining them using a switch.

6.3 Program files

6.4 Optimization

6.5 Internal data storage

6.6 Variables in modules

附录C 为分布式机器进行设置（MPI）

• 分布式机器 distributed machine
• 分布式计算机系统是将多台小型微型机互连组成的一种新型计算机系统。它冲破了传统的集中式单机局面，从分散处理的概念出发来组织计算机系统，具有较高的性能价格比，灵活的系统可扩充性， 良好的实时性、可靠性与容错性等潜在优点，是近几年来计算机科学技术领域中极受重视的新型计算机系统，现已成为迅速发展的一个新方向。

C.1 模型建立

为了使用 MPI在分布式内存机器上运行 WAVEWATCH III，需要满足两个要求。

1. 所有的可执行文件需要被正确地编译。这意味着代码的编译要有适当的 WAVEWATCH III选项（开关 switches），并有适当的编译器选项。
2. 模型的并行版本需要在适当的并行环境中运行。这意味着并行代码要在多处理器机器上运行，在该机器上调用适当的并行环境。这两个问题将在下文中详细讨论。

在 第4节 Wave Model Structure and Data Flow描述的所有 WAVEWATCH III程序中，只有三个程序受益于MPI的并行实现：实际模型运行程序 ww3 shel和 ww3_multi，以及初始条件程序 ww3_strt。

• ww3_strt通常不在运行环境中使用，一般可以在单处理器模式下运行。在多处理器模式下运行 ww3_strt的主要原因是为了减少其内存需求。

• 这三个代码是唯一同时处理所有网格点的所有谱的代码，因此需要比其他所有 WAVEWATCH III程序多得多的内存。并行运行这些程序的一个额外好处（除了 减少运行时间）是，如果增加处理器的数量，这些程序的并行版本对 每个处理器的内存要求更低。

  • 一个 处理器，相当于一台小电脑？

• 考虑到上述情况，对于大多数并行机器上的实现来说，只需要编译带有 MPI选项的主程序 ww3_shel和 ww3_multi就足够了。

所有其他的 WAVEWATCH III程序都是为 单处理器设计的。

• 这些程序不应该在并行环境下运行，因为这将导致输出文件的I/O错误。
• 此外，由于这些代码的设计，它们在并行环境中的运行时间不可能有任何增益。因为所有的程序都共享 子程序，所以必须保证这种编译是正确的，也就是说，子程序和 主程序是用兼容的编译器设置编译的。这意味着并行程序和非并行程序之间共享的 子程序应该为每个应用程序单独进行编译。

编译MPI版本程序的第一步是保证使用适当的编译器和编译器选项。在使用xlf编译器的IBM系统和使用Portland编译器的Linux系统上，可以在WAVEWATCH III发行版中提供的编译和链接脚本示例中找到这方面的例子。