3 Running POP

Once the executable pop (standard LANL) or ocn (CCSM) is built, POP requires some input data to run correctly. The first requirement is a file called pop_in that contains many namelists that determine options and parameter values for the run. For standard LANL POP, a sample input file is created in the run directory, and can also be found in the input_templates directory. In the CCSM POP release, a collection of resolution-dependent pop_in files resides in the input_templates directory. For many of the namelist variables in the CCSM pop_in files, a string of upper case letters appears instead of an actual value. During the CCSM build procedure, the ocean setup script selects the appropriate resolution- dependent pop_in file, then replaces the upper-case strings via the Unix sed command. The values of the string-replacements are set in the ocean setup script from CCSM environment variables and from user-selected values.

The full range of namelist options is described below. In addition (except for the simple benchmark test-problem configuration), files will be required to initialize grids, fields for output and possibly other options.  These will be discussed in more detail below and in later chapters.

The namelists and the model features that they control are presented below.  Each namelist appears in a table whose columns contain:

• The name of the namelist, followed by the names of all parameters.
• The range (discrete or continuous) of possible values of the parameter. Square brackets surround the [default value] that is set in the POP code.
  Note that the namelist parameter value set in the pop_in file overrides the default value set in the code.
  A separate line lists the default value set by the CCSM pop_in, in cases where it differs from the value set in the POP code. If the parameter value is resolution-dependent, then the CCSM values are identified by the CCSM resolution name, gx3 or gx1v3 ( see CCSM grid description below); otherwise, the CCSM default value is simply identified by the notation (CCSM).
• The units, if applicable, and a description of the parameter.

Return to Contents

Return to beginning of Chapter 3

3.1 Operational control

3.1.1 Input/Output

Both standard LANL POP and CCSM POP have the capability to perform parallel input/output in order to speed up IO when writing large files, although the CCSM POP netCDF option requires that output files be written serially. Because most files read or written by POP utilize direct-access IO with a horizontal slice written to each binary record, the parallel IO routines allow several processors to write individual records to the same file. The user can specify how many processors to participate in the parallel IO with some restrictions. The number of processors obviously cannot exceed the total number of processors assigned to the job. In addition, it is not productive to assign more processors than the number of vertical levels as these processors will generally remain idle (or even perform unnecessary work). Lastly, there may be some restrictions based on the particular architecture.  Some architectures have a limit on the number of effective IO units that can be open simultaneously.  Some architectures (e.g. loose clusters of workstations) may not have a file system accessible to all of the participating processors, in which case the user must set the number of IO processors to one.

As mentioned above, POP utilizes mostly binary I/O in Fortran direct-access binary files. As a result, the record length must be specified when opening the file and the record length is governed by three module parameters (recl_int, recl_real, recl_dbl). A horizontal slice of the arrays are written in each record, so the record length is the global horizontal grid size multiplied by the appropriate recl_* parameter. For many architectures which use the IEEE standard (SGI, Sun, IBM), the record length is in bytes and these three parameters are set to 4,4, and 8, respectively. However, if you are running POP on a machine in which the record length is not in bytes (e.g. some compilers want record length in 4-byte words) or on a machine in which integers and reals are not 4-byte words (e.g. Cray PVP machines), you may have to edit the file io.F in the appropriate subdirectory (mpi,serial,shmem) to change these parameters to the appropriate values.

The POP model writes a variety of information, including model configuration and many diagnostics, to standard output. Typically standard output would be redirected to a log file using a Unix redirect '>' operator. However, in some cases this is not possible, so a namelist flag lredirect_stdout can be turned on to redirect standard output to a log file. The logfile generated by standard LANL POP code will have the name log_filename.date.time where the date and time are the actual wallclock time and not the model simulation time. In CCSM POP, the option lredirect_stdout is enabled, and the ocean setup script replaces the pop_in string OUTPUTL/LOG_FILENAME with values of the CCSM ocean setup script variables $OUTPUTL and $LOG_FILENAME. The CCSM default values for these variables cause the output file to appear in the ocean-model execution directory with the file name "ocn.log.yymmdd-hhmmss".

During production runs, it is not convenient to have to change the pop_in file for every run. Typically, the only changes necessary are the names of any restart input files. To avoid having to change these filenames in the pop_in file for every run, an option luse_pointer_files exists. If this flag is .true., the pathnames of restart files are recorded in pointer files with the name pointer_filename.suffix, where suffix is currently either restart or tavg to handle restart files and time-averaged history restart files. When a simulation is started from restart, it will read these pointer files to determine the location and name of the actual restart files.

On SGI Origin 2000 and Cray T3E computers, a more efficient library called PSF was developed to perform parallel IO. An interface to this library is provided in the mpi subdirectory in a file called io_psf.Fortran. To use this interface, the user must copy this file to io.F and be sure to link with the psf library (-lpsf).

The CCSM ocean setup script replaces following strings in the CCSM pop_in files:

• OUTPUTL is replaced by the ocean-execution directory name, $EXEDIR (by default, for the ocean model, this name is 'ocn')
• LOG_FILENAME is replaced by ocn.log.date-time, where date is in the format yymmdd and time is in the format hhmmss
• OUTPUT/pop_pointer is replaced by $SCRIPTS/rpointer.ocn

Return to Contents

Return to beginning of Chapter 3

3.1.2 Time management

The time_manager_nml namelist controls the timestep; the length of the current run; the method used to suppress the leapfrog computational mode; and the date on which this run-sequence began.  A run-sequence consists of one or more job submissions, each of which produces a restart file that is used to begin the next job in the sequence.  A run-sequence is identified by a runid that is declared in the first job of the sequence and held fixed throughout the sequence; runid is used in generating default names for the model's output files.  Similarly, the parameters iyear0...,isecond0, are set in the first job and held fixed throughout the sequence. An additional variable called date_separator can be used to govern the form of the date that is appended to various output files. In standard LANL POP, the date_separator is a single character used to separate yyyy, mm, and dd in a date format. A blank character translates to no separator (yyyymmdd); a value of '-' results in the format yyyy-mm-dd.

All CCSM POP output filenames conform to the CCSM output filenaming conventions; hence the date_separator value is meaningless (not used) in CCSM POP.

The CCSM ocean setup script replaces following strings in the CCSM pop_in files:

• RUNID is replaced by the CCSM casename, $CASE
• TIME_MIX_FREQ and DT_COUNT are replaced by values appropriate for the selected resolution
• INPUT is replaced by 'input'
• IYEAR0, IMONTH0, IDAY0 are determined from the CCSM date variable, $BASEDATE
• IHOUR0, IMINUTE0, ISECOND0 are all set to zero

The timestep is defined using a combination of dt_option, dt_count, and time_mix_opt. If time_mix_opt is either 'matsuno' or 'avg', then the timestep is determine as follows: If 'steps_per_(day,year)' is chosen, the timestep is simply (seconds per(day,year))/dt_count. If 'hours' or 'seconds' is chosen, the timestep is dt_count in hours or seconds (note that dt_count need not be an integer). If 'auto_dt' is chosen, the timestep is automatically computed based on the total number of zonal grid points; here, the scaling is such that a uniform 2^o-zonal resolution results in a 1-hour timestep.

