Skip to content
Alexandra Bozec edited this page Sep 8, 2023 · 9 revisions

Welcome to the HYCOM-src wiki!

The Hybrid Coordinate Ocean Model (HYCOM) source code is now available through the GitHub platform. To have access to the latest version (currently 2.3.01):
git clone --recursive https://github.com/HYCOM/HYCOM-src.git src_2.3.01_mpi

See the What's new in 2.3.01 wiki page for the most significant changes to the code since 2.3.00.


HYCOM Overview

The HYbrid Coordinate Ocean Model (HYCOM) uses conventional Primitive Equation 2nd order finite volume dynamics in the horizontal and solves the layered continuity equation. However, in the vertical it uses the Arbitrary Lagrangian Eulerian (ALE) approach to extend its range of applicability beyond that of a standard layered Ocean General Circulation Model (OGCM).

Traditional vertical coordinate choices [z-level, terrain-following (sigma), isopycnic] are not by themselves optimal everywhere in the ocean. Ideally, an OGCM should (a) retain its water mass characteristics for centuries (a characteristic of isopycnic coordinates), (b) have high vertical resolution in the surface mixed layer (a characteristic of z-level coordinates) for proper representation of thermodynamical and biochemical processes, (c) maintain sufficient vertical resolution in unstratified or weakly-stratified regions of the ocean, and (d) have high vertical resolution in coastal regions (a characteristic of terrain-following coordinates).

The hybrid coordinate used in HYCOM is one that is isopycnal in the open, stratified ocean, but smoothly reverts to a terrain-following coordinate in shallow coastal regions, and to z-level coordinates in the mixed layer and/or unstratified seas. The hybrid coordinate extends the geographic range of applicability of traditional layered or isopycnic coordinate circulation models toward shallow coastal seas and unstratified parts of the world ocean. In HYCOM, each coordinate surface is assigned a target isopycnal. The model continually checks whether or not grid points lie on their reference isopycnals and, if not, tries to move them vertically toward the latter. However, the grid points are not allowed to migrate when this would lead to excessive crowding of coordinate surfaces. Thus, in shallow water, vertical grid points are geometrically constrained to remain at a fixed depth while being allowed to join and follow their reference isopycnals over the adjacent deep ocean.

In the mixed layer, grid points are placed vertically so that a smooth transition of each layer interface from an isopycnic to a constant-depth surface occurs where the interface outcrops into the mixed layer. HYCOM therefore behaves like a conventional sigma model in very shallow and/or unstratified oceanic regions, like a z-level coordinate model in the mixed layer or other unstratified regions, and like an isopycnic-coordinate model in stratified regions. The figure is a three year mean of potential temperature from the surface to 1000m (top) and 1000m to 6000m (bottom) at 180W a 41-layer 1/12º global HYCOM simulation, illustrating isopycnal layers outcropping into fixed depth layers near the surface and at high latitudes. Thin lines are interface locations and the thick black line is the mixed layer depth.

HYCOM_Section


Naming Convention

HYCOM can be hardwired at compile time for a particular region, but it is now more usual to configure it to allocate memory at run time, i.e. as a relo executable. In fact, all the config/ examples are for relo setups. When the RELO macro is set, arrays are allocated at run time and the defaults for the small number of user changeable parameters in mod_dimensions.F90 are usually appropriate. The most commonly edited parameter in mod_dimensions.F90 is mxthrd which might need changing when parallelizing with OpenMP (TYPE=omp or TYPE=ompi), see the OpenMP wiki page. If you want to use static compile-time arrays, dimensions.h will need customizing - see the Defining Domain Dimensions wiki page for more details.

There is still a compile time distinction between global tripole grids (with a special halo exchange on the "north" domain edge), and the equation of state is chosen at compile time to improve performance. If you only have one domain and one equation of state you can call your directory anything you like (e.g. src_2.3.01_mpi). If you have multiple domains, one approach is to compile in the generic RELO and/or RELO_GLB "region" directory and then softlink from the actual region directories:

hycom/RELO/src_2.3.01-7tsig0_mpi
hycom/RELO/src_2.3.01-17tsig2_mpi
hycom/GOMb0.08/src_2.3.01-17tsig2_mpi -> ../RELO/src_2.3.01-17tsig2_mpi

hycom/RELO_GLB/src_2.3.01-17tsig2_mpi
hycom/GLBt0.72/src_2.3.01-17tsig2_mpi -> ../RELO_GLB/src_2.3.01-17tsig2_mpi

The actual region source code directores can skip the "-XtsigY" part of the name if this never changes for that domain.

Then edit and run Make.csh for your setup, see Compilation (Make) wiki page for more details.