this is the second newsletter within a week. We promise however to reduce
this frequency drastically in the future.
The reason for this newsletter is to announce the release of GOTM v.
2.0.0, which is written in FORTRAN90 and contains a number of new features.
These will be discussed in detail below. There are now two versions maintained
in parallel for a while. Version 1.2.x is written in FORTRAN77 and has
been developed for inclusion into 3D models written in F77. That version
may fade out after a while, depending on the needs of our users. The new
version 2.0.0 is strictly modular and therefore also suitable for inclusion
in 3D models. We would therefore like to encourage all users to switch
to the new version as soon as possible.
The new code of version 2.0.0 can be downloaded from the main web page
in two versions as explained below, with and without NetCDF support.
All (old and new) test cases can be downloaded by clicking on the ‘!
Run test cases !’ prompt on the left panel of the web site. When
arriving on that page, you have to decide whether to download old (GOTM
v.1.#.#) or new test cases (GOTM v.2.#.#).
All existing scenarios (test cases) have been adapted to v. 2.0.0 such
that there are now two versions for some of the test cases, which however
differ in format only. A number of new, mainly simple idealistic test cases
have been added in order to demonstrate various features of GOTM:
Channel: Steady-state channel flow driven by surface slope.
Couette: Steady-state channel flow driven by surface stress.
Convection: convective deepening driven by negative surface heat
Estuary: Estuarine circulation driven by external and internal pressure
Rouse: Simulation of the Rouse suspended matter profile in a channel
Seagrass: Simulation of seagrass dynamics under long swell waves.
Compared to v. 1.2.x this new version has the following new physical
Internal pressure gradient: Horizontal gradients of temperature and
salinity may be specified as simple constant values in time and space or
read from a file allowing for variation in time and space. GOTM,
then calculates the internal pressure gradient by using the equation of
state. The user may choose whether or not using the temperature and salinity
gradients for horizontal advection of T and S as well. As a test case for
internal pressure gradients and horizontal advection, Estuary is used for
demonstration of this feature.
Linearised equation of state: The user may now choose between four options
for the equation of state, (i) full UNESCO equation with thermobaric effect,
(ii) full UNESCO equation without thermobaric effect, (iii), a linear approximation
to the UNESCO equation of state with user defined T0, S0 and p0, (iv) a
linear equation of state with user defined rho0, T0, S0, and expansion
coefficients for T and S.
Variable relaxation of T and S: Relaxation to temperature and salinity
may now be given in three user defined parts of the water column with different
relaxation times, upper part, middle part and lower part. This allows for
example for Dirichlet boundary conditions for T and S, which to our opinion
are not that elegant, but sometime inevitable when forcing data are missing
or e.g. bottom salinity has to be restored in order to avoid model
Seagrass dynamics: This is a more exotic feature motivated by the work
of Verduin and Backhaus . Seagrass is reproduced by Lagrangian tracers
which advect with the flow. Lateral excursion limits are set. When those
are reached friction is exerted on the flow. Friction coefficients and
excursion limits which depend on the physiology of the plant, have to be
written in from a file. The user has to specify, how much of the energy
loss from the mean flow will be transferred to turbulence. With this model,
we could reproduce the two-dimensional modelling results by Verduin and
Backhaus . This work has been initialised during a visit of Jennifer
Verduin at JRC Ispra.
Other new features are related to the structure and the output:
As mentioned in the beginning of this mail - version 2.0.0 of GOTM is
written in Fortran90. There are 2 main reasons for the change from F77
to F90 - firstly F90 contains a feature called 'modules' and secondly F90
allows for dynamic memory allocation. We will shortly discuss why these
two features are important. In F77 the usual way to share variables between
various subroutines is via common-blocks. These common-blocks are usually
store in 'include files' which are included in the subroutines which needs
access to certain variables. In F90 common-blocks have been replaces
by a much more powerful facility - called modules. Modules can contain
both data and subroutines which can act on these. In addition it is possible
to set private and public attributes variables and subroutines - which
prohibits or allows use outside the module - in this way it is possible
for a number of routines to
share some variables without giving global access.
In F77 all array sizes have to be specified at compile time. To avoid
recompilation all the time arrays are dimensioned to 'always be large enough'
- which of course they never are. In F90 arrays can have the attribute
'allocatable' which means the size of the arrays can be decided at run-time.
When considering reading in observed profile data this a major advantage.
GOTM v2.0.0 and higher is build around some - to a large degree - self-contained
modules. Each of these modules perform some very specific tasks and interacts
with the 'outside' world via 'public member functions' and 'public member
data'. GOTM is divided into 4 layers . Layer 0 serves only one purpose
namely to start the model - when run as a stand alone application this
is done via main.F90. Level 1 controls everything in the model run - the
model is initialised by calling a number of initialisation routines provided
by the different modules, the actual integration is done and finally the
model is grace-fully shut down. Level 2 contains the various modules -
meanflow, turbulence etc.. Level 3 contains the routines that actually
do the calculations and which will be called from level2. A short rationale
for this structure follows: for the user who just wants to make simulations
and doesn't care too much about 'what’s under the hood' it is only necessary
to know about level 0 - how do I start the model. On the other hand it
is possible for developers to make changes/additions/new algorithms in
level 2 and 3 without the user even knows and without the way the program
is operated changes.
One of the problems with numerical models is how to store the results.
In the previous versions of GOTM we supplied two methods for output - one
was ASCII in a tabular format - the other was native GrADS format. Both
of these methods have proven to be inadequate for GOTM. ASCII because we
loose backward compatibility with user developed scripts/programs if we
start to add more columns or blocks of data. GrADS because it was not portable
between platforms and because of confusion in F77 concerning the 'recl=
' specifier when writing binary data - does the recl specifier count bytes
or elements. In addition adding additional fields to GrADS native format
not straight forward. Because of these problems we looked for an alternative
and we soon decided to adopt the NetCDF format - both because one of the
authors (Karsten Bolding) already had experience with NetCDF and also because
it fulfilled out requirements - namely - it is supported on many architectures
and can be moved freely between these architectures, it is fairly
easy to add additional output without loosing compatibility with previous
versions, there is a great variety of software - both Open Source
and commercial - available for post processing - we will provide some links
on www.gotm.net. In fact GrADS can read NetCDF if the so-called COARDS
convention is kept. However, we have decided to keep the option for ASCII
output since not all users will have access to NetCDF immediately - but
we strongly encourage to use NetCDF when possible. However, if the user
wants to implement her/his own output format we kept the possibility in
the code to fairly easy implement new output formats.
As the time go we hope that users will start to provide scripts etc
for post-processing purposes - we would like to create a users area on
the web-site for exchange of these scripts. Pierre-Phillipe Mathieu has
started by making a GrADS script which will take as input a NetCDF file
and create a variety of jpeg plots ready to put on the web.
We provide two different versions of GOTM - with and without support
for NetCDF. Both versions unpack in a flat directory structure with only
one Makefile. It is necessary to edit the Makefile to reflect the F90/F95
compiler available. How to create modules from the source code is treated
differently for different Fortran compilers so the FFLAGS variable might
need to be set. In the version that supports NetCDF please edit NETCDFLIB
to reflect local conditions. In the near future it is the intention also
to release the development version of GOTM. The development version uses
a directory structure where different modules are in different directories
- in addition the code is pre-processed before compilation. So far we have
tested this on 3-4 platforms with success - but we have also tried at least
one platform where the Makefile system we have set up did not work - older
Suns seems to be the problem. We are working on it...
It is our intention to set up the 'Download Sourcecode' area similar
to the 'Download Test Cases' but since our webmaster - Pierre-Phillipe
Mathieu - has got a new job and will not have web access for a few weeks
we have to postpone this a bit.
We tested this new version on various compilers, and find (after intensive
changes in the code) no more problems. We would however appreciate if you
could test one of the scenarios and report to us which compiler you used
and which problems occurred. Manuel is currently running the new version
on a Windows NT platform. He will soon create a web page with respective
We hope that you enjoy this new version and look forward to your comments).