This is still a draft of the blog-post - kb 2019-07-19.

This message is mainly for those who want to help developing GOTM further. Not everything will work as expected - and we are aware of issues with the present code. Even so the code is released and we hope for feedback in order to proceed and reletive soon have a full release of GOTM v5.4.

As the sum of the changes are rather big it is necessary with a more thorough test than what is normally the case. The changes falls in 3 catagories each described in sub-sections below.

CMake configuration re-write and sub-modules use

A description of the changes have already been given here

The main take home message is that GOTM now comes with external dependencies already included as part of the git clone .. command. This implies that there is no need to explicitly define FABM_BASE as part of the CMake configuration step.

New run-time configuration - YAML

For some of the use cases we have experienced over the last few years the Fortran namelist files have become a limiting factor. Without going into to much detail the main problem was related to automatic generation of namelist files when GOTM was used in sensitivity and auto-calibration work.

The YAML format is not completely new on GOTM context as the relative new output manager uses a YAML configuration file. Also FABM uses YAML format for run-time configuration. One of the objectives of the YAML specification was to create a human readable format - so understanding the content of the configuration file is as easy - if not easier - than the namelist files. All configurations are now contained in one single file. As the YAML file can be generated by GOTM itself it is possible to actively use the meta data used internally by the field-manager in GOTM. This has been used to make annotations in the YAML file.

We have - for now - kept compatibility with namelists i.e. it is still possible to run GOTM using namelist configuration files. To do this users must add –read_nml when executing GOTM. We strongly urge people to shift to the YAML-based configuration file. To ease the transition we provide support for an automatic conversion from namelists to YAML. A strong argument for converting is that new features in GOTM is not guarenteed work with namelists - there was a reason why we wanted to shift away.

The default behaviour of GOTM is to read from gotm.yaml but it is now possible to override the default behaviour by specifying an alternative YAML file on the command line as gotm test-gotm.yaml in which case the configuration will be read from test-yaml.gotm instead. This is usefull in an ensemble context where 100’s or 1000’s of simulations are to be done and the configuration can be in e.g. gotm.yaml.0000, gotm.yaml.0001, ….

A few examples on command line use:

gotm

will run gotm using gotm.yaml as configuration file.

gotm gotm_test.yaml

will run gotm but using gotm_test.yaml as configuration file.

gotm --write_yaml gotm_default.yaml

will generate an annotated gotm_default.yaml and exit. The annotations are generated based on the metadata in the GOTM Fortran it self. It is important that no gotm.yaml exists as it will used to start a normal simulation.

gotm --write_yaml gotm_nml.yaml --read_nml

will generate gotm_nml.yaml and exit. Configuration will be read from existing namelist-files and used. This is a method to transfer a namelist based configuration to a YAML-based configuration.

gotm --write_schema gotm.schema

will write a XML-formatted file. This option might later be used with e.g. editscenario.

gotm  --output_id _01

will change output file names from e.g. nns_annual.nc to nns_annual_01.nc. So it is possible to store different test runs in different output files without the need to manually change output.yaml.

New features

The major new feature in this release is the YAML-based runtime configuration.

In addition preliminary support for ice is provided in this release. The ice-models are from an external project and does not share any code with the previous attempts to include ice in GOTM (and GETM). Work will be continued on further developing and refining the ice models - but using the concepts of sub-modules this work can be done withput interfering with the core GOTM source code. The idea is to have an API that will allow for a number of different ice-models where one will be selected at run-time. The presence of ice will have an impact on fluxes of heat and momentum accross the air-sea interface. Depending on the complexity of the ice-model different output will be available - but as a minimum always the ice thickness.