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:
Compared to v. 1.2.x this new version has the following new physical
features:
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
is
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
instructions.
We hope that you enjoy this new version and look forward to your comments).
Kind regards,
Your GOTM Team.
Hans Burchard (hans@gotm.net)
Karsten Bolding (karsten@gotm.net)
Manuel Ruiz Villarreal (uscfmmrv@ds.cesga.es)
Pierre-Philippe Mathieu (pp.mathieu@altavista.net)
Georg Umgiesser (georg@lagoon.isdgm.ve.cnr.it)