Ocean#

Purpose#

Instead of atmospheric turbulent flows, PALM can be used to simulate turbulent flows in the ocean as well. The main area of application is the ocean mixed layer. Other fields of application may be turbulence generated by hydrothermals at the bottom of the ocean. Beside pure ocean flows, PALM also allows to simulate a coupled atmosphere-ocean system.

General Information#

The ocean mode is switched on by adding the namelist &ocean_parameters to the _p3d namelist file. See &ocean_parameters for the complete list of available steering parameters.

Switching on the ocean mode has several effects:

An additional prognostic equation for salinity is solved (can be switched off via salinity = .F.). Zero salinity flux is used as default boundary condition at the sea surface and bottom of the sea.
z=0 (sea surface) is assumed at the model top (vertical grid index k=nzt on the w-grid), with negative values of z indicating the depth.
If switched on, random perturbations are by default imposed to the upper model domain from zu(nzt*2/3) to zu(nzt-3).

Basic Usage / Settings#

A simple setup for an ocean mixed layer including the effect of Langmuir circulation is given in the namelist file oceanml_p3d. Try using this setup for first tests of the ocean module, and then modify it towards your intended application. Attention: This file requires adjustments before using it for a real simulation. The required adjustments are listed as comments in the file.

The following list shows those settings of parameters in the &initialization_parameters which are specific for ocean simulations. Explanations will be given below the list.

    dx = 1.25,
    dy = 1.25,
    dz = 1.25,

    use_top_fluxes     = .T.,
    bc_uv_t            = 'neumann',
    top_momentumflux_u = -0.0001,    ! corresponds to u* = 0.01 m/s
    top_momentumflux_v = 0.0,
    top_heatflux       = 1.02e-4,    ! gives weak cooling at ocean surface

    constant_flux_layer = .F.,
    bc_uv_b             = 'neumann',

    initializing_actions = 'set_constant_profiles',

Since the size of turbulent eddies in the ocean is at least one order of magnitude smaller than in the atmosphere, the grid spacings dx, dy, and dz must be set appropriately and should be in the order of 1m or even less.
Mechanical and thermodynamic forcing is achieved by prescribing the momentum flux and the sensible heat flux at the ocean surface via parameters top_momentumflux_u, top_momentumflux_v, and top_heatflux. It additionally requires to set use_top_fluxes = .T.. Be aware that fluxes are given in kinematic units, i.e. \(\frac{m^2}{s^2}\) and \(K \frac{m}{s}\). Since there is no logarithmic wall layer at the ocean top (it is an almost free-slip surface with zero mean vertical velocity gradient), Neumann conditions should be set for all quantities, e.g. bc_uv_t = 'neumann'.
If the setup shall not include the ocean bottom, the constant flux layer as default bottom boundary conditions must be switched off via constant_flux_layer = .F. and free-slip conditions should be set via bc_uv_b = 'neumann'.
The only available initialization method is initializing_actions = 'set_constant_profiles'. Profiles are constructed starting from the sea surface down to the bottom of the model (e.g. via pt_vertical_gradient and pt_vertical_gradient_level), using surface values given by pt_surface, sa_surface, ug_surface, and vg_surface.

The specific ocean parameter settings in the example file oceanml_p3d are:

&ocean_parameters
    stokes_waveheight          = 1.0      ! results in a turbulent Langmuir
                                          ! number La = 0.45
    stokes_wavelength          = 40.0,    ! results in a turbulent Langmuir
                                          ! number La = 0.45
    wave_breaking              = .F.,     ! The implemented parameterization is
                                          ! designed for a vertical grid spacing
                                          ! of dz = 1.25m and time steps of
                                          ! about 4 s. It will probably fail for
                                          ! other setups.
                                          ! Attention:
                                          ! For Noh et al. switch to .T.
    surface_cooling_spinup_time = 900.0,  ! add a surface cooling only at start
                                          ! in order to initiate turbulence
    salinity                   = .TRUE.,  ! salinity switched on just for
                                          ! testing the salinity code
                                          ! remove this and the following two
                                          ! parameters for simulating the
                                          ! Noh et al. case
    bc_sa_t                    = 'neumann',
    top_salinityflux           = 0.0,     ! zero salinityflux at ocean surface
