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 variableregion_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 thesfwf_formulation
) must be proportional to the latent heat flux (part of theshf_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, ifs_interior_restore_tau=365
ands_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:
- effective_temperature(1:172,1:128,1:12)
- time_scale(1:172,1:128,1:12)
- ice_mask(1:172,1:128,1:12)
- 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.