9. 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.

Sometimes an asterisk (*) will be used as a UNIX-like wildcard.

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

Since the options apply to several or all of the forcing categories, the options will be explained first, then the namelists for the categories will be given.

9.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 *_data_type where * denotes each of ws, shf, sfwf,etc. The options for data_type 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 *_data_inc which is the increment (in hours) between consecutive values of the forcing data. For example, ws_data_inc =24 denotes daily wind stress forcing. The value of *_data_inc is disregarded for all of the other *_data_type options.

9.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 *_interp_type and the options are (envelope,please):

  • ‘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 *_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 *_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

9.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.

shf_formulation options:

  • ‘restoring’
    a simple restoring of the top layer potential temperature in the model to a data value, dT/dt = (T:sub:`data` - T:sub:`model`) / τ, where τ is a constant time scale. T:sub:`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 [2] 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 similar to a fully-coupled model (and using bulk flux formulations extracted from the NCAR flux coupler). 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.

sfwf_formulation options:

  • ‘restoring’:
    a simple restoring of the top layer salinity in the model to a data value, dS/dt = (S:sub:`data` - S:sub:`model`) / τ, where τ is a time scale. S:sub:`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 similar to coupled mode (and using bulk flux formulations extracted from the NCAR flux coupler). 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).

pt,s_interior_formulation options:

  • ‘restoring’
    a simple restoring of the potential temperature or salinity below the top level in the model to a data value, d(T,S)/dt = ((T,S):sub:`data` - (T,S):sub:`model`) / τ, where τ is a constant time scale. Values of the potential temperature or salinity in the entire volume of the ocean ((T,S):sub:`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 one 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 to the nearest integer.

9.4. Forcing files

If any of the options for *_data_type are chosen to be anything besides ‘none’ or ‘analytic’, then the user must supply files that contain the appropriate data via the variables *_filename. All data files are currently 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.

9.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/cm2
restoring time scale: days
heat flux: W/m:sup:`2`
precipitation: kg/m:sup:`2`/s
air temperature: degrees K
humidity: kg/kg
wind speed: m/s
cloud fraction: dimensionless, varying from 0 to 1
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 *_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 psu (ppt), while the model expects msu(g/g) = (0.001)psu, so the user can specify sfwf_data_renorm(1) = 0.001 in the namelist if sfwf_formulation = ‘restoring’ or ‘bulk-NCEP’.

9.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 currently do not 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',
``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 and salinity 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.
``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.

9.7. Forcing modules

The files

forcing\_ws.F90
forcing\_shf.F90
forcing\_sfwf.F90
forcing\_ap.F90
forcing\_pt\_interior.F90
forcing\_s\_interior].F90

modules that initialize and calculate the forcing terms. forcing.F90 is the driver module and forcing_tools.F90 contains routines shared by all of the individual forcing modules.

9.8. Forcing namelists

The following namelist groups control the behvaior of the forcing input:

  • The windstress forcing namelist group is forcing_ws_namelist.
  • The surface heat flux forcing namelist group is forcing_shf_nml.
  • The surface fresh water flux forcing namelist group is forcing_sfwf_nml.
  • The atmospheric pressure forcing namelist group is forcing_ap_nml.
  • The interior potential forcing namelist gorup is forcing_pt_interior.nml.
  • The interior salinity forcing namelist gorup is forcing_s_interior.nml.
  • The surface absorption namelist group is sw_absorption_nml. See Chapter 9 of the The Parallel Ocean Program (POP) Reference Manual for details.