If 'avg' is selected for time_mix_opt, then a timestep one-half the usual size is taken every time_mix_freq steps. This may result in a non-integral number of steps per day and irregular day boundaries. If an integral number of steps per day is required, two alternative options are provided. Choosing 'avgbb' will force a second half step to be taken immediately following the first, the equivalent of progressing in time one full time step, but with increased diffusion. Selection of the 'avgfit' option will cause the code to compute the size of a timestep so that the end of a specified interval occurs exactly at the end of a timestep. The time interval to be fit into is governed by the 'fit_freq' parameter which sets the number of time intervals per day (1=once per day) into which the number of full and half time steps must fit exactly.

The timestep size can be increased for tracers in the deep ocean. If such acceleration is requested (laccel = .true.), a profile of the acceleration with depth must be read from the file accel_file, an ascii file with a single column of numbers giving the acceleration factor for each vertical level. Another form of acceleration is to take a longer tracer timestep than momentum timestep. This can be specified by changing dtuxcel to factor smaller than 1.0.

Return to Contents

Return to beginning of Chapter 3

3.2 Grid and bottom-topography definition

POP can be configured to use a variety of grids, because it is written to allow any logically rectangular, orthogonal coordinate system on a sphere.  Generation of such a grid can be time consuming, but it only needs to be done once for a given run-sequence (or even for a set of run-sequences based on the same grid). Consequently, grids and topography are usually generated off-line and grid information is stored in files that are read in during initialization of each job. 

However, options exist to generate both horizontal and vertical grids internally. Because any grid size can be easily produced and IO is unnecessary, this option is used for the benchmark test-problem described in Appendix 7.3. The horizontal grid in this case is a simple lat/lon grid.  The vertical grid uses an algorithm identical to the off-line vertical grid generator; vertical grids are generated which have relatively shallow surface layers and increasing thickness with depth. Topography can also be generated internally, but this option currently only creates an idealized continental outline with a flat bottom; it should not be used for serious ocean simulations

Three options are available for the surface layer: rigid lid ('rigid'); the original free surface formulation ('oldfree'), where the thickness remains constant, but changes in the free surface are used in forcing terms; and a new variable thickness surface layer ('varthick'), where the thickness of the surface layer adjusts to fresh water input/export if natural freshwater boundary conditions are used.

Note that in the 'varthick' formulation, assumptions remain that both the sea-surface height and changes in thickness should be much smaller than the thickness of the surface layer itself. Both because of these assumptions and because the present implementation has some known inconsistencies with respect to the salt/ freshwater input when ice forms and melts, respectively, the CCSM POP enables the 'varthick' suboption, lfw_as_salt_flx, which treats the freshwater flux as a virtual salt flux. Thus, although the thickness of the first layer changes, the horizonal-mean thickness change (or SSH) remains unchanged, i.e., the global mean sea level cannot change.

For some forcing options and in marginal-sea balancing (and in future versions, for regional diagnostics), a region mask is necessary to identify various ocean regions. This mask is a simple two-dimensional integer mask that assigns a region number for each horizontal grid point. Negative values of the region number are used to indicate marginal seas. If such a region mask is not necessary, region_mask_filename must be set to 'unknown_region_mask'.

Two region mask files are required for CCSM POP: the region-mask data file, region_mask_filename, defined above, and a companion region-information file, region_info_filename, which defines region names, identifies active ocean regions and marginal seas, and contains information for marginal-seas balancing. Resolution-dependent versions of the region-information files reside in the CCSM POP directory input_templates. The region-mask data files are much larger, and are bundled with the CCSM2.0 data tar file.

Each record of the region-information file contains the following information, in order:

• region number -- a signed integer in the set {+/-1, +/-2, ...}; a positive value indicates the region is an active-ocean region, whereas a negative value indicates that the region is a marginal sea
• region name -- a character string up to 80 characters long describing the region, e.g., 'Pacific Ocean'
• for marginal seas, the latitude of the center of an associated active-ocean region used for marginal-seas balancing; for active-ocean regions, this value is 0.0
• for marginal seas, the longitude of the center of an associated active-ocean region used for marginal-seas balancing; for active-ocean regions, this value is 0.0
• for marginal seas, the area in square centimeters of an associated active-ocean region used for marginal-seas balancing; for active-ocean regions, this value is 0.0

The CCSM ocean setup script replaces the string INPUT with 'input'.

The procedures for generating the various types of grids and the associated bottom topography, using off-line codes, are presented in detail in Appendix 7.2.  The types of grids that can be generated off-line at present are

• Almost-global Mercator grids
• Global displaced-pole grids
• Regional grids

The horizontal grid in POP is assumed cyclic in both directions. If cyclic conditions are not suitable (e.g. regional models or pole points), land points should be used to prevent flow through the boundary. At present, POP does not support in-flow/out-flow boundary conditions for regional grids, only buffer zones whose thermohaline properties are maintained by restoring to climatology are allowed (see section 3.8.3.3).

Return to Contents

Return to beginning of Chapter 3

3.3 Initializing the model state

3.3.1 Temperature and salinity distribution

Note: The CCSM POP temperature and salinity initialization options differ from those in the standard LANL release of POP 1.4.3, because the CCSM POP must conform to the CCSM2.0 RUNTYPE requirements. Therefore, the discussion below of init_ts_options is divided into two sections, the first for the standard LANL version, the second for the CCSM.

3.3.1.1 LANL POP init_ts_options

Most jobs are continuations of a run-sequence, so the potential temperature and salinity (and other necessary variables) are read in from a restart file (see below). In this case, the init_ts_opt should be set to 'restart', and the runid and model starting times are specified automatically when the information in the restart header file is read.

Because of a conflict with the definitions of the 'branch' option between the standard LANL POP 1.4.3 and the CCSM POP codes, the discussion from the LANL document describing this option has been deleted here. The original LANL POP 'branch' code has also been deleted from the CCSM POP release; the CCSM POP code supports only the CCSM definition of the 'branch' option (descibed below).

To begin a run from scratch, any of the other three options can be used. The 'file' option reads a file containing the 3-d fields for potential temperature and salinity (using direct-access binary format as in the restart file) and uses those fields for the initial condition. The 'mean' option reads a mean profile from an ascii input file with potential temperature and salinity given in two columns as a function of depth. This mean state will be spread across the horizontal domain to create horizontally-uniform 3-d fields. The final option is 'internal' and generates a mean vertical profile by interpolating from the 1992 Levitus mean ocean profile. As in the 'mean' option, this vertical profile is then spread across the horizontal domain to create the full 3-d fields.

3.3.1.2 CCSM POP init_ts_options

