.. _forcing_options: 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. 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. 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 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-\ *in*\ dependent 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-\ *in*\ dependent 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. 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. 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\ :sup:`2` | +------------------------------+----------------------------------------+ | **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'. 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. 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. 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.