/ ! end of ocean parameters

Meaning of the single parameters can be found in the &ocean_parameters reference. Parameter surface_cooling_spinup_time is used here to limit the time for which the surface cooling (as set via top_heatflux) is applied. This method can be used to trigger the onset of turbulence at the beginning of a run, in addition to the random disturbances that can be generated via runtime-parameter create_disturbances. Be aware that turbulence generation by wave breaking is switched-off in this setup (note the description of wave_breaking, wherethe grid size and time step restrictions for using this parameter is discussed).

Nested Ocean Runs#

PALM's self-nesting feature can be used for ocean runs as well. The top of the nested domains always match the sea surface. Elevated nests (e.g. to better resolve just the pycnocline) are not allowed. Like for atmospheric runs, self-nesting is activated by adding a &nesting_parameters namelist to the _p3d file. More details about self-nesting are given in the self-nesting guide.

Coupled Atmosphere-Ocean Simulations#

Beside the self-nesting, PALM allows to couple an ocean simulation with an atmosphere simulation via flux coupling at the interface. A coupled atmosphere-ocean run requires to provide two parameter files for steering the atmosphere run and the ocean run separately, e.g.:

.../JOBS/coupled_run/INPUT/coupled_run_p3d
.../JOBS/coupled_run/INPUT/coupled_run_p3d_O

The ocean run parameter file name requires the suffix _O. Parameters for atmosphere/ocean can be chosen independently, but they should form a physically meaningful setup. The only condition that the parameters must meet, is that the setups have an identical horizontal domain size, i.e. (nx+1)* dx and (ny+1)*dy respectively must match in both parameter files. In order to account for the fact that eddies in the ocean are generally smaller and usually have lower velocities than in the atmosphere, it is beneficial to use different grid spacings in both models (i.e., finer grid spacing for the ocean).

The atmosphere parameter file (coupled_run_p3d) must include the additional namelist

&nesting_parameters
   domain_layouts = ’atmos’, 1, -1, 4, 0.0, 0.0, 0.0,
                    ’ocean’, 2,  1, 8, 0.0, 0.0, 0.0, /

Names of the models must be given as 'atmos' and 'ocean'. The fourth column of domain_layouts gives the number of cores to be assigned to the respective atmosphere / ocean model (in this example 4 cores for atmosphere and 8 cores for ocean). The total number of cores given via palmrun option -X must match the sum of both, so this example requires -X 12. The partitioning of cores to the atmosphere and ocean model should allow for a good load balancing. The corner coordinates of the domains given in columns 5-7 must be chosen as 0.0.

The &runtime_parameters namelist parameter dt_coupling defines the time interval at which data is exchanged between atmosphere and ocean surface. It must be explicitly set both in the _p3d and _p3d_O file. The interval must not be smaller than the minimum time step by the atmosphere and the ocean model. In order to ensure synchronous coupling throughout the simulation, dt_coupling should be chosen larger than dt_max.

Boundary Conditions for Atmosphere-Ocean Coupling#

Atmosphere surface boundary conditions for temperature (bc_pt_b) and mixing ratio (bc_q_b) are automatically set to 'dirichlet', because the surface temperature is given by the ocean top temperature, and the mixing ratio is assumed as the saturation mixing ratio at this temperature. For more details about the exchange of boundary data between atmosphere and ocean see the reference section.

Coupled Atmosphere-Ocean Simulations with Spinup#

Since the onset of fully developed turbulence in the ocean usually requires more time than in the atmosphere, it makes sense to run the atmosphere and the ocean model separately until turbulence has been fully developed. It is possible to activate the coupling after this spinup time. The spinup runs are also called precursor runs.