The CCSM ocean setup script automatically sets init_ts_opt in the pop_in file to the appropriate value, based upon the CCSM environment variable $RUNTYPE. Because the CCSM POP conforms to the CCSM2.0 RUNTYPE requirements, the code also recognizes, in addition to the LANL POP options listed above, the following four init_ts_opt options: 'startup', 'continue', 'branch', and 'hybrid'.

The CCSM POP option 'startup' is identical in meaning to the LANL option 'file' described above, and 'continue' is identical to 'restart', but 'branch' has a somewhat different meaning than that in the standard LANL release. In CCSM, a 'branch' run initializes the model with datasets from a previous case, but allows for only the case name and input parameters to change. A 'hybrid' run is the same as a 'branch' run, except that the model starting times associated with the input data files are overridden with a new starting date and time.

Note that with either the 'branch' or 'hybrid' options, even if all input is identical to the original run, the model would not restart exactly, because the very first model timestep of the new run is an Euler forward step.

See the CCSM2.0 User's Guide "5.1.3 Changing the RUNTYPE" for a further description of the various RUNTYPE options.

The CCSM ocean setup script replaces following strings in the CCSM pop_in files:

• 'INIT_TS_OPTION' is replaced with the appropriate string, 'startup', 'continue', 'branch', or 'hybrid', as directed by the CCSM master run script.
• 'INPUT' is replaced by 'input'

Return to Contents

Return to beginning of Chapter 3

3.3.2 Restart control

As a POP calculation proceeds, restart files are produced at intervals of simulated time specified by the parameter restart_freq in namelist restart_nml. Restart files contain only the minimum information required to restart the model exactly, so that the results are the same after a restart as would have been the case had no restart been done. This means that two time-levels (n-1 and n) of the prognostic variables must be saved in 64-bit precision.

The restart filenames generated by the CCSM POP code conform to the CCSM2.0 output file naming requirements, and thus they are different from those generated by standard LANL POP 1.4.3. Therefore, the following discussion of restart filenames is split into two sections, the first describing the standard LANL conventions, the second the CCSM.

3.3.2.1 LANL POP restart filenames

The root of the restart filename is given by the restart_outfile variable. The actual full filename will be restart_outfile.runid.suffix where suffix is a number that depends on restart_freq_opt. If this option is 'nyear', 'nmonth' or 'nday' suffix will be the calendar day in yyyymmdd. If the option is 'nstep', suffix will be the current step number. In the unlikely case that the user chooses 'nhour' or 'nsecond', suffix will be yyyymmdd.{hh,sssss} where hh and sssss denote the current hour or seconds in the current day. A common convention (see Chapter 4) is to give restart files the simple root name 'd'. In addition to these named restart files, additional restart files may be written using the even/odd convention. If leven_odd is set to .true., the model will write restart files every even_odd_freq steps. These files will be named restart_outfile.runid.{even,odd} where the code alternately writes to an even or odd file. Any previous file of the same name will be overwritten. This capability is particularly useful for backup in case the simulation terminates prematurely; it provides restart capability without needing to keep many named restart files present in the file system. The model writes alternately to each of two such files so that if an error occurs while writing one restart file, the other restart file will still be all right.

3.3.2.2 CCSM POP restart filenames

The restart output files generated by the CCSM POP code conform to the CCSM2.0 output file naming conventions, which, in the case of the restart files, means the following: first, a directory named 'rest' is created in the ocean execution directory. Then, when the CCSM flux coupler signals that a restart history file is required (or when the ocean code determines internally that a restart file is necessary via the standard POP mechanism described above), two restart output files are created, one containing the restart data in binary format and the other an ascii-format companion file containing the namelist restart_hdr_nml. These two files are named:

• rest/$CASE.pop.r.yyyy-mm-dd-sssss.hdr
• rest/$CASE.pop.r.yyyy-mm-dd-sssss

The leven_odd_on option has not been tested in the CCSM POP code.

The CCSM ocean setup script replaces the string 'OUTPUTR' in the CCSM pop_in file with $EXEDIR/rest/$CASE.pop.r

Return to Contents

Return to beginning of Chapter 3

3.4 Computational options

3.4.1 Barotropic-mode solver

The two-dimensional elliptic equation for the surface pressure is solved implicitly, by any of three methods, all iterative. Convergence of the iterative solvers is governed by the two parameters solv_convrg and solv_max_iters as shown in the table below. The convergence criterion solv_convrg should be chosen small enough such that the pressure balance (printed as part of the model global diagnostics) agrees to 3-4 digits. The parameter solv_max_iters must be chosen large enough to allow the solver to converge (typically a few hundred), but small enough so that the code will terminate in a reasonable time if the solver is unable to converge.

Occasionally, when benchmarking the code, it is useful to hardwire the number of iterations to give a consistent iteration count between runs. In this case, solv_convrg can be set to exactly zero and the solver will iterate solv_max_iters and continue with the simulation without terminating.  Needless to say, this feature should only be used for benchmarking and not for actual ocean simulations.

The solv_ncheck provides a means to improve performance by checking for convergence every solv_ncheck iterations. A preconditioner may be supplied to improve convergence.  It must be computed off-line using a supplied code (in the tools directory) and supplied in a file named precond_file as nine stencil weights for the nine-point operator. The Jacobi method converges very slowly; it is not recommended but is provided as an alternative.

Return to Contents

Return to beginning of Chapter 3

3.4.2 Advection methods

Currently, advection of momentum is always done by centered finite differences in space. For tracer advection, two options are available. The first is the standard centered advection; the second is 3rd-order upwinding which, although not monotone, will improve monotonicity at a somewhat increased computational cost.

Return to Contents

Return to beginning of Chapter 3

3.4.3 Pressure-averaging of horizontal pressure gradient

This technique was explained in the Introduction. Because it can potentially increase the allowable timestep size, it should always be enabled.  The option to turn it off is provided only to permit comparisons with and without pressure-averaging or between POP and other codes that do not incorporate this technique.

Return to Contents

Return to beginning of Chapter 3

3.5 Vertical mixing parameterizations

Several vertical mixing parameterizations are available within the POP model.  The value of vmix_choice determines whether a simple constant mixing, a Richardson-number dependent mixing or the KPP mixing parameterization is used.  Additional mixing parameters for each of these schemes are set in individual namelists shown below; only the namelist associated with the mixing choice is actually read.

The const and rich parameterizations both generate mixing coefficients small enough to permit the vertical mixing equations to be solved explicitly, so the –Dimpvmix option is not needed at compile-time.  However, this limitation to relatively small mixing coefficients also implies that neither of these is capable of dealing with convectively unstable water columns, so convective adjustment (convection_type='adjustment' in convection_nml) must be used in conjunction with const and rich.

KPP mixing (Large et al. 1994), on the other hand, can generate large coefficients, particularly within the boundary layer and in convective regions. Therefore, the vertical mixing equations must be solved implicitly. Thus, when KPP is being used, the -Dimpvmix option must be invoked at compile-time and convective adjustment should be turned off. KPP mixing is the standard CCSM vertical mixing scheme, so by default, the CCSM POP build procedure enables the -Dimpvmix option.

