The General Ocean Turbulence model is both a state-of-the-art turbulence library for flows in natural waters and a 1D water column model.

GOTM was initiated by Hans Burchard and Karsten Bolding in 1998 and the first public release was in 1999. BB has always been responsible for maintaining the code – first using CVS and later using git. BB has provided numerous code contributions and has participated very active on the developers and users mailing lists.

The turbulence library of GOTM is used in a number of 3D ocean models - such as

GOTM is used as the primary test bed for Framework for Biogeochemical Models FABM.

GOTM has its own web-site where in-depth information can be found.

Here we will just provide some information on new features BB is doing on the core GOTM code. This does not include utilities described elsewhere on this site - but only changes to the core part of the GOTM source code. This is typically new features that requires a significant knowledge of the entire code base - but also quite some resources in terms of implementation and testing time.

Developments by BB

The table below describes the on-going GOTM developments at BB. As described here it is very difficult to get funding for pure model development. On the other hand - to bring things forward - you can’t wait for funding agencies to be ready.

BB has therefor initiated projects using BB resources - that hopefully someday can be released for general use - but it will require funds.

Feature         Status          Price (Euro)
YAML configuration 50 % - August 2018 funded
Assimilation 50 % - july 2017 75.000,-
Hotstart 100 % - March 2018 funded (15.000,-)

Jorn - shall we consider a html table here



Until now GOTM has been configured through a combination of namelists (in a number of files) and text files (scalar time-series and profiles). Namelists - being a standard Fortran feature - has clear advantages and replacing them with a costum configuration system must be carefully evaluated. The main disadvantage of namelists is - they are Fortran only - i.e. any manipulation of the namelists must be done either in an editor or through costum made tools (like editscenario). New use cases of GOTM - e.g. auto-calibration - requires a flexible easy maintainable system for generating ensembles of configurations in a non-interactive way. FABM and the output manager in GOTM already uses YAML as configuration format so replacing namelists with a YAML-formatted configuration file seems the obvious choice.

Implementation details

The implementation depends on the Fortran YAML library developed by Jorn Bruggeman and briefly described here.

To ease the transition from namelist based configuration to YAML-based a method for converting namelists to a YAML-file has been implemented via command line options as seen in the figure below.

The default - calling GOTM executable without any options - will read gotm.yaml. Skipping reading gotm.yaml can be achieved by specifying –no_read_yaml_file. Reading an existing - working - namelist configuration can be done be specifying –read_nml_files. Saving the final configuration to a new YAML-formatted file can be done by specifying –save_yaml where file is the name of the target YAML file.

To create a starting point for a new configuration with default parameter settings the following command can be used: gotm –save_yaml default.yaml.

To convert an existing namelist based configuration use this command: gotm –read_nml_files –save_yaml gotm.yaml

Present status

The code is presently in a private BB development Gitlab repository. When feature complete the code will be moved to a public branch of the main GOTM Github repository.

Presently output.yaml has not been merged with gotm.yaml - if it will depends on some further workflow experiences.


Nothing yet



Even though GOTM simulations typically executes quite fast there are use cases where dividing the simulation in parts do make sense. One example is when doing i a coupled physical/bio-geochemical simulation. It is desirable to have the i physical fields in balance before bio-geochemistry is switched on. A second example i is when doing ensemble data-assimilation studies. Here starting the simulation i from a analyzed state is mandatory.

Implementation details

The hotstart feature in GOTM is implemented on top if the field_manager utilising the possibility to add attributes to variables. For state variables – and other variables necessary to perform a hotstart – an extra attribute state is added during registration in the field_manager. The output_manager utilizes the state attribute information when creating a list of fields that must be either written to - or read from - the hotstart file. The link to the data in the NetCDF formatted hotstart file is done through the name variable in the field_manager. Having no hard-coded link between variables names in the model code and data in the hotstart file make a very flexible and extendable scheme. Bio-geochemical models not even implemented in FABM will work seamlessly during hotstart.

The use of the hotstart facility is controlled through two variables in the gotm_run.nml namelist. A boolean – hotstart_offline – and a variable to hold the name of the file with the hotstart data – hotstart_file. If hotstart_offline is true the time information in the time namelist must match the time information contained in hotstart_file.

Present status

The implementation is finished. The correctness of implementation has been tested in the following way:

  • A full simulation is done and the hotstart file is saved.
  • A new simulation is made identical to the original one – but including a hotstart time sometime during the simulation period. The hotstart file from the final part of the simulation is saved.
  • The two saved hotstart files are compared using the md5sum algorithm. If the sums are identical so are the hotstart files – and so are the simulations.

Below is shown the result from the Northern North Sea (nns_annual) standard test case. A hot-start has been injected at july 1st in the simulation year.