The time interval in which the respective models shall run uncoupled needs to be set by initialization parameter coupling_start_time. Furthermore, end_time = coupling_start_time is required.

After the independent precursor runs are finished, the coupled run can be started, as sketched in Fig. 1. Note that the coupled run is carried out as a restart run that reads the restart data that have been generated by the precursor runs.

atm_ocean_coupling_spinup
Figure 1: Timeline for the independent atmosphere and ocean precursor runs as well as for the coupled run.

Short step-by-step instructions to carry out a coupled run with separate (spinup) precursor runs:

Give the parameter files for steering the atmosphere and ocean spinup runs separately, e.g.:

.../JOBS/atmosphere_spinup/INPUT/atmosphere_spinup_p3d
.../JOBS/ocean_spinup/INPUT/ocean_spinup_p3d

In atmosphere_spinup_p3d set e.g.

end_time = 3600.0
coupling_start_time = 3600.0

In ocean_spinup_p3d set e.g.

end_time = 40000.0
coupling_start_time = 40000.0

Carry out the atmosphere and ocean precursor run separately, and store the restart data:

palmrun ... -r atmosphere_spinup -X 16 -a "d3# restart"
palmrun ... -r ocean_spinup -X 48 -a "d3# restart"

Copy the parameter files and restart data manually to the folder used for the coupled run (name as given by the run-identifier). The ocean data files now require the suffix _O. Note that cp -r is required because restart data may be stored in folders, depending on restart_data_format.

cp    .../JOBS/atmosphere_spinup/INPUT/atmosphere_spinup_p3d &
      .../JOBS/coupled_run/INPUT/coupled_run_p3dr_O
cp    .../JOBS/ocean_spinup/INPUT/ocean_spinup_d3d &
      .../JOBS/coupled_run/INPUT/coupled_run_p3dr_O
cp -r .../JOBS/atmosphere_spinup/RESTART/atmosphere_spinup_d3d.000 &
      .../JOBS/coupled_run/RESTART/coupled_run_d3d.000
cp -r .../JOBS/ocean_spinup/RESTART/ocean_spinup_d3d.000 &
      .../JOBS/coupled_run/RESTART/coupled_run_d3d_O.000

Assuming that the coupled models shall run for 20000 s, in file coupled_run_p3dr set e.g.

end_time = 23600.0

In coupled_run_p3dr_O set

end_time = 60000.0

Add the namelist &nesting_parameters

&nesting_parameters
   domain_layouts = ’atmos’, 1, -1, 16, 0.0, 0.0, 0.0,
                    ’ocean’, 2,  1, 48, 0.0, 0.0, 0.0, /

to file `coupled_run_p3dr`.

Carry out the coupled run:

palmrun ... -r coupled_run -X 64 -a "d3r"

Limitations#

Following limitations apply for the ocean mode:

only cyclic horizontal boundary conditions are allowed (see bc_lr and bc_ns )
the atmosphere-ocean coupling requires topography = 'flat' in the atmosphere model
the atmosphere-ocean coupling does not permit to use self-nesting at the same time, neither for the atmosphere, nor for the ocean model
there is no precipitation effect on salinity in coupled atmosphere-ocean runs
wave effects (e.g. on the roughnes length) are not considered on the atmosphere side in case of coupled runs

The ocean mode can not be used in combination with the following PALM modules or settings:

meso-scale nesting
urban surface model
land surface model
any radiation model
bulk cloud physics or just using humidity
chemistry (except if only passive scalars are used as chemical species)

Reference#

For more detailed scientific and technical information about the ocean mode see the reference section.

Notes, shortcommings and open issues#

The PALM developers are no oceanographers. We developed the ocean mode for colleagues from oceanography within some joint projects. We try to care for bugs that are reported via the trouble-ticket system, but our general support for the ocean module is very limited.

Keys	Action
`?`	Open this help
`n`	Next page
`p`	Previous page
`s`	Search