If implicit vertical mixing was chosen at compile time, the parameter aidif governs the time-centering of the implicit scheme. The bottom_drag coefficient is used to compute bottom drag.

The CCSM POP has the option of using a non-zero, spatially and temporally uniform bottom heat flux, bottom_heat_flx, below a specified depth, bottom_heat_flx_depth. This is a very crude, preliminary attempt in approximating the ocean-bottom geothermal heating. This heat flux is applied only at top surfaces of the bottom grid boxes, including the ocean bottom, i.e., zero-flux boundary conditions still exist at cell sides.

Return to Contents

Return to beginning of Chapter 3

3.5.1 Constant coefficients

Return to Contents

Return to beginning of Chapter 3

3.5.2 Richardson-number mixing

The Pacanowski and Philander (1981) mixing scheme was developed primarily for use in tropical ocean and, although it can be used elsewhere in the global ocean, the user should be aware of the possible need to adjust its parameters (Peters et al. 1988; Gent 1991).

Return to Contents

Return to beginning of Chapter 3

3.5.3 Convective adjustment

Convective adjustment must be used in conjunction with the const and rich options, unless implicit vertical mixing has been enabled.

If you specify 'adjustment', then the code will make nconvad passes through the convective adjustment of tracers.  This option may only be used if implicit vertical mixing is off.  If the convection type is specified as 'diffusion', the code will treat convectively unstable regions using the diffusion coefficients convect_diff for tracers and convect_visc for momentum. Implicit vertical mixing must be used for the 'diffusion' option. If vmix_type is chosen to be 'constant', then convect_visc can be set to zero and no convective diffusion of momentum will occur.  Note that this is not true for either rich mixing or KPP and convect_visc must be set properly for these cases.

Return to Contents

Return to beginning of Chapter 3

3.5.4 KPP mixing

If kpp is to be used, implicit vertical mixing must be turned on at compile-time as described in a previous chapter. If kpp is enabled, convection_type (above) is redundant, but it should be set to 'diffusion' so that the model will not stop with an error condition. The KPP parameterization is relatively complex and only the parameters that are routinely changed are shown here (and included in the namelist). It is possible to change other parameters by editing the KPP module, but this should not be necessary and is discouraged.

A recent change to the KPP implementation allows a depth-dependent background diffusivity and viscosity. The form of this dependence is vdc = vdc1 + vdc2*atan((-z-dpth)*(1/L)), where z is the model vertical coordinate, positive upwards; the viscosity is simply vvc = Prandtl*vdc. If a constant diffusivity and viscosity are required, simply set vdc2 to zero.

Return to Contents

Return to beginning of Chapter 3

3.6 Horizontal mixing parameterizations

The del2 (Laplacian) and del4 (bi-harmonic) mixing options are ad hoc parameterizations, particularly for tracers. These level-oriented parameterizations mix water-mass properties across sloping isopycnic surfaces. The Gent-McWilliams (1990) parameterization remedies this shortcoming by forcing the mixing to take place along isopycnic surfaces. An anisotropic viscosity parameterization is also available. This option assigns different values of viscosity parallel and perpendicular to a given direction, where the direction can be specified as described in a later section.

The coefficients ah and am have default values that are only valid for del2 and a specific grid size. The user will have to determine the appropriate values for their particular grid size and choice of parameterization. The auto_hmix option attempts to compute coefficients based on known values for other resolutions. The result may or may not be suitable. The variable_hmix option modifies the coefficients ah and am based on functions of the grid cell areas and will reduce the values for smaller grid cells (am and ah thus represent the values at the largest grid cells). In the future, several options for the functional form of this scaling will be available.

The values of ah and am in the table are appropriate for del2 only.  For del4 the units of ah and am are (cm⁴/s) and values are negative and are of the order of (1-10)E+14 in magnitude.  As in the del2 case, ah and am must be scaled appropriately for different grid resolutions.

Return to Contents

Return to beginning of Chapter 3

3.6.1 Gent-McWilliams isopycnal mixing parameterization

Gent-McWilliams (gent) mixing operates only on tracer species (potential temperature, salinity, and other tracers). No bi-harmonic form of gent has been implemented yet. For vertical dependence of the mixing, a profile with the form kappa_depth_1 + kappa_depth_2*exp(-z/kappa_depth_scale) can be chosen; for a constant kappa, the first parameter should be set to 1 and the second to 0. Horizontally varying mixing coefficients, due to Visbeck et at. (1995), can be activated by setting kappa_choice = 'variable'. Two diffusivities can be specified for the Redi and bolus parts of the GM parameterization if not using the Visbeck (1995) formulation; ah (from the horizontal mix namelist) is used for the Redi part, ah_bolus is used for the bolus part. Two different maximum slopes can also be specified to allow different taperings of the Redi and bolus terms. A backgroud horizontal diffusivity ah_bkg can be used for bottom cells.

The CCSM POP has an additional option, gm_bolus, to compute the bolus velocity components explicitly, which is used in the advective terms. If gm_bolus is true, the skew-flux form of the mixing tensor is not used. Using unequal values or different maximum slopes for the Redi and bolus parts or setting gm_bolus = .true. increases the computational cost.

Return to Contents

Return to beginning of Chapter 3

3.6.2 Anisotropic viscosity options

The anisotropic viscosity routine computes the viscous terms in the momentum equation as the divergence of a stress tensor , which is linearly related to the rate-of-strain tensor with viscous coefficents visc_para and visc_perp . These coefficients represent energy dissipation in directions parallel and perpendicular to a specified alignment direction which breaks the isotropy of the dissipation. There are three options for choosing the alignment direction: 1) along the local instantaneous flow direction, 2) along the east direction, and 3) along the coordinate directions (note: the viscous operator is invariant under a rotation of the alignment direction by 90 degrees, so for example, choosing the alignment direction as north, south, east or west are all equivalent.). A functional approach is used to derived the discrete operator, which ensures positive-definite energy dissipation, provided visc_para > visc_perp.

The viscosities may optionally (lsmag_aniso = .true.) be evaluated with Smagorinsky-like non-linear dependence on the deformation rate, which is proportional to the norm of the strain tensor. With the Smagorinski option, the viscosities are evalutated as

visc_para -> max[c_para|D|ds**2),u_para*ds] visc_perp -> max[c_perp|D|ds**2),u_perp*ds]

where ds = min(dx,dy), and the |D| is the deformation rate: |D| = sqrt(2)|E| (where |E| is the norm of the strain tensor), c_para and c_perp are dimensionless coefficients of order 1, and u_para and u_perp are velocities associated with the grid Reynolds number which determine minimum background viscosities in regions where the nonlinear viscosities are too small to control grid-point noise. Typically u_para and u_perp are order 1 cm/s. If lvariable_hmix_aniso is true and Smagorinsky is not turned on, the non-linear viscosities are automatically limited to be no greater than 1/2 the maximum valued allowed by the viscous CFL limit. Note that the tapering will differ for the two components so the ratio will not remain constant. In the future, an option for reading in a spatially-dependent field will be added.

The CCSM ocean setup script replaces the string OUTPUTHv with $EXEDIR/hist/$CASE.pop.hv in the CCSM pop_in files

Return to Contents

Return to beginning of Chapter 3

3.7 Physical process options

3.7.1 Equation of state approximation

Three options for computing the density from salinity and potential temperature are available in the standard LANL POP. The first is a UNESCO equation of state (eos) based on potential temperature from Jackett and McDougall (1995). The second is a polynomial fit to the full UNESCO equation of state. The advantage of the polynomial form is that it is faster; the disadvantage is that the polynomial is only valid over a specified temperature and salinity range and exceeding that range will have unpredictable results. This is a particular issue with the KPP vertical mixing scheme which often computes buoyancy by displacing water near the surface to deep water where the EOS range has been restricted. The last option is a linear eos which is supplied for use only in special situations where such an approximation is appropriate.

In addition to the three standard LANL eos options, a fourth option for the equation of state is available in the CCSM POP: the faster and more accurate alternative to the UNESCO eos of McDougall, Wright, Jackett and Feistel (2002 submission to JTECH).

For the polynomial option, there are two methods for determining the polynomial coefficients and these are determined by the value of state_file. If this variable is defined as 'internal', the code will determine the polynomial coefficients internally based on the vertical grid.  The internal routines currently use hard-wired profiles for the limits of validity of the polynomial eos; if the user wishes to change these limits, they can be changed in an off-line coefficient generator (in the tools/eos directory) and the coefficients can be read in from a file. The value of state_file will be the name of the coefficient input file. Future versions of this module should allow run-time changes in the way the coefficients are computed, but these two options are adequate for all cases.  As mentioned above, the polynomial eos has a certain temperature and salinity range over which the polynomial is valid.  The state_range_opt variable determines what to do if these limits are exceeded during a simulation. The first option is to simply 'ignore' when these occur; this is generally not as bad as it sounds as the range is valid for nearly all normal cases.  The second option is to 'check' whether the range is exceeded and print a warning if such problems are detected.  The last option, 'enforce', simply makes sure the polynomial is evaluated within the correct range without changing the values of T or S. For example, if the temperature drops below -2^oC, the code will compute a density based on a temperature of -2^oC without actually changing the temperature. The state_range_freq can be used to perform the checks infrequently to save computational time.

Return to Contents

Return to beginning of Chapter 3

3.7.2 Baroclinic-mode parameters

The reset_to_freezing option exists to make sure the surface temperature does not drop below freezing, a situation that can occur with some types of forcing in stand-alone mode. This option is not used (or is ignored) if sea ice formation is enabled (see next section).

Return to Contents

Return to beginning of Chapter 3

3.7.3 Sea-ice emulation parameters

If ice_freq_opt is not set to the value 'never', the code will create ice whenever the ocean temperature drops below freezing at levels at or above kmxice. In the coupled CCSM POP, this ice formation is computed at the coupling timestep and at the timestep immediately prior to the coupling timestep. The determination of the ice timestep in the CCSM coupled model is completely independent of the parameters selected in the ice_nml.

The ice is assumed to have a salinity given by sea_ice_salinity, which is a namelist parameter in the standard LANL POP version, but is set to the CCSM2.0 "shared constants" value in CCSM POP. In coupled mode, the heat flux associated with ice formation is saved and sent to the flux coupler for use in the ice model to determine the amount of ice formation. For a discussion of lactive_ice, see Section 3.9.1.

Return to Contents

Return to beginning of Chapter 3

3.7.4 Topographic stress

If ltopostress is .true., then an implementation of Holloway's topographic stress parameterization (see Eby and Holloway, JPO 24, 1994, p2577-2588) is enabled. In effect, this changes the field acted on by the del2 operator from (U,V) to (U-U*,V-V*) where (U*,V*) are derived based on the topography gradient and a specified length scale.

Return to Contents

Return to beginning of Chapter 3

3.8 Forcing options (ocean-only mode)

Presently, POP includes routines for specifying the surface forcing for the velocity, pressure, temperature, and salinity as well as interior forcing for temperature, and salinity. While it is impossible to anticipate every kind of forcing a user might want, the routines have been constructed so that it should be relatively easy to add new types of forcing by using existing types as a template. In the following sections, these abbreviations apply:

• ws => wind stress; surface forcing for the horizontal velocity field.
• shf => surface heat flux; surface forcing for the potential temperature equation.
• sfwf => surface fresh water flux; surface forcing for the salinity equation.
• ap => surface pressure forcing due to variations in the atmospheric pressure.
• pt_interior => interior forcing for the potential temperature equation.
• s_interior => interior forcing for the salinity equation.

Each forcing category listed above has a namelist, and a set of options must be specified in each namelist.  The options are:

• periodicity
• temporal interpolation method and interval
• formulation
• files containing forcing data
• units of forcing variables
• updating the forcing values

Return to Contents

Return to beginning of Chapter 3

3.8.1 Periodicity of forcing data

First, the user must decide on the periodicity (or 'type') of the data that will force the model, for example, an annual mean climatology or a re-analysis product available every day.  This choice is specified by the namelist variables {ws, shf, sfwf, ap, pt_interior, s_interior}_data_type and the options are:

• 'none' => no forcing.
• 'analytic' => a time-invariant analytic form for the forcing.
• 'annual' => a time-invariant annual mean forcing.
• 'monthly-equal' => a monthly mean climatology assumed to consist of 12 values that are separated equally in time by 365/12 = 30.4166 days.  This was included mostly for backward compatibility.
• 'monthly-calendar' => a monthly mean climatology whose 12 values correspond to the non-leap-year calendar.
• 'monthly' => synonymous with  'monthly-calendar'.
• 'n-hour' => forcing is specified every 'n' equally spaced hours.  If this is chosen, the user must also specify a value for {ws,shf,sfwf,ap,pt_interior,s_interior}_data_inc which is the increment (in hours) between consecutive values of the forcing data, for example, ws_data_inc=24. for daily wind stress forcing. The value of *_data_inc is disregarded for all of the other *_data_type options.

Return to Contents

Return to beginning of Chapter 3

3.8.2 Temporal interpolation of forcing data

Next, the user must decide how to temporally interpolate the forcing data to the appropriate point in time for the model to use. If the data type of the forcing is either 'none', 'analytic', or 'annual', then the interpolation options are disregarded since the forcing is invariant in time.  The type of interpolation is specified by the value of {ws, shf, sfwf, ap, pt_interior, s_interior}_interp_type and the options are:

• 'nearest' => use the forcing from the time that is closest to the current model time.
• 'linear' => use a linear interpolation to the current model time using the two nearest forcing times.
• '4point' => use a 3rd order polynomial fit using the 4 nearest forcing times and evaluate it at the current model time.

How often interpolation is done is specified using the namelist variables {ws, shf, sfwf, ap, pt_interior, s_interior}_interp_freq and the options are:

• 'never' => never perform any temporal interpolation.
• 'n-hour' => perform temporal interpolation every 'n' hours. If this is chosen, the user must also specify a value for {ws,shf,sfwf,ap,pt_interior,s_interior}_interp_inc which is the increment (in hours) between interpolation calculations. Note that it is assumed that this value is less than or equal to the data increment.
• 'every-timestep' => perform temporal interpolation every timestep.

Return to Contents

Return to beginning of Chapter 3

3.8.3 Forcing formulation

For those model forcing terms that typically depend explicitly on the model state (shf, sfwf, pt_interior, s_interior) there are various ways of formulating the forcing which can be specified using the *_formulation namelist variables for each case.

Return to Contents

Return to beginning of Chapter 3

3.8.3.1 shf_formulation options:

• 'restoring' => a simple restoring of the top layer potential temperature in the model to a data value, dPT/dt = (PT(data) - PT(model))/tau, where tau is a constant time scale. PT(data)represents a space- and possibly time-dependent array of values of sea-surface temperature (SST) and is the only necessary forcing field.  If this option is chosen, then a value for the space- and time-independent restoring time-scale variable shf_restore_tau (in days) also needs to be specified.
• 'Barnier-restoring' => use the ECMWF heat flux analysis of Barnier et al. (1995) arranged in restoring form.  Necessary forcing fields consist of (in order) an effective SST, spatially varying restoring time scale, sea ice mask, and net downward short-wave radiation.  If this option is chosen, then it is also necessary to specify the namelist variable jerlov_water_type to calculate the depth of short-wave penetration.
• 'bulk-NCEP' => calculate fluxes based on atmospheric state variables and radiation similarly to the NCAR flux coupler. (The details of this type of forcing are given in Large et al. (1997) and NCAR Oceanography Section (1996), and are not repeated here.) Necessary forcing fields consist of (in order) SST, air temperature, air humidity, downward short-wave radiation, cloud fraction, and wind speed. If this option is chosen, then it is also necessary to specify the namelist variable jerlov_water_type to calculate the depth of short-wave penetration. This option also expects the name of a file used to define different regions of the ocean (including marginal seas) specified by the namelist variable region_mask_filename in the grid namelist to identify the marginal-seas regions. In this formulation, the ice-covered regions are determined based upon Shea et al. (1990) SST climatology. The strengths of open-ocean (i.e. no ice cover), under-ice, and marginal-sea restoring coefficients are given by the shf_weak_restore, shf_strong_restore, and shf_strong_restore_ms namelist variables, respectively, in the forcing_shf_nml.

Return to Contents

Return to beginning of Chapter 3

3.8.3.2 sfwf_formulation options:

• 'restoring' => a simple restoring of the top layer salinity in the model to a data value, dS/dt = (S(data) - S(model))/tau, where tau is a constant time scale. S(data) represents a space- and possibly time-dependent array of values of sea-surface salinity (SSS) and is the only necessary forcing field. If this option is chosen, then a value for the space- and time-independent restoring time-scale variable sfwf_restore_tau (in days) also needs to be specified.
• 'bulk-NCEP' => calculate fluxes based on atmospheric state variables similarly to the NCAR flux coupler. (The details of this type of forcing are given in Large et al. (1997) and NCAR Oceanography Section (1996), and are not repeated here.) Necessary forcing fields consist of (in order) SSS and precipitation. If this option is chosen, it is necessary to also choose 'bulk-NCEP' for shf_formulation since the evaporation rate (part of the sfwf_formulation) must be proportional to the latent heat flux (part of the shf_formulation). The ice-covered regions are determined based on Shea et al. (1990) SST climatology. The strengths of open-ocean (i.e. no ice cover), under-ice, and marginal sea-restoring coefficients are given by the sfwf_weak_restore, sfwf_strong_restore, and sfwf_strong_restore_ms namelist variables, respectively, in the forcing_sfwf_nml. In this formulation, note that the weak-restoring term is applied only in ice-free regions. Also, if ladjust_precip = .true., yearly precipitation adjustments are made.

Note that runoff is not used in these ocean-only forcing formulations.

Return to Contents

Return to beginning of Chapter 3

3.8.3.3 {pt,s}_interior_formulation options:

• 'restoring' => a simple restoring of the {potential temperature(PT),salinity(S)} below the top level in the model to a data value, d{PT,S}/dt = ({PT,S}(data) - {PT,S}(model))/tau, where tau is a constant time scale. Values of the {PT,S} in the entire volume of the ocean ({PT,S}(data)) are the only necessary forcing fields. If this option is chosen, then a value for the restoring time scale namelist variable {pt,s}_interior_restore_tau (in days) also needs to be specified. In addition, a value for the namelist variable which specifies the maximum level for which interior restoring is performed ({pt,s}_interior_restore_max_level) is necessary. For example, if s_interior_restore_tau=365 and s_interior_restore_max_level=17, then salinity will be restored to data with a time scale of 1 year for model levels 2 through 17 everywhere in the ocean.

Having interior restoring occur everywhere in the ocean as described above is more relevant to data-assimilation than to prognostic simulations, so there is support for variable interior restoring specified by {pt,s}_variable_interior_restore = .true..  If this option is selected, the user must supply a file ({pt,s}_interior_restore_filename) that contains the maximum model depth for which interior restoring is performed and the inverse restoring timescale (1/days) for each horizontal grid point.  This option can be useful for creating graduated 'buffer zones' at the boundaries of non-global models or to set water mass properties due to outflow from unresolved marginal seas.  For example, the maximum level for restoring can be set to zero everywhere except for north of 75N where it takes on a nonzero (though not necessarily constant from point to point) value to help create Arctic water masses.  To reduce the direct influence of the buffer zone, the inverse restoring time-scale can be tapered from zero at 75N to a finite value at the northern edge of the grid. Note that the code expects both fields to be double precision, but converts the maximum depth-level field to integer internally using the 'nint' (nearest integer) function.

Return to Contents

Return to beginning of Chapter 3

3.8.4 Forcing files

If any of the options for {ws,shf,sfwf,ap,pt_interior,s_interior}_data_type except for 'none' or 'analytic' are chosen, then the user must supply files that contain the appropriate data via the variables {ws,shf,sfwf,ap,pt_interior,s_interior}_filename. All data files are assumed to be double-precision, direct-access files with each record having the dimensions of the full horizontal grid.  The data is also assumed to be in a specific order that varies depending on the forcing formulation to be used.  For 'annual' and 'n-hour' forcing, one occurrence of each forcing field should be in the file; for 'monthly-calendar' or 'monthly-equal' forcing, all 12 months of each field should be in the file. For example, if the heat flux is 'monthly-calendar' 'Barnier-restoring', and the horizontal grid is 172x128, then the forcing file should have data in the following order:

• 1. effective_temperature(1:172,1:128,1:12)
• 2. time_scale(1:172,1:128,1:12)
• 3. ice_mask(1:172,1:128,1:12)
• 4. net_shortwave(1:172,1:128,1:12).

If the forcing is 'n-hour' then there needs to be a different file for each forcing time in the sequence. The files are assumed to be labeled by the date of the middle of the forcing period; and are of the form 'root.yyyy.ddd.hh' where 'root' is specified using *_filename, yyyy is the year (0000-9999), ddd is the day (001-366), and hh is the hour (01-24). Note that the dating convention is relative to year 0000, so results may not be what the user expects. For example, with wind stress forcing every 2 days (ws_data_inc = 48.), even number years will expect files dated on even days of the year, and odd days for odd numbered years (in the absence of leap years). Thus, the expected sequence of files at the end of year 1492 is (with ws_filename = 'ws'): ... ws.1492.362.00, ws.1492.364.00, ws.1493.001.00, ws.1493.003.00 ... because ws.1492.364.00 refers to forcing covering days 363 and 364 of year 1492, while ws.1493.001.00 refers to forcing covering day 365 of year 1492 and day 1 of year 1493.  Makes perfect sense, doesn't it?  It is possible to change the labeling date from the middle of the forcing interval to the beginning by changing a flag in the source code.

Return to Contents

Return to beginning of Chapter 3

3.8.5 Forcing units

The code makes assumptions about the units of the fields read in from the forcing files as follows:

• potential temperature (degrees C)
• salinity (g/g)
• wind stress (dyne/cm²)
• restoring time scale (days)
• heat flux (W/m²)
• precipitation (kg/m²/s)
• air temperature (K)
• humidity (kg/kg)
• wind speed (m/s)
• cloud fraction, ice_mask (dimensionless, varying from 0 to 1).

Any input data that isn't in the correct units can be multiplied by a renormalization factor specified by a component in the namelist variable vector {ws, shf, sfwf, ap, pt_interior, s_interior}_data_renorm.  The components of this vector match up with the order of the fields in the forcing file.  For example, salinity data sets are often in msu, while the model expects msu*0.001, so the user can specify sfwf_data_renorm(1) = 0.001 in the namelist if sfwf_formulation = 'restoring' or 'bulk-NCEP'.

Return to Contents

Return to beginning of Chapter 3

3.8.6 Updating the forcing values

Forcing values are updated based on the value of *_interp_inc and whether the value of the forcing term depends explicitly on the ocean state, as detailed below.

• Wind stress (ws) and atmospheric pressure (ap) forcing don't depend explicitly on the ocean state so the forcing terms in the equations are updated depending on the value of {ws,ap}_interp_freq. For example, with ws_data_type = 'monthly-calendar', ws_interp_type = 'linear', and ws_interp_freq = 24., the code will linearly interpolate monthly wind stress values at the beginning of each day and will use this interpolated value for one model day.
• Potential temperature (shf and pt_interior) and salinity (sfwf and s_interior) forcing typically do explicitly depend on the ocean state (for example, restoring to climatology depends on the difference between the climatological value and the current model value) so the forcing terms in the equations are evaluated every timestep. However, just like with the wind stress and atmospheric pressure, the value of the data used in calculating the forcing terms depends on the value of *_interp_freq. For example, with pt_interior_data_type = 'monthly-calendar', pt_interior_interp_type = 'linear', pt_interior_interp_freq = 48., and pt_interior_formulation = 'restoring', the code will linearly interpolate monthly potential temperature values at the beginning of each 2-day interval and will use this interpolated value for two model days when calculating the forcing.  Again, the actual forcing term is evaluated every timestep, but the value that is being restored to stays constant over the 2 day period.

Return to Contents

Return to beginning of Chapter 3

3.8.7 Forcing modules

The files forcing_{ws,shf,sfwf,ap,pt_interior,s_interior}.F are the modules that initialize and calculate the forcing terms. forcing.F is the driver module and forcing_tools.F contains routines shared by all of the individual forcing modules.

Return to Contents

Return to beginning of Chapter 3

3.8.8 Forcing namelists

3.8.8.1 Windstress

Note: because the CCSM default value for ws_data_type is 'none', CCSM defaults for ws_data_type-related namelist parameters are irrelevent and are not listed here.

Return to Contents

Return to beginning of Chapter 3

3.8.8.2 Surface heat flux

Note: because the CCSM default value for shf_data_type is 'none', CCSM defaults for shf_data_type-related namelist parameters are irrelevent and are not listed here.

^* Presently, these are only available in CCSM POP; in the future, they may be available from LANL. See Section 3.9.1 for details.

Return to Contents

Return to beginning of Chapter 3

3.8.8.3 Surface fresh water flux

Note: because the CCSM default value for sfwf_data_type is 'none', CCSM defaults for sfwf_data_type-related namelist parameters are irrelevent and are not listed here.

^* Presently, these are only available in CCSM POP; in the future, they may be available from LANL

Return to Contents

Return to beginning of Chapter 3

3.8.8.4 Atmospheric pressure

Note: because the CCSM default value for ap_data_type is 'none', CCSM defaults for ap_data_type-related namelist parameters are irrelevent and are not listed here.

Return to Contents

Return to beginning of Chapter 3

3.8.8.5 Potential temperature – interior

Note: because the CCSM default value for pt_data_type is 'none', CCSM defaults for pt_data_type-related namelist parameters are irrelevent and are not listed here.

Return to Contents

Return to beginning of Chapter 3

3.8.8.6 Salinity -- interior

Note: because the CCSM default value for s_data_type is 'none', CCSM defaults for s_data_type-related namelist parameters are irrelevent and are not listed here.

Return to Contents

Return to beginning of Chapter 3

3.9 Forcing options (coupled mode)

The POP code is used in coupled mode in a variety of research settings. In addition to the CCSM, POP is the ocean component of the Parallel Climate Model (PCM) developed at NCAR by a team led by Warren Washington, and two other coupled models are adopting POP and CICE for their ocean and sea ice components: the Colorado State University Coupled Model and a coupled model to be developed at UCLA.   Of these, only PCM was available at the time that original LANL POP manual was being written. CCSM and PCM run on SGI Origin 2000 and IBM SP systems, and PCM also runs on a Cray T3E system.

To run the POP code in any of the coupled modes, the coupling interface must be activated at compile-time by specifying -Dcoupled in the makefile (see section 2.2.4).  This option is enabled by default in the CCSM build procedure (see section 2.1.1). 

When -Dcoupled is enabled, the coupled_nml namelist becomes available.

In a fully coupled integration, i.e. all components are active, {ws,shf,sfwf}_data_type (in forcing_ws_nml, forcing_shf_nml, and forcing_sfwf_nml, respectively) must be set to 'none', so that the model will not require any surface data sets, no unnecessary time interpolations will be done, and, most importantly, the surface fluxes will not be modified internally.

When the coupled option is enabled, the river runoff freshwater fluxes are readily received from a land model via the coupler. There are no options to override this behavior.

A CCSM option that becomes available when coupled is lms_balance of forcing_sfwf_nml. If .true., then POP balances evaporation, precipitation, runoff, and ice formation freshwater fluxes over each marginal sea region individually. Any excess/deficit is transported to/from designated active ocean regions for each marginal sea. These regions are determined by CCSM POP based on the information available in region_info_filename of grid_nml.

Return to Contents

Return to beginning of Chapter 3

3.9.1 Partially-coupled option (CCSM POP only)

The CCSM POP provides a second coupled option activated by setting both {shf,sfwf}_formulation = 'partially-coupled'. The option represents an improvement over the internal bulk-NCEP formulation, while retaining most of bulk-NCEP's important features. In particular, partially-coupled is designed to integrate ocean-only or ocean-ice coupled integrations subject to data sets from observations/reanalyses or an atmospheric model. This option eliminates the burden of creating individual forcing data sets for each ocean/ice resolution. Instead, a "data" (a.k.a "dummy") atmospheric model reads standard atmospheric data sets (say at T62 resolution) which are sent to the coupler. The coupler then passes the computed and spatially interpolated fluxes to the ocean model. In a similar fashion, a "data" ice model can be used to read in observed ice fraction data sets to be sent to the ocean model via the coupler. As in a fully-coupled integration, the river runoff fluxes and the lms_balance option are available.

As in bulk-NCEP, if ladjust_precip = .true. in the forcing_sfwf_nml, POP performs precipitation adjustment factor computations, excluding the marginal seas. However, unlike in bulk-NCEP, it does not itself use this factor to adjust the incoming precipitation field. Instead, if lsend_precip_fact = .true. in forcing_sfwf_nml, this factor is sent to the coupler, which then uses it to multiply both the precipitation and runoff fields before sent to the ocean and ice models. If lsend_precip_fact = .false., then even if the precipitation factor adjustment is requested, it is not used. In this case, one has the option of performing either none or instantaneous precipitation, evaporation, and runoff balance within the coupler by appropriately setting flx_epbal namelist variable of the coupler. If lsend_precip_fact = .true., but not partially-coupled, then the coupler receives 1 as the precipitation adjustment factor. The net effect is equivalent to setting flx_epbal='off' in the coupler namelist.

If luse_cpl_ifrac = .true. (forcing_shf_nml), then POP does use the ice fraction information coming from an ice model via the coupler. If this option is .false., the ice fractions are computed internally based on the Shea et al. (1990) SST climatology as in bulk-NCEP. luse_cpl_ifrac is ignored in fully-coupled integrations.

The partially-coupled formulation does allow the ocean model to modify the incoming heat and freshwater fluxes. No modifications of the wind stress fields, however, are allowed. These heat and freshwater flux changes are in the form of additional restoring components activated by non-zero values of the {shf,sfwf}_{weak,strong}_restore_{ms} in forcing_{shf,sfwf}_nml. Note that the marginal sea restoring coefficient is particularly useful here if one chooses to apply no restoring elsewhere. In contrast to bulk-NCEP, the weak restoring of salinity is done everywhere, i.e. including ice covered regions. This term is construced to have zero horizontal mean.

The above restoring coefficients should be chosen judiciously. For example, if lms_balance=.true., then {shf,sfwf}_strong_restore_ms should be set to zero to prevent any additional restoring forcing in marginal sea areas.

By default, under ice covered regions (either internally determined or coming from an ice model), POP uses monthly-mean, diagnosed ice/ocean freshwater fluxes from an active sea-ice/ocean integration. This is an attempt to provide better fluxes in these regions compared to strong restoring. The freshwater fluxes due to any frazil ice formation are not included in these fluxes and therefore, handled separately by ice formation (in POP) and subsequent melt (in an ice model). lactive_ice in ice_nml should be set to .true. to override this feature, thus allowing POP to use whatever is sent from an ice model via the coupler.

The frazil ice formation is the only mechanism to heat below freezing surface temperatures to the freezing point in POP. The associated heat fluxes are much larger than any diagnosed sea-ice/ocean heat flux, thus eliminating the need for such fluxes.

Return to Contents

Return to beginning of Chapter 3

3.10 Input datasets

3.10.1 Input datasets for LANL POP

3.10.2 Input datasets for CCSM POP

Associated with every data file is an informational companion file with an identical root filename, but with the suffix ".readme" instead of the format-describing suffix of the data filename. The format for all ".readme" files is the same, and includes the following information:

1. concise summary of the data-file contents
2. name of the person who created the file
3. date and time the dataset was created
4. name of the computer on which the dataset was created
5. dataset format (see the CCSM POP Naming Conventions document for the meanings of the dataset format codes)
6. "endian-ness" of ieee datasets
7. location of a permanent, archival copy of the dataset
8. descriptions of the methodology used to create the data file
9. optionally, other information may be available, including:
• a description of any other datasets used to create the data file
• a copy of any code or scripts used to create the file, or a reference to an archived version of these codes and/or scripts

For the oldest CCSM POP input datasets, not all of the information listed above is available, but for many of the more recent datasets, the information is available and may be helpful for users who are interested in customizing these input datasets to better suit their own applications.

A handful of small CCSM POP input datasets are not located in the inputdata/ocn/pop/resolution/subdir directory, but rather reside in the models/pop/input_templates directory.

Return to Contents

Return to beginning of Chapter 3

3.11 Trouble-shooting

If you encounter problems getting POP to run, here are some tips about things to check.

Return to Contents

Return to beginning of Chapter 3

3.11.1 Checking the timestep stability criteria

Return to Contents

Return to beginning of Chapter 3

3.11.2 Checking the global energy and work balances

Return to Contents

Return to beginning of Chapter 3

3.11.3 Getting the right combination of vertical mixing options

Return to Contents

Return to beginning of Chapter 3

3.11.4 Getting the right combination of horizontal mixing options

Return to Contents

Return to beginning of Chapter 3

3.11.5 Getting the right combination of forcing options

Return to Contents

Return to beginning of Chapter 3

3.11.6 Properly normalizing input salinity values

The units for salinity in the model are g/g.  Care must be taken to renormalize salinity data, which is often in g/kg.

Return to Contents

Return to beginning of Chapter 3

3.11.7 Real-time X-window display

A rudimentary X-display can be used to monitor the model's behavior as it is running, which can sometimes be useful in locating when and where (on the model grid) things start to go bad. This capability relies on an unsupported, not-necessarily-portable interface to an X library called fix.  There are no guarantees that this will work on your system or that this will be supported in future releases. Currently, the fields to be viewed in the x-window are hard-wired and can only be changed by changing the source code.

Note: The CCSM POP neither uses nor supports X-display.

Return to Contents

Return to beginning of Chapter 3