SourceWiki - User contributions [en]

GENIE Using netCDF

2012-05-23T09:30:02Z

Genie-user:

==Quickest Possible Start==

<pre>
cd genie/genie-main
make netcdf
</pre>

This will download the NetCDF library source code and compile, using the compiler selections in '''user.mak'''. Once built, the libraries will be placed in the '''NETCDF_DIR''', also set in '''user.mak'''.

==What is NetCDF? and why use it?==

NetCDF is fast becoming the de facto standard format for storing climate model data. It is a 'platform independent' format and so is good for sharing data between members of the community. The format is also flexible in what can be stored and self-documenting--two more very useful features. There is of course some overhead in learning any new file format, but I believe that using NetCDF is well worth the relatively small amount of effort (honest) involved.

Data are stored in NetCDF in the form of ''variables''. These can have '''dimensions''' and other '''attributes'''. A NetCDF file is split into two main sections; (i) a header, which describes all the variables, dimensions and attributes; and (ii) the data part in which, well, the data is stored (ahem).

In order to read and write data to and from a NetCDF file, we must tell our programs how to do it. To do this fro scratch each time would be both tedious and a waste of time. Luckily the kind folks at Unidata make a high-level ''interface'' available which we can use in our programs. This is distributed in the form of a ''library'' which we can link to our programs. (They produce libraries for a number of languages such as F77 and F90, C and C++.)

==Obtaining the NetCDF Libraries==

You can download the source code for the NetCDF libraries from the [http://www.unidata.ucar.edu/software/netcdf/ Unidata NetCDF web page]. '''Note''' for older versions of the libraries, there is a choice of download between Fortran77 and Fortran90--i.e. there were different libraries for the two languages. For more recent versions however, one downloa fits all:

<pre>
wget http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.0.tar.gz
</pre>

==Compiling the NetCDF libraries==

The Unidata webpage contains links to documentation describing installing and using the libraries. However, the quickstart below, may be enough to get you going. Note that it's far easier if you use the same fortran compiler to compile both GENIE and the NetCDF libraries. If you do not, then you will need to become familiar with compiler options which deal with the topic of "name mangling" (enough said). Note that you will also most likely fair better with an up-to-date copy of the NetCDF libraries. The libraries are written in C and Fortran. You need to set some environment variables to tell the installation process which compilers you are using. On my Linux system, using gcc to compile the C code and ifort for the Fortran, I typed the following in my bash shell:

<pre>
tar -xzf netcdf-4.0.tar.gz
cd netcdf-4.0
./configure --prefix=${HOME}/netcdf/4.0 FC=gfortran CC=gcc CXX=g++ CPPFLAGS="-DpgiFortran"
make
make check
make install
</pre>

Check that you have the created all the files you need. You should see '''libnetcdf.a''' in the your installation lib directory. For Fortran90 support, you will also need '''netcdf.mod''' in the include directory.

==Linking with GENIE==

Once you have compiled the NetCDF libraries, you must make them available to GENIE. To do this, you will need edit '''genie-main/user.mak'''. If you followed the example above, you should edit the line begining '''NETCDF_DIR=''' to be '''NETCDF_DIR=/opt/local'''.

==If you get Compilation Errors==

If you have followed the guidelines above and you still find you get errors compiling GENIE, then it is likely that these are due to something called '''name-mangling'''. When I compiler creates ''object code'' from source code (you will see .o files created from .f files, for example--.o stands for 'object'), it ''mangles'' or decorates the names of functions, subroutines etc. typically with a number of leading or trailing underscores. This is all fine and dandy--so long as the decorated names, or ''symbols'', match between your program and your library. If different compilers were used to compile your NetCDF libraries and GENIE, then you will get a mismatch, and errors about '''unresolved symbols''', i.e. compiler A might work with symbols like '''myname_''', wheeras compiler B might expect '''myname__''' and hence we get trouble.

If you are in this situation, you can do one of several things:

# Make sure you use the same compiler for both the NetCDF libararies and GENIE.
# If (1) is true and you are using the '''g95''' compiler, you will need to add '''-fno-second-underscore''' to the Fortran compilation flags for both the NetCDF libs and GENIE
# If you can't satisfy (1) an argument to your compiler (such as in 2) can change the way it mangles names so that you can match the symbols in your NetCDF libraries to those expected when compiling GENIE.

If you must use different compilers, you will find the UNIX command line tool '''nm''' useful for examing the contents of object files and libraries, e.g. <tt>nm path_to_netcdf_lib</tt> or <tt>nm path_to_a_genie_object_file</tt>. Determine the form of decoration and provide the appropriate options to the compiler.

GENIE Versions

2012-05-23T09:21:05Z

Genie-user:

==GENIE Versions==

Latest released version: 2.7.1 (SVN tag '''rel-2-7-1''')
{| border="1" cellpadding="5"
! Released Version
! Date
! SVN tag
! Comments
|-
| 2.8.0
| May 2012
| '''rel-2-8-0'''
| Cut down genie.F now default
|-
| 2.7.7
| April 2011
| '''rel-2-7-7'''
|
|-
| 2.7.5
| January 2011
| '''rel-2-7-5'''
|
|-
| 2.7.4
| October 2010
| '''rel-2-7-4'''
|
|-
| 2.7.3
| August 2010
| '''release-2-7-3'''
|
|-
| 2.7.2
| August 2010
| '''rel-2-7-2'''
|
|-
| 2.7.1
| May 2010
| '''rel-2-7-1'''
|
|-
| 2.7.0
| May 2010
| '''rel-2-7-0'''
|
|-
| 2.6.0
| Feb 2010
| '''rel-2-6-0'''
|
|}

GENIE

2012-01-10T14:10:28Z

Genie-user:

[[Category:Projects]]

==Welcome to the GENIE wiki!==

===Science Pages===

* [[GENIE_module_intros|Introductions to the GENIE component models]]
* [[GENIE:Internal|Wiki Pages for members of the GENIE project]]
* [http://www.genie.ac.uk The GENIE website]

===Tutorials for Using the Model===

* [[GENIE_running_an_expt|Installing and running GENIE on your local machine]]
** [[GENIE_WindowsCompilation|Configuring a Windows build environment]]
* [[GENIE_Main|An overview of the key files in genie_main]]
* [[GENIE_Using_netCDF|Using NetCDF]]
* [[Using_GLIMMER|Using GLIMMER]]
* [[GENIE_GENIELabInstall|Installing GENIELab -- Running and Tuning GENIE from MatLab]]
* [[GENIE_GENIELab|Using GENIELab]]
* <del>[[GENIE_Using_NaturalDocs|Using NaturalDocs to document your code]]</del>
* [[GENIE_Using_Doxygen|Using Doxygen to document your code]]
* [[GENIE_How-To|GENIE How-To]]

===Framework Documentation===

* [[GENIE_Coupling|PRISM coupling in GENIE]]
** [[GENIE_Gridspec|Gridspec for GENIE]] - towards a standard description for model grids (for use in PRISM coupling)
** [[GENIE_BFG|Introduction to BFG]] - BFG will automatically generate framework code (the "glue" code between models) for PRISM coupling

* [[GENIE_ALADDIN2|ALADDIN: the GENIE launchpad]]

===Misc===

* [[GENIE_Quick_wiki_ref|Very sparse quick tips on wiki editing]]

GENIE Quick wiki ref

2012-01-10T14:08:45Z

Genie-user: moved GENIE:Quick wiki ref to GENIE Quick wiki ref

==Adding New Pages==

* An easy way to create a new wiki page is to add a link to the new page from an existing page, e.g. <pre>[[GENIE_MyPage|A link to my page]]</pre> Save your changes, and the link will appear in red. When you click on the link, you will be able to edit the content of the new page.

* Another way to create a new page is to type a URL in the address window and, again, a new page will automatically be created, e.g. <pre> http://source.ggy.bris.ac.uk/wiki/GENIE_new_page_name </pre> Remember to link it to another page, however, or it will be left in limbo!

==Editing Content==

Below are a some examples markup used to format wikimedia pages (for more detail visit [http://meta.wikimedia.org/wiki/Help:Wikitext_examples markup examples]).

First click '''edit'''. Click on '''Show preview''' to see the effect of your changes, and '''Save page''' when you're happy.

* Headings <pre> ==Section Heading== ===Subsection=== ====Subsubsection==== </pre>
* Bullet lists <pre> * Item ** Indented item *** Deeper indentation</pre>
* Numbered lists <pre> # Item ## Sublist item ### etc </pre>
* Description lists <pre> ; Category : description </pre>
* Bold <pre> '''text''' </pre>
* Italics <pre> ''text'' </pre>
* Internal page links <pre>[[GENIE:MyPage|A link to my page]]</pre>
* External page links <pre> [http://www.google.co.uk Click here for Google] </pre>
* Tables
<pre> {| border="1" cellspacing="0" cellpadding="5" align="center"
! This
! is
|-
| a
| table
|-
|}
</pre>

GENIE Quick wiki ref

2012-01-10T14:08:12Z

Genie-user:

GENIE

2010-09-26T10:45:34Z

Genie-user: added How-To page

GENIE WindowsCompilation

2010-05-10T14:30:27Z

Genie-user:

==Building GENIE on Windows Platforms==
The GENIE makefiles have been modified to enable a command line compilation of the framework under Windows using Linux emulation software.

===Prerequisites===
In order to build GENIE on a Windows platform you will need to install and configure a suitable environment consisting of

* A linux emulator
* Third party libraries including NetCDF
* A Windows Fortran compiler
* A Windows Linker

The build system is known to work with the following software:

{| border="1" cellspacing="0" cellpadding="5" align="center"
!colspan="2"|Tool
!Software
!Versions
!Notes
|-
| rowspan="2" colspan="2"| Linux emulation
| CygWin
| 1.5.12-1
|  
|-
| MinGW (MSYS)
| 1.0.10
| Build only. There is no bash shell available so genie_example.job cannot be executed.
|-
| rowspan="2" colspan="2"| Third party libraries
| NetCDF
| 3.5.0, 3.6.0, 3.6.1, 3.6.2
| Pre-built dll from UCAR can be used with the native microsoft compilers. We recommend building the NetCDF library locally.
|-
| Python
| 2.3.3+
| Available in CygWin. Must be installed separately for MinGW.
|-
| rowspan="5"| Native Microsoft
| rowspan="2"| Fortran Compiler
| Compaq Visual Fortran
| 6.6C
|  
|-
| Intel Visual Fortran
| 9.1, 10.0, 10.1
|  
|-
| rowspan="3"| C/C++ Compiler / Linker
| Microsoft Visual Studio .NET 2003
| 7.1.3088
|  
|-
| Microsoft Platform SDK for Server 2003
| R2
|  
|-
| Microsoft Visual Studio 2005
| 8.0.50727.762
|  
|-
| rowspan="4"| GNU Compilers
| rowspan="2"|Fortran Compiler
| GNU g95
| 0.91
|  
|-
| GNU gFortran
| 4.3.0
|  
|-
| rowspan="2"| C/C++ Compiler / Linker
| GNU gcc
| 4.0.3
|  
|-
| GNU ld
| 2.16.91
|  
|}

===Installing a Linux Emulator===
In order to execute the GENIE build process on a Windows platform it is necessary to install a Linux emulator that can process the GNU make files. There are two popular Linux emulation tools for Windows; Cygwin and MinGW. Cygwin provides a comprehensive Linux emulation layer for Windows and can be used to build, execute and manage GENIE. MinGW (Minimalist GNU for Windows) provides a limited set of tools that are sufficient to build GENIE but cannot be used to configure the model for execution. We therefore recommend the Cygwin route but provide details of MinGW for completeness.

====Cygwin installation====
Download the Cygwin setup executable from the Cygwin website at [http://cygwin.com/ http://cygwin.com/].
Execute the setup program and install Cygwin as directed.
When asked to select packages please ensure that the following packages are installed:
* Base --> bash
* Devel --> make
* Devel --> gcc, gcc-core, gcc-g77, gcc-g++, subversion
* Utils --> diffutils
* Interpreters --> python
* Interpreters --> perl (for documentation)
* Libs --> libxslt
* gfortran specific requirements
** Math --> gmp
** Math --> mpfr

The Cygwin file <code>C:\cygwin\bin\link.exe</code> needs to be moved so that the Visual Studio <code>link.exe</code> linker can be picked up in preference. Alternatively, the Cygwin path would need to be updated to place the Visual Studio linker ahead of the Cygwin default.

Native Win32 Compiler Configuration

Compaq Visual Fortran

We assume that you have a standard installation of the Intel or Compaq Visual Fortran product on your system. In order to make the compiler and linker available at the command line within the Cygwin shell we recommend editing the batch file that launches Cygwin as follows. Edit the file <cygwin>/cygwin.bat (adjusting the paths to the compilers as appropriate):

<pre>
@echo off

call "C:\Program Files\Microsoft Visual Studio\DF98\BIN\DFVARS.BAT"
call "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.bat"

C:
chdir C:\cygwin\bin

bash --login -i
</pre>

Intel Visual Fortran

<pre>
@echo off

call "C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\SetEnv.Cmd" /XP32 /RETAIL
call "C:\Program Files\Intel\Compiler\Fortran\9.1\ia32\Bin\IFortVars.bat"

C:
chdir C:\cygwin\bin

bash --login -i
</pre>

GNU g95 Compiler Installation

For up to date details please see [http://ftp.g95.org/#Win http://ftp.g95.org/#Win].
Download g95-x86-cygwin.tgz from [http://ftp.g95.org/g95-x86-cygwin.tgz http://ftp.g95.org/g95-x86-cygwin.tgz].
Copy this file to the root of your cygwin distribution.
In cygwin:
cd /
tar zxvf g95-x86-cygwin.tgz

GNU gFortran Compiler Installation

For up to date details please see [http://gcc.gnu.org/wiki/GFortranBinariesCygwin http://gcc.gnu.org/wiki/GFortranBinariesCygwin].
Download the latest release of the compiler. A link to the location of the latest release can be found at [http://gcc.gnu.org/wiki/GFortranBinaries http://gcc.gnu.org/wiki/GFortranBinaries].
Move the release archive to the Cygwin root directory.
In Cygwin:
cd /
tar jxvf gfortran-4.3-Cygwin-i686.tar.bz2
ln -s /usr/local/gfortran/bin/gfortran.exe /usr/local/bin/gfortran
ln -s /usr/local/gfortran/bin/gfortran.exe /usr/local/bin/gfc

====MinGW installation====
MinGW [http://www.mingw.org/ http://www.mingw.org/] provides a build environment capable to generating Windows executables that do not rely on 3rd party dlls.

===Building NetCDF===
Download NetCDF source release from UCAR:
http://www.unidata.ucar.edu/downloads/netcdf
Extract the contents of the archive to a convenient location <netcdf_root>.

====Microsoft Compilers====
The GENIE framework requires a full installation of the NetCDF library including the C, F77, F90 and C++ interfaces (although the latter is only required for the nightly build tests and can be omitted if these will not be run). The UCAR website does not currently (August 2005) provide pre-built binaries for Win32 satisfying these requirements so we must build the libraries manually.

Download the NetCDF source code from the UCAR website:

[ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf.tar.gz ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf.tar.gz]

Extract the contents of the archive to a local directory. Open the src\win32\NET\netcdf.sln file with Microsoft Visual Studio. Open the Configuration Manager and set the Active Solution to "Release". Highlight the netcdf project and open the properties dialog. Select C/C++ -> Command Line and add the following compiler option in the Additional Options dialog:

/D FCALLSC_QUALIFIER="__declspec(dllexport) __stdcall"

This compiler directive causes the F77 interface to be built in addition to the default C interface. Build the solution and close Visual Studio.

Open a Command Prompt and configure the CVF and the VC++.NET environments (modify the paths to your local installation if necessary):

"C:\Program Files\Microsoft Visual Studio\DF98\BIN\DFVARS.BAT"
"C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.bat"

Navigate to the src\f90 directory and build the F90 library:

Compaq Visual Fortran:
f90.exe /compile_only typeSizes.f90
f90.exe /compile_only netcdf.f90
lib /OUT:netcdf_f90.lib typeSizes.obj netcdf.obj

Intel Visual Fortran:
ifort.exe /iface:cvf /compile-only typeSizes.f90
ifort.exe /iface:cvf /compile-only netcdf.f90
lib /OUT:netcdf_f90.lib typeSizes.obj netcdf.obj

The Win32 build of the C++ interface is not officially supported by UCAR (at least no specific documentation exists on this). Unfortunately, we require a 'hack' to the code to get the C++ interface to build using Visual Studio. Create a copy of the netcdf.h header file:

copy src\libsrc\netcdf.h src\cxx\netcdf.h

Edit the new copy of netcdf.h in src\cxx and comment out line 199 (line number may vary between releases)

// #define off_t __int64

Navigate to the src\cxx directory and build the C++ library:

netcdf-3.6.0-p1:
cl.exe /c /O2 /I..\libsrc /DNDEBUG /D "DLL_NETCDF" /EHsc netcdf.cpp
cl.exe /c /O2 /I..\libsrc /DNDEBUG /D "DLL_NETCDF" /EHsc ncvalues.cpp
lib /OUT:netcdf_c++.lib netcdf.obj ncvalues.obj

netcdf-3.6.1:
cl.exe /c /O2 /I..\libsrc /I..\win32\NET /DNDEBUG /D "DLL_NETCDF" /EHsc netcdf.cpp
cl.exe /c /O2 /I..\libsrc /I..\win32\NET /DNDEBUG /D "DLL_NETCDF" /EHsc ncvalues.cpp
lib /OUT:netcdf_c++.lib netcdf.obj ncvalues.obj

Unfortunately, we have to create our own installation. Please create directories and copy files as indicated below. Use the command prompt or Windows Explorer according to preference.

<pre>
cd <netcdf_root> (contains the src folder)
[cut-and-paste should work for the commands below]

mkdir bin
mkdir lib
mkdir include

copy src\win32\NET\Release\netcdf.dll bin\
copy src\win32\NET\Release\ncdump.exe bin\
copy src\win32\NET\Release\ncgen.exe bin\

copy src\win32\NET\Release\netcdf.lib lib\
copy src\f90\netcdf_f90.lib lib\
copy "src\cxx\netcdf_c++.lib" lib\

copy src\libsrc\netcdf.h include\
copy src\fortran\netcdf.inc include\
copy src\f90\netcdf.mod include\
copy src\f90\typeSizes.mod include\
copy src\cxx\netcdf.hh include\
copy src\cxx\netcdfcpp.h include\
copy src\cxx\ncvalues.h include\
</pre>

====GNU Compilers====
In a Cygwin environment that has g95 installed, navigate to the NetCDF directory (here <netcdf_root_cygpath> refers to the location of the NetCDF root in the Cygwin path style. e.g. /cygdrive/c/netcdf-3.6.2).
cd <netcdf_root_cygpath>

g95 Compiler

FC=g95 ./configure --prefix=<netcdf_root_cygpath>
make check
make install

gfortran Compiler

FC=gfortran CPPFLAGS=-DpgiFortran ./configure --prefix=<netcdf_root_cygpath>
make check
make install

'''NB. If the <code>configure</code> phase fails indicating that the f90 compiler is not working then please check that you have installed the Math packages GMP and MPFR into Cygwin.'''

'''If <code>make check</code> fails, try <code>make distclean</code> ,reset your enviroment variables and rerun <code>configure</code>.'''

===Configuring the GENIE build===
I strongly recommend checking out the GENIE code into a directory that does not contain any space characters. We have not tested builds with paths containing spaces, they may or may not work. Life is simpler without the spaces.

====Native Microsoft Compilers====
Edit user.sh:
CODEDIR=/cygdrive/drive_letter/path/to/genie
OUTROOT=/cygdrive/drive_letter/path/to/output

Edit user.mak:
GENIE_ROOT=/cygdrive/drive_letter/path/to/genie
OUT_DIR=/cygdrive/drive_letter/path/to/output

Select the appropriate Windows version of the GNU compiler:
Either:
F77=f90.exe
Or:
F77=ifort.exe

And set the other relevant flags

CXX=cl.exe
MACHINE=WIN32
NETCDF_DIR=E:\\users\\andrew\\netcdf-3.6.0-p1
NETCDF_NAME=netcdf.lib

Change the path as appropriate for the location of your Win32 NetCDF installation.

====GNU Compilers====
Edit user.sh:
CODEDIR=/cygdrive/drive_letter/path/to/genie
OUTROOT=/cygdrive/drive_letter/path/to/output

Edit user.mak:
GENIE_ROOT=/cygdrive/drive_letter/path/to/genie
OUT_DIR=/cygdrive/drive_letter/path/to/output

Select the appropriate Windows version of the GNU compiler:
Either:
F77=g95.exe
Or:
F77=gfc.exe

And set the other relevant flags (please note that despite being a Windows build this is identical to a Linux setup)
CC=gcc
CXX=g++
MACHINE=LINUX
NETCDF_DIR=<netcdf_root_cygwin>
NETCDF_NAME=netcdf

===Executing the GENIE build===
Somewhat ironically, the Windows build in Cygwin is not at all forgiving of any Windows CRLF in the scripts it processes. After performing any edits on the files with native Windows tools it is recommended to sanitise the files in genie-main using <code>dos2unix</code>.

dos2unix genie-main/*
dos2unix genie-main/configs/*

At the CygWin bash prompt make sure that the NetCDF DLL and Python are in the system path. If you have installed Cygwin's release of Python then this should already be available on the path, if not then update as follows:

$ export PATH=$PATH:/cygdrive/c/netcdf/bin:/cygdrive/c/Python

It is worth checking that Python can be invoked from the shell and that the version is >1.5.2. To build the binary it should be possible to execute the make command:

$ cd [install-path]/genie-main
$ make

The following warning message will be issued during the final link phase of the Compaq/Intel build:

LINK : warning LNK4044: unrecognized option "module:..\genie-lib\mod"; ignored

This is an expected outcome and does not impact the final production of the GENIE binary.

===Running GENIE===
In the Cygwin environment you should find that <code>genie_example.job</code> and <code>make <test_target></code> should work in exactly the same way as in Linux. The XML configuration files should be successfully processed by the version of xsltproc available in Cygwin.

Please note that to run the GENIE binary on a remote system you will need to package up the cygwin1.dll file along with the genie.exe binary and appropriate configuration files.

The MinGW/MSYS shell cannot successfully invoke <code>genie_example.job</code>. Please look at the GENIELab software as an alternative means of managing the binary if you have Matlab available on your system.

Fortran1

2010-05-04T23:58:17Z

Genie-user: /* hello, world */

[[Category:Pragmatic Programming]]
'''Fortran1: The Basics'''
=Getting the content for the practical=
We'll forge our path through the verdant garden of '''Fortran90''' using a number of examples. To get your copy of these examples, from the version control repository, login to your favourite linux machine (perhaps dylan), and type:

<pre>
svn co http://source.ggy.bris.ac.uk/subversion-open/fortran1/trunk fortran1
</pre>

=hello, world=

Without further ado, and in-keeping with the most venerable of traditions, let's meet our first example--"hello, world":

<pre>
cd fortran1/examples/example1
</pre>

You can compile the program by typing:

<pre>
gfortran hello_world.f90 -o hello_world.exe
</pre>

and run it by typing:

<pre>
./hello_world.exe
</pre>

'''Bingo!''' You've just compiled and run, perhaps your first, Fortran90 program. Hurrah! we're on our way:) Everybody whoop! Yeehah!

OK, OK...you'd better reign in your excitement. This is serious you know!:)

Enough of the magic, let's take a look inside the source code file. Take a look at the contents of hello_world.f90, using '''cat''', '''less''', '''more''' or your favourite text editor, and you'll see:

<source lang="fortran">
!
! This is a comment line.
! Below is a simple 'hello, world' program written in Fortran90.
! It illustrates creating a main 'program' unit together
! with good habits, such as using 'implicit none' and comments.
!
program hello_world
implicit none
write(*,*) "hello, world"
end program hello_world
</source>

We have:
#some comment lines, giving us a helpful narrative
#the start of the '''main program unit'''
#the '''implicit none''' statement (more of that in the next section, but suffice to say, every well dressed Fortran program should have one)
#a '''write''' statement, printing our greeting to the screen
#and last, but not least, the end of the main program.

This is all pretty straight forward, right? Open-up your text editor and try changing the greeting, just for the heck of it. Retype '''make''' and re-run it. We'll adopt a similar strategy for all the other examples we'll meet. If you ever want to get back to the original version of a program, just type:

<pre>
svn revert hello_world.f90
</pre>

Although this has all been fairly painless, we have made a very significant step--we are now editing, compiling and running Fortran programs. All the rest is basically just details!:)

=Containers and the Types of Things=

As fun as "hello, world" was, let's spice things up a little. For instance, let's introduce some variables. We'll need to move to the next example:

<pre>
cd ../example2
</pre>

Fortran90 has several types of built-in, or '''intrinsic''', variables. Take a look in '''intrinsic_types.f90''':

<pre>
character :: sex ! a letter e.g. 'm' or 'f'
character(len=12) :: name ! a string
logical :: wed ! married?
integer :: numBooks ! must be a whole number
real :: height ! e.g. 1.83 m (good include units in comment)
complex :: z ! real and imaginary parts
</pre>

This set of types suffice for a great many programs. The above are all single entities. We'll meet arrays of things in a couple of examples time. In ''Fortran2'', we'll also meet user-defined types. These allow us to group instances of intrinsic types together forming new kinds of thing--new types. User-defined types are the ''bees knees'' and can make programs much easier to work with. We'll leave the details to that later course, however.

The above snippet shows some variable '''declarations''', along with a helpful comments. It's good practice to comment your declarations, as a programmer new to your code (or even yourself in a couple of months time) can have a hard time figuring out what is supposed to be stored in such-and-such a variable. While we're on the topic, it's also good practice to give your variables meaningful names, even if they are long. Trust me, a bit more typing now, perhaps, but a lot less head-scratching later on over what is stored in the inspiringly named '''xbNew''', or '''z2'''!

It's often a good idea to give variables an initial value when we declare them (working with unitialised variables in another common source of bugs):

<pre>
character :: nucleotide = 'A' ! DNA has A,C,G & T
character(len=50) :: infile = 'yourData.nc', outfile = "myData.nc"
logical :: initialised = .true. ! or .false.
real :: solConst = 1.37 ! Solar 'constant' in kW/m^2
complex :: sqrtMinusOne = (-1.0, 0.0) ! sqrt(-1)
</pre>

Fortran90 also allows us to gives variables certain attributes, for example:

<pre>
real,parameter :: pi = 3.14159 ! a fixed constant
real(kind=8) :: totPrecip ! this is preferred to 'double precision'
</pre>

The '''parameter''' attribute tells you, me and Fortran that '''pi''' is a '''constant'''. It's fixed and it's a compile-time error if we try to change it. This is a good thing, since we can catch nasty bugs that can creep in that way. We never want pi to be anything other than pi, right?! Assigning '''parameter''' attributes to quantities we know are constant is an example of '''defensive programming''', or ''bug avoidance''!

By default reals in Fortran are represented using 4 bytes of memory. The addition of '''(kind=8)''' gives us an 8-byte real, often referred to a '''double precision''' real. Fortran does have a ''double precision'' type, but the '''kind''' attribute is preferred. (Many compilers also support the promotion of all default, 4-byte reals and integers in your program through flags, typically named ''-r8'' and ''-i8'', respectively.) 8-byte reals can be useful as accumulators, since they can help to avoid rounding errors.

The remaining part of the program illustrates some pitfalls--'''beware!''':
* '''integer division''' and it's truncation
* '''casting''' as a solution to mismatched types
* (integer) '''overflow'''
* (real number) '''underflow'''

Let's have a play with the program. You an compile it and run it by typing:

<pre>
make
./types.exe
</pre>

Although we compiled our first example ''by-hand'', we'll be using '''make''' to compile the rest of our example programs, so you won't have to worry about that side of things. (If you'd like to know more about make, you can take a look at [[Make|our course on make]], presented in a very similar style to this here excursion into Fortran90.)

Now modify the program (remembering "svn revert intrinsic_types.f90" if you make a mess). Try giving values to various types and also using operators such as:

* arithmetic: +, -, /, ** (exponentiation)
* functions: sin, cos, floor (rounding down)
* logic: .and., .or., .not., .eqv., .neqv.
* and you'll meet many more in the future..

For example:

* Calculate the [http://en.wikipedia.org/wiki/Sphere#Surface_area_of_a_sphere surface area of a sphere].
* Is sine of pi divided by four really the same as one over root two?
* What is the truth table of the NAND operator?

----

About that mysterious '''implicit none''' which we keep seeing at the start of our programs. Let me tell you a story: Once upon a time, the kings and queens of the garden of Fortran, being a generous and well meaning bunch, decided to save the programmers the bother of specifying the type of their variables. "Don't bother!", they said, "just be sure to give them appropriate names, and well sort out the rest." "Thank you. Thank you very much", said the programmers, and it was decreed that the names of integers should start with the letters i, j, k, l, m, or n, and the names of reals would start with the other letters. Anyhow, this all seemed like a great wheeze and everybody was very happy. This lasted for a while, but after time, the programmers got complacent and forgot how to name things and it all got rather messy. Integers became reals, reals became integers and before they knew it, the programmers had '''bugs all over the place!''' Boo. The kings and queens conferred on the matter and they realised that they had made a grave error in their gift of implicit typing. However, they couldn't undo what they had done. Instead, they had to persuade the programmers to give it up voluntarily. "Anything, anything!", they pleaded "to get rid of '''all these bugs!'''", and so it passed that every good programmer agreed to put '''implicit none''' at the top of every program they wrote, and they all lived happily ever after.

=If, Do, Select and Other Ways to Control the Flow=

Programs are like cooking recipes. We've covered the how much of this and how much of that part. However, we also need to cover the doing bit--do this and then do that, and for how long etc. This is generically termed '''control flow'''. Fortran gives us a fairly rich language with which to describe how we would like things done. Next example:

<pre>
cd ../example3
</pre>

Take a look inside '''control.f90'''. We have some variable declarations and then we encounter our first '''conditional''':

<pre>
if (initialised .eqv. .true.) then
write (*,*) "The variable 'area' is initialised and has the value:", area
else
write (*,*) "The variable 'area' is NOT initialised and has the value:", area
end if
</pre>

This is fairly self eplanatory--'''if'''..something is the case..'''then'''..'''else'''.. You can also have an '''elseif'''. In fact you can have as many of those as you like. You can also have as many statements inside each clause as you like. Talk about spoiled!

Our first '''do loop''' is of the form:

<pre>
do ii=1,5
write (*,*) "Do loop counter ii is:", ii
end do
</pre>

Again, this is fairly readable. '''ii''' is first given the value of 1, the body of the loop is evaluated and then we go back to the top again. Except this time we '''increment''' the counter (ii) by the '''default amount''', which is 1. When we're at the top and we take '''ii''' past 5, we stop the loop and move on to the next statement passed the '''end do'''. You're allowed as many statements inside the loop as you like. Indeed, you're allowed more loops, conditions, loops in loops, just about anything you can think of! '''Beware''', however, debugging a huge construct of nested this that and the other can be beyond the limits of human patience. Keep our programs simple and you will be happier for it.

The other loop examples show variations in the stopping condition and '''stride''' (i.e. how much we increment by), including counting backwards, and stopping before we've even started!

'''Select''' is another control structure. This is a neat way of saying, "if..then..elsif..else.." The '''default''' clause at the bottom is important. Dropping this off can lead to '''fall-through''', where none of the cases triggered. This is rarely what you want and can lead to nasty bugs.

As before, compile it, run it and generally muck about. These are only a few of the control structures provided to us by Fortran. You'll find that you can do most things with these three, however.

Before leaving this example, let's consider if tests containing an equals and floating point numbers. Remember that there are an infinite set of real numbers and so a computer can only approximate them. For example, '''how would a computer represent 10/3'''? It has limited precision. It follows therefore that we should be careful when we need to test whether a real number is equal some value, such as '''3.3''' (see the last section of the program). A common way around this problem is to subtract the first real from
second and to compare the '''absolute''' value of the result to some small threshold (to account for rounding errors).

'''Exercises'''

* Write a select statement which prints out the names of the digits in the set [1,10] in different languages. Write a loop to trigger each of these print statements.
* Write a nested loop: Write a pair of nested do loops which count between 1 and 3. Print the values of the two counters in the inner-most loop. Think about where your 'end do's should go.
* Write a nested if statement: For example, create character variables called 'vehicle', 'colour' and 'size'. We could represent a small red car as; vehicle = 'c', colour = 'r' and size = 's'. Arrange for your nested if to print 'eureka' given a big green train. Think about where your 'end if' statements should go.

=Not one, Many!=

That was fun. Back to thinking about variables for a moment:

<pre>
cd ../example4
</pre>

Last time we declared just one thing of a given type. Sometimes we're greedy! Sometimes we want more! To be fair, some things are naturally represented by a vector or a matrix. Think of values on a grid, solutions to linear systems, points in space, transformations such as scaling or rotation of vectors. For these sorts of things the kings and queens of Fortran gave us programmers '''arrays'''. Take a look inside '''static_array.f90''':

<pre>
real, dimension(4) :: tinyGrid = (/1.0, 2.0, 3.0, 4.0/)
real, dimension(2,2) :: square ! 2 rows, 2 columns
real, dimension(3,2) :: rectangle ! 3 rows, 2 columns
</pre>

The syntax here reads, "we'll have an one-dimensional array (i.e. vector) of 4 reals called tinyGrid, please, and we'll set the initial values of the cells in that array to be 1.0, 2.0, 3.0 and 4.0, respectively.

For the second and third declarations, we're asking for two-dimensional arrays. One with two rows and two colums, called ''square'', and one with three rows and two colums. We're calling that ''rectangle''.

The program then goes on to print out the contents of ''tinyGrid''.

Fortran90 provides a couple of handy '''intrinsic routines''' for determining the '''size''' (how many cells in total) and the '''shape''' (number of dimensions and the ''extent'' of each dimension) of an array. Fortran90 also allows us to '''reshape''' an array on-the-fly. Using this intrinsic, we can copy the values from ''tinyGrid'' into ''square''. Neat.

Fortran also provides us with a rather rich set of operators (+, -, *, / etc.) for array-valued variables. Have a go at playing with these. If you know some linear algebra, you're going to have a great time with this example!

'''Exercises'''

* Create 3x3 grid to store the outcome of a game of noughts-and-crosses (tic-tac-toe), populate it and print the grid to screen.
* Fortran allows you to '''slice''' arrays. For example the second column of the 2d-array 'a' is a(:,2). Print the third row from the grid above.
* Add two vectors together. Is this algebraically correct? What about adding two matrices?
* Create two 2-d arrays. Populate one randomly and create another as a mask. Combine the two matrices and print the result.

----

The static malarky is because Fortran90 also allows us to say we want an array, but we don't know how big we want it to be yet. "We'll decide that at run-time", we programmers say. This can be handy if you're reading in some data, say a pay-roll, and you don't know how many employees you'll have from one year to the next. Fortran90 calls these '''allocatable arrays''' and we'll meet them in ''Fortran2''.

=If Things get Hectic, Outsource!=

<pre>
cd ../example5
</pre>

Now, as we get more ambitious, the size of our program grows. Before long, it can get unwieldy. Also we may find that we repeat ourselves. We do the same thing twice, three times. Heck, many times! Now is the time to start breaking your program into chunks, re-using some from time-to-time, making it more manageable. Fortran gives us two routes to chunk-ification, '''functions''' and '''subroutines'''. Let's deal with subroutines first. In '''procedures.f90''', scroll down a bit and ou can see:

<pre>
subroutine mirror(len,inArray,outArray)

implicit none

! dummy variables
integer, intent(in) :: len
character,dimension(len),intent(in) :: inArray
character,dimension(len),intent(out) :: outArray

! local variables
integer :: ii
integer :: lucky = 3 ! notice scope of this identically named variable

do ii=1,len
outArray(len+1-ii) = inArray(ii)
end do

write (*,*) "'lucky' _inside_ subroutine is:", lucky

end subroutine mirror
</pre>

Now, note that this is '''outside''' of the main program unit. (In principle, we could hive this off into another source code file, but we'll leave that discussion until ''Fortran2''.) Notice also that we have a shiney '''implicit none''' resplendent at the top of the subroutine. Overall, it looks pretty similar to how a main program unit might look, but with the addition of '''arguments'''. Those fellows in the parentheses after the subroutine name. The declaration part also lists those arguments and we've commented that this are so-called '''dummy variables'''. We also see an attribute that we've not seen before, called '''intent'''. This is a very handy tool for defensive programming (remember aka ''bug avoidance''). Using ''intent'' we can say that the integer ''len'' is an input and as such we're not going to try to change it. Likewise for the caharcter array ''inArray''. It would be a compile-error if we did. We also state that the character array ''outArray'' is an output and we're going to give it a new value ''come what may''! We also have some variables that we note are '''local'''. Interestingly enough, one of our local variables, the integer called ''lucky'', has exactly the same name as a variable in the main program unit. When we run the program, however, we will see that the two do not interfere with each other. This is down to their '''scope'''. The scope of lucky in the main program is all and only the main program unit and the scope of lucky in the subroutine is all and only the subroutine. We say that the main program unit and the subroutine units have different '''name spaces'''.

Well, we've seen a lot of new syntax and concepts in all that. Useful ones though. This program is small and artificial, so it's hard to see the benefits just yet. You will, however, as your programs grow. The subroutine is '''called''' from the main program , funnily enough by a '''call''' statement. Notice how the arguments passed to the subroutine in the call statement also have different names in the main program and the subroutine. That's scope again.

Functions are a bit different to subroutines. Notice that we don't call them in the same way. We still pass arguments, but the functions '''returns''' and value, and so we could place a function on the right-hand side (RHS) of an assignment. Looking at the body of the function:

<pre>
function isPrime(num)

implicit none

! return and dummy variables
logical :: isPrime
integer, intent(in) :: num

select case (num)
case (2,3,5,7,11,13,17,19,23,29)
isPrime = .true.
case default
isPrime = .false.
end select

end function isPrime
</pre>

we can see that we have a declaration for a variable with the same name as the function. The type of this variable is the '''return type''' of the function. Indeed the value of this variable when we reach the bottom of the function is the value passed by to the calling routine. Note that we can call functions and subroutines from other functions and subroutines etc. in a nested fashion. This particular function is a fairly lame prime number spotter and returns a logical (.true. or .false.) depending upon whether its single input integer is prime.

The last thing of note is the funky '''interface''' structure at the top of the main program:

<pre>
interface
function isPrime(num)
logical :: isPrime
integer, intent(in) :: num
end function isPrime
end interface
</pre>

Our function '''definition''' is outside of the main program and so is said to be '''external'''. The main program unit needs to know about it, however, and an interface structure is a good way to do this as it prompts Fortran to check that all the arguments match up between the call and the definition. It's the way to do it.

Try running the program and writing some functions and subroutines of your own.

'''Exercises'''

* Write a simple error handling subroutine that '''stop'''s the program after printing a message, which is passed in as an argument.
* Does the surface area of a circle increase linearly with an increase in radius? How about circumference? Write some functions and a loop to investigate.
* What happens if you write a function which calls itself?

=Input and output=

==File i/o ==
<pre>
cd ../example6
</pre>

In this example we se how we can write output to a file and also read input from a file. before you can use a file, it needs to be opened. This is done with the open statement:

<pre>
open(unit=19,file="output.txt",form='formatted',status='old',iostat=ios)
</pre>

* the <tt>unit</tt> is just a number given to the file so that we can refer to it later. It needs to be between 1 and 99 and numbers 5 and 6 are reserved (5 for keyboard entry and 6 for screen output)
* the <tt>file</tt> is simply the name of the file to open
* the <tt>form</tt> is used to give the file format. It can be 'formatted' (i.e. a text file) or 'unformatted' (i.e. a binary file).
* he <tt>status</tt> specifies the behaviour if the file exists:
** <tt>'old'</tt> means the file must exists
** <tt>'new'</tt> means the file cannot exists pror to being opened
** <tt>'replace'</tt> is used when an old file will be overwritten
* <tt>iostat</tt> is used to return a non zero integer in case of an error, i.e. the file cannot be opened for instance.

After you are done with a file, you must close it:
<pre>
close(19)
</pre>

Note that if you need to go back to the beginning of a file, you don't have to close it and open it again, you can simly rewind it:
<pre>
rewind(19)
</pre>

To write in a file, the syntax is:
<pre>
write(unit=19,fmt=something) data, to, write
</pre>

* <tt>unit</tt> is simply the unit number of the file you want write to. Note that by default <tt>fmt=*</tt>, and the data is written to the screen.
* <tt>fmt</tt> is the '''format'''. It allows you to format the data you want to write (add spaces, number of significant digits etc...). The format can be given in the write statement or in another line. You should really look for more information about the formatting options.

Look at how the data is written in <tt>example6</tt> to see a range of options to output data.

To read information from a file, the <tt>write</tt> statement is used:

<pre>
read(unit=19,fmt=something,iostat=ios) data, to, read
</pre>

It is used in the reverse way from write really (if you can write you should able to read...). Of note is that it is very important to use the <tt>iostat</tt> keyword to make sure read errors are treated appropriately.

The last thing shown in <tt>example6</tt> is how more efficient binary data storage is compared to text/formatted data storing. The caveat is that you cannot directly look inside binary files using a text editor. In our case, the same data is written to two files, a text file and a binary file. Look at the size difference:
<pre>
-rw-r--r-- 1 ggjpr uucp 215K Feb 6 10:24 output.bin
-rw-r--r-- 1 ggjpr uucp 631K Feb 6 10:24 output.txt
</pre>

==Using character strings as file names==
<pre>
cd ../example7
</pre>

<tt>example7</tt> shows a little trick for people who output a lot of data and need to manipulate a lot of files. It is possible to use a write statement to output a number (or anything else) to a character string, use that string as a file name and open, close and output to many files on the fly. Look at <tt>io.f90</tt> in <tt>example7</tt> for a simple example.

==Namelists==
And all of a sudden, we're at our last example:

<pre>
cd ../example8
</pre>

In this one, we'll look at file-based input and output. Fortran provides a way of grouping variables together into a set, called a '''namelist''', that are input or output from our program ''en masse''. This is a common situation. The statement:

<pre>
namelist /example_nml/numBooks,initialised,name,vec
</pre>

sets it up.

Fortran further provides us with built-in mechanisms for reading or writing a namelist to or from a file.

First, we must open the file:

<pre>
open(unit=56,file='input.nml',status='old',iostat=ios)
if (ios /= 0) then
print*,'ERROR: could not open namelist file'
stop
end if
</pre>

In this snippet, we've associated the file called '''input.nml''' (you can find this in the directory already) with a so-called Fortran '''unit'''. Unit number 56 to be precise, although we could have picked any unit number we liked, so long as it wasn't associated with a different file. We also made sure to tell Fortran that this is an '''old''' file, i.e. that it already exists, and to check the error code, in case the '''open''' operation failed. If that were to happen, we've asked the program to halt with an error.

Now, assuming that we've opened the file OK, we proceed to read its contents. Fortran makes this rather easy for us, given that the information is contained in a namelist:

<pre>
read(UNIT=56,NML=example_nml,IOSTAT=ios)
if (ios /= 0) then
print*,'ERROR: could not read example namelist'
stop
else
close(56)
end if
</pre>

In the '''read''' statement, we told fortran that we wanted to read a namelist and that the group of variables should be labelled in the file as '''example_nml'''. Again we've checked the error status and decided to halt with an error should the read statement fail for any reason. Take a look at the contents of '''input.nml'''. See that it is ascii text and that the variables (with their values) do not need to be listed in the same order in the file as they are in the program. If the data is read successfully, we close the file unit.

The program procedes to print the values to screen, demonstrating that they have indeed come from the file, to assign new values to the variables and then to write the modified values to a new file, called '''modified.nml'''. Compare the two ascii text files. Try running the program a second time and you will recieve an error, telling you that the output could not be written since a file called modified.nml exists and that we expressly stated that is was to be a '''new''' file. Delete modified.nml, try again and it will succeed. Try changing the namelist, values, filenames etc. Go for it, make a mess! You'll learn a lot from it:)

'''Exercises'''

* Write some code to read in a colour (red, blue, green etc.) from a namelist and then print out the names of all the [http://en.wikipedia.org/wiki/Railway_engines_(Thomas_and_Friends) railway engines] (thomas, percy, gordon etc.) that match.
* Read in the dimensions of an ellipse from file and print out it's area.

= To go further =
The [[:category:Pragmatic Programming | Pragmatic Programming]] course continues with [[Linux2]], a look at some of the more advanced but very useful Linux concepts.

Now that you are getting familiar with Fortran, go a bit further by reading [[Fortran2]].

A useful reference: [http://www.amazon.co.uk/Fortran-Programming-International-Computer-Science/dp/0201544466 Fortran 90 Programming. Ellis, Philips, Lahey. Addison-Wesley. ISBN 0-201-54446-6].

GENIE Compiling

2010-03-31T10:51:53Z

Genie-user: /* Mac OSX - March 2010 */

=Mac OSX - March 2010=
by Greg Colbourn, with thanks to Simon Mueller

* Intel Core 2 Duo, 2.26GHz MacBook Pro
* OSX Snow Leopard 10.6.2, Xcode 3.2.1

1. Download netcdf from http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.0.1.tar.gz

2. Go to unzipped netcdf directory and type following commands:

export FFLAGS="-m32"; export FCFLAGS="-m32"; export CFLAGS="-m32"; export CXXFLAGS="-m32"

./configure --prefix=[your path]/netcdf-4.0.1 FC=/usr/local/bin/gfortran F90=/usr/local/bin/gfortran CC=gcc CXX=g++ CPPFLAGS="-DpgiFortran"

make check

make install

3. Comment out the line in the " # === GNU 'gfortran' compiler ===" section of genie-main/makefile.arc that says:

LDFLAGS += -static

4. In user.mak have:

F77=gfortran
CC=gcc
CXX=g++-4.0
NETCDF_NAME=netcdf

=Compilation error with NetCDF version 4=
If you are using identical compilers for genie and netcdf, but still get a compilation error message associated with netcdf (e.g. ''This module file was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read''), there may be a compatibility issue with your netcdf version. Switching from NetCDF version 4 (RHES4) to v3.6.1 has bypassed this problem (using Red Hat/ifort/icc), although the reason for this is not known.

k.i.c.oliver@open.ac.uk, 21st November 2006

=Intel Fortran v7.1, INT() and PARAMETER()=

ifcv7.1 will not compile statements of the form:

* PARAMETER (N=INT(..))

Hence they have been removed from genie-land/src/fotran/qsat.f

Gethin Williams Fri Dec 15 16:58:47 GMT 2006

=New line characters in text files (UNIX/Windows)=

===Description of problem===

UNIX uses a linefeed character (as should CVS internally), but Windows uses both carriage-return and linefeed (CR/LF). Some compilers/other tools may have trouble reading or displaying files that have the wrong new line characters for the platform. A symptom of this can be a large number of "odd-looking" compiler errors, and the problem may not be easy to spot because most code editors correctly display both UNIX and Windows new lines. Note that CVS should append the appropriate new line characters for the platform onto which a source file is checked out, but this may not be reliable.

===Suggested solutions===

If your text editor has an option allowing you to change the new line character, edit the option and save the file. UNIX commands are also available to do the job, for example:

* dos2unix -ascii my_source_file.f90 my_source_file.f90
* unix2dos -ascii my_source_file.f90 my_source_file.f90

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

=Standard Fortran compliance=

===Description of problem===

Most compilers allow extensions to the Fortran language, but using these extensions may cause errors when a different (often older) compiler is used. For instance, the only format descriptor that can be used without an explicit width is the character descriptor "A", however many compilers will allow other format descriptors to be used without a width, e.g. "G", to which a default width (and number of characters right of the decimal place) is applied by the compiler.

===Suggested solutions===

The GENIE overnight tests are carried out on several different platforms (Linux, Windows, Solaris) with different compilers. However, it isn't practicable to test every combination of platform and compiler, so when adding significant amounts of new code to GENIE it may be worth testing on more than one compiler/platform if available.

A good check for non-standard Fortran is to compile GENIE with an appropriate compiler option that checks for standards compliance (the compiler option can be added in makefile.arc). In general, it's best to avoid non-standard Fortran unless there's a strong argument for using it.

Compiler flags for popular Fortran compilers:

* -std -- Intel (ifort)
* -Mstandard -- Portland (pgf90)
* -ansi -- Sun (f95)

The ISO Fortran standard homepage is here: http://www.nag.co.uk/sc22wg5/

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

GENIE Compiling

2010-03-31T10:51:31Z

Genie-user: /* Mac OSX - March 2010 */ forgotten step

=Mac OSX - March 2010=
by Greg Colbourn, with thanks to Simon Mueller

* Intel Core 2 Duo, 2.26GHz MacBook Pro
* OSX Snow Leopard 10.6.2, Xcode 3.2.1

1. Download netcdf from http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.0.1.tar.gz

2. Go to unzipped netcdf directory and type following commands:

export FFLAGS="-m32"; export FCFLAGS="-m32"; export CFLAGS="-m32"; export CXXFLAGS="-m32"

./configure --prefix=[your path]/netcdf-4.0.1 FC=/usr/local/bin/gfortran F90=/usr/local/bin/gfortran CC=gcc CXX=g++ CPPFLAGS="-DpgiFortran"

make check

make install

4. comment out the line in the " # === GNU 'gfortran' compiler ===" section of genie-main/makefile.arc that says:

LDFLAGS += -static

3. In user.mak have:

F77=gfortran
CC=gcc
CXX=g++-4.0
NETCDF_NAME=netcdf

=Compilation error with NetCDF version 4=
If you are using identical compilers for genie and netcdf, but still get a compilation error message associated with netcdf (e.g. ''This module file was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read''), there may be a compatibility issue with your netcdf version. Switching from NetCDF version 4 (RHES4) to v3.6.1 has bypassed this problem (using Red Hat/ifort/icc), although the reason for this is not known.

k.i.c.oliver@open.ac.uk, 21st November 2006

=Intel Fortran v7.1, INT() and PARAMETER()=

ifcv7.1 will not compile statements of the form:

* PARAMETER (N=INT(..))

Hence they have been removed from genie-land/src/fotran/qsat.f

Gethin Williams Fri Dec 15 16:58:47 GMT 2006

=New line characters in text files (UNIX/Windows)=

===Description of problem===

UNIX uses a linefeed character (as should CVS internally), but Windows uses both carriage-return and linefeed (CR/LF). Some compilers/other tools may have trouble reading or displaying files that have the wrong new line characters for the platform. A symptom of this can be a large number of "odd-looking" compiler errors, and the problem may not be easy to spot because most code editors correctly display both UNIX and Windows new lines. Note that CVS should append the appropriate new line characters for the platform onto which a source file is checked out, but this may not be reliable.

===Suggested solutions===

If your text editor has an option allowing you to change the new line character, edit the option and save the file. UNIX commands are also available to do the job, for example:

* dos2unix -ascii my_source_file.f90 my_source_file.f90
* unix2dos -ascii my_source_file.f90 my_source_file.f90

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

=Standard Fortran compliance=

===Description of problem===

Most compilers allow extensions to the Fortran language, but using these extensions may cause errors when a different (often older) compiler is used. For instance, the only format descriptor that can be used without an explicit width is the character descriptor "A", however many compilers will allow other format descriptors to be used without a width, e.g. "G", to which a default width (and number of characters right of the decimal place) is applied by the compiler.

===Suggested solutions===

The GENIE overnight tests are carried out on several different platforms (Linux, Windows, Solaris) with different compilers. However, it isn't practicable to test every combination of platform and compiler, so when adding significant amounts of new code to GENIE it may be worth testing on more than one compiler/platform if available.

A good check for non-standard Fortran is to compile GENIE with an appropriate compiler option that checks for standards compliance (the compiler option can be added in makefile.arc). In general, it's best to avoid non-standard Fortran unless there's a strong argument for using it.

Compiler flags for popular Fortran compilers:

* -std -- Intel (ifort)
* -Mstandard -- Portland (pgf90)
* -ansi -- Sun (f95)

The ISO Fortran standard homepage is here: http://www.nag.co.uk/sc22wg5/

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

GENIE Compiling

2010-03-24T15:54:59Z

Genie-user: removed old Apple OSX and g95 section

=Mac OSX - March 2010=
by Greg Colbourn, with thanks to Simon Mueller

* Intel Core 2 Duo, 2.26GHz MacBook Pro
* OSX Snow Leopard 10.6.2, Xcode 3.2.1

1. Download netcdf from http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.0.1.tar.gz

2. Go to unzipped netcdf directory and type following commands:

export FFLAGS="-m32"; export FCFLAGS="-m32"; export CFLAGS="-m32"; export CXXFLAGS="-m32"

./configure --prefix=[your path]/netcdf-4.0.1 FC=/usr/local/bin/gfortran F90=/usr/local/bin/gfortran CC=gcc CXX=g++ CPPFLAGS="-DpgiFortran"

make check

make install

3. In user.mak have:

F77=gfortran
CC=gcc
CXX=g++-4.0
NETCDF_NAME=netcdf

=Compilation error with NetCDF version 4=
If you are using identical compilers for genie and netcdf, but still get a compilation error message associated with netcdf (e.g. ''This module file was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read''), there may be a compatibility issue with your netcdf version. Switching from NetCDF version 4 (RHES4) to v3.6.1 has bypassed this problem (using Red Hat/ifort/icc), although the reason for this is not known.

k.i.c.oliver@open.ac.uk, 21st November 2006

=Intel Fortran v7.1, INT() and PARAMETER()=

ifcv7.1 will not compile statements of the form:

* PARAMETER (N=INT(..))

Hence they have been removed from genie-land/src/fotran/qsat.f

Gethin Williams Fri Dec 15 16:58:47 GMT 2006

=New line characters in text files (UNIX/Windows)=

===Description of problem===

UNIX uses a linefeed character (as should CVS internally), but Windows uses both carriage-return and linefeed (CR/LF). Some compilers/other tools may have trouble reading or displaying files that have the wrong new line characters for the platform. A symptom of this can be a large number of "odd-looking" compiler errors, and the problem may not be easy to spot because most code editors correctly display both UNIX and Windows new lines. Note that CVS should append the appropriate new line characters for the platform onto which a source file is checked out, but this may not be reliable.

===Suggested solutions===

If your text editor has an option allowing you to change the new line character, edit the option and save the file. UNIX commands are also available to do the job, for example:

* dos2unix -ascii my_source_file.f90 my_source_file.f90
* unix2dos -ascii my_source_file.f90 my_source_file.f90

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

=Standard Fortran compliance=

===Description of problem===

Most compilers allow extensions to the Fortran language, but using these extensions may cause errors when a different (often older) compiler is used. For instance, the only format descriptor that can be used without an explicit width is the character descriptor "A", however many compilers will allow other format descriptors to be used without a width, e.g. "G", to which a default width (and number of characters right of the decimal place) is applied by the compiler.

===Suggested solutions===

The GENIE overnight tests are carried out on several different platforms (Linux, Windows, Solaris) with different compilers. However, it isn't practicable to test every combination of platform and compiler, so when adding significant amounts of new code to GENIE it may be worth testing on more than one compiler/platform if available.

A good check for non-standard Fortran is to compile GENIE with an appropriate compiler option that checks for standards compliance (the compiler option can be added in makefile.arc). In general, it's best to avoid non-standard Fortran unless there's a strong argument for using it.

Compiler flags for popular Fortran compilers:

* -std -- Intel (ifort)
* -Mstandard -- Portland (pgf90)
* -ansi -- Sun (f95)

The ISO Fortran standard homepage is here: http://www.nag.co.uk/sc22wg5/

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

GENIE Compiling

2010-03-23T18:47:01Z

Genie-user: /* Mac OSX - March 2010 */

=Mac OSX - March 2010=
by Greg Colbourn, with thanks to Simon Mueller

* Intel Core 2 Duo, 2.26GHz MacBook Pro
* OSX Snow Leopard 10.6.2, Xcode 3.2.1

1. Download netcdf from http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.0.1.tar.gz

2. Go to unzipped netcdf directory and type following commands:

export FFLAGS="-m32"; export FCFLAGS="-m32"; export CFLAGS="-m32"; export CXXFLAGS="-m32"

./configure --prefix=[your path]/netcdf-4.0.1 FC=/usr/local/bin/gfortran F90=/usr/local/bin/gfortran CC=gcc CXX=g++ CPPFLAGS="-DpgiFortran"

make check

make install

3. In user.mak have:

F77=gfortran
CC=gcc
CXX=g++-4.0
NETCDF_NAME=netcdf

=Apple OSX and g95=

* POWERPC, 1.5GHZ Powerbook
* OSX Tiger 10.4.7, Xcode 2.4

Genie compiles with g95, gcc and g++
* g95 0.90-1 (Fink download)
* gcc 4 (Xcode, probably)
* g++ 4 (Xcode, probably)

==Need to exclude biogem (code from cvs early October 2006)==

In genie-main makefile
MODULE_NAMES = igcm3 \
slabocean \
slabseaice \
fixedocean \
fixedseaice \
goldstein \
embm \
seaice \
fixedatmos \
land \
fixedland \
fixedicesheet \
fixedchem \
ichem \
atchem
# biogem \
# ichem

genie-main/genie_ini_wrappers.f90: Lines 262+:
! call initialise_biogenie(t0,go_dt,go_lin,go_lout, &
! and all the arguments...

genie-main/genie_loop_wrappers.f90: Lines 676+ and 725:

! call biogenie( &
! and all the arguments...

! call rest_biogem(go_lout,'.'//go_ext)

genie-main/genie.F: Line 1688:

c call end_biogenie(go_sfcatm(:,:,:))

==In order to work with netcdf (v3.6.1 compiled from source with g96, gcc and g++)==
You must compile netcdf with identical compilers to those used for genie. You may need to edit the netcdf configure script to make sure it finds the right compilers. Netcdf binaries downloaded via fin are therefore unlikely to work.

Then in genie-main makefile.arc comment out two flags:
#FFLAGS += -fno-second-underscore
#LDFLAGS += -static

Alternatively, if you can work out how to do it, compile netcdf with -fno-second-underscore. I couldn't fathom where to put that in.

jules@jamstec.go.jp, 30th October 2006.

=Compilation error with NetCDF version 4=
If you are using identical compilers for genie and netcdf, but still get a compilation error message associated with netcdf (e.g. ''This module file was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read''), there may be a compatibility issue with your netcdf version. Switching from NetCDF version 4 (RHES4) to v3.6.1 has bypassed this problem (using Red Hat/ifort/icc), although the reason for this is not known.

k.i.c.oliver@open.ac.uk, 21st November 2006

=Intel Fortran v7.1, INT() and PARAMETER()=

ifcv7.1 will not compile statements of the form:

* PARAMETER (N=INT(..))

Hence they have been removed from genie-land/src/fotran/qsat.f

Gethin Williams Fri Dec 15 16:58:47 GMT 2006

=New line characters in text files (UNIX/Windows)=

===Description of problem===

UNIX uses a linefeed character (as should CVS internally), but Windows uses both carriage-return and linefeed (CR/LF). Some compilers/other tools may have trouble reading or displaying files that have the wrong new line characters for the platform. A symptom of this can be a large number of "odd-looking" compiler errors, and the problem may not be easy to spot because most code editors correctly display both UNIX and Windows new lines. Note that CVS should append the appropriate new line characters for the platform onto which a source file is checked out, but this may not be reliable.

===Suggested solutions===

If your text editor has an option allowing you to change the new line character, edit the option and save the file. UNIX commands are also available to do the job, for example:

* dos2unix -ascii my_source_file.f90 my_source_file.f90
* unix2dos -ascii my_source_file.f90 my_source_file.f90

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

=Standard Fortran compliance=

===Description of problem===

Most compilers allow extensions to the Fortran language, but using these extensions may cause errors when a different (often older) compiler is used. For instance, the only format descriptor that can be used without an explicit width is the character descriptor "A", however many compilers will allow other format descriptors to be used without a width, e.g. "G", to which a default width (and number of characters right of the decimal place) is applied by the compiler.

===Suggested solutions===

The GENIE overnight tests are carried out on several different platforms (Linux, Windows, Solaris) with different compilers. However, it isn't practicable to test every combination of platform and compiler, so when adding significant amounts of new code to GENIE it may be worth testing on more than one compiler/platform if available.

A good check for non-standard Fortran is to compile GENIE with an appropriate compiler option that checks for standards compliance (the compiler option can be added in makefile.arc). In general, it's best to avoid non-standard Fortran unless there's a strong argument for using it.

Compiler flags for popular Fortran compilers:

* -std -- Intel (ifort)
* -Mstandard -- Portland (pgf90)
* -ansi -- Sun (f95)

The ISO Fortran standard homepage is here: http://www.nag.co.uk/sc22wg5/

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

GENIE Compiling

2010-03-23T17:56:59Z

Genie-user: removed mac os x march 2010 from middle of another section

=Mac OSX - March 2010=
by Greg Colbourn

* Intel Core 2 Duo, 2.26GHz MacBook Pro
* OSX Snow Leopard 10.6.2, Xcode 3.2.1

1. Download netcdf from http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.0.1.tar.gz

2. Go to unzipped netcdf directory and type following commands:

export FFLAGS="-m32"; export FCFLAGS="-m32"; export CFLAGS="-m32"; export CXXFLAGS="-m32"

./configure --prefix=[your path]/netcdf-4.0.1 FC=/usr/local/bin/gfortran F90=/usr/local/bin/gfortran CC=gcc CXX=g++ CPPFLAGS="-DpgiFortran"

make check

make install

3. In user.mak have:

F77=gfortran
CC=gcc
CXX=g++-4.0
NETCDF_NAME=netcdf

=Apple OSX and g95=

* POWERPC, 1.5GHZ Powerbook
* OSX Tiger 10.4.7, Xcode 2.4

Genie compiles with g95, gcc and g++
* g95 0.90-1 (Fink download)
* gcc 4 (Xcode, probably)
* g++ 4 (Xcode, probably)

==Need to exclude biogem (code from cvs early October 2006)==

In genie-main makefile
MODULE_NAMES = igcm3 \
slabocean \
slabseaice \
fixedocean \
fixedseaice \
goldstein \
embm \
seaice \
fixedatmos \
land \
fixedland \
fixedicesheet \
fixedchem \
ichem \
atchem
# biogem \
# ichem

genie-main/genie_ini_wrappers.f90: Lines 262+:
! call initialise_biogenie(t0,go_dt,go_lin,go_lout, &
! and all the arguments...

genie-main/genie_loop_wrappers.f90: Lines 676+ and 725:

! call biogenie( &
! and all the arguments...

! call rest_biogem(go_lout,'.'//go_ext)

genie-main/genie.F: Line 1688:

c call end_biogenie(go_sfcatm(:,:,:))

==In order to work with netcdf (v3.6.1 compiled from source with g96, gcc and g++)==
You must compile netcdf with identical compilers to those used for genie. You may need to edit the netcdf configure script to make sure it finds the right compilers. Netcdf binaries downloaded via fin are therefore unlikely to work.

Then in genie-main makefile.arc comment out two flags:
#FFLAGS += -fno-second-underscore
#LDFLAGS += -static

Alternatively, if you can work out how to do it, compile netcdf with -fno-second-underscore. I couldn't fathom where to put that in.

jules@jamstec.go.jp, 30th October 2006.

=Compilation error with NetCDF version 4=
If you are using identical compilers for genie and netcdf, but still get a compilation error message associated with netcdf (e.g. ''This module file was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read''), there may be a compatibility issue with your netcdf version. Switching from NetCDF version 4 (RHES4) to v3.6.1 has bypassed this problem (using Red Hat/ifort/icc), although the reason for this is not known.

k.i.c.oliver@open.ac.uk, 21st November 2006

=Intel Fortran v7.1, INT() and PARAMETER()=

ifcv7.1 will not compile statements of the form:

* PARAMETER (N=INT(..))

Hence they have been removed from genie-land/src/fotran/qsat.f

Gethin Williams Fri Dec 15 16:58:47 GMT 2006

=New line characters in text files (UNIX/Windows)=

===Description of problem===

UNIX uses a linefeed character (as should CVS internally), but Windows uses both carriage-return and linefeed (CR/LF). Some compilers/other tools may have trouble reading or displaying files that have the wrong new line characters for the platform. A symptom of this can be a large number of "odd-looking" compiler errors, and the problem may not be easy to spot because most code editors correctly display both UNIX and Windows new lines. Note that CVS should append the appropriate new line characters for the platform onto which a source file is checked out, but this may not be reliable.

===Suggested solutions===

If your text editor has an option allowing you to change the new line character, edit the option and save the file. UNIX commands are also available to do the job, for example:

* dos2unix -ascii my_source_file.f90 my_source_file.f90
* unix2dos -ascii my_source_file.f90 my_source_file.f90

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

=Standard Fortran compliance=

===Description of problem===

Most compilers allow extensions to the Fortran language, but using these extensions may cause errors when a different (often older) compiler is used. For instance, the only format descriptor that can be used without an explicit width is the character descriptor "A", however many compilers will allow other format descriptors to be used without a width, e.g. "G", to which a default width (and number of characters right of the decimal place) is applied by the compiler.

===Suggested solutions===

The GENIE overnight tests are carried out on several different platforms (Linux, Windows, Solaris) with different compilers. However, it isn't practicable to test every combination of platform and compiler, so when adding significant amounts of new code to GENIE it may be worth testing on more than one compiler/platform if available.

A good check for non-standard Fortran is to compile GENIE with an appropriate compiler option that checks for standards compliance (the compiler option can be added in makefile.arc). In general, it's best to avoid non-standard Fortran unless there's a strong argument for using it.

Compiler flags for popular Fortran compilers:

* -std -- Intel (ifort)
* -Mstandard -- Portland (pgf90)
* -ansi -- Sun (f95)

The ISO Fortran standard homepage is here: http://www.nag.co.uk/sc22wg5/

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

GENIE Compiling

2010-03-23T17:53:57Z

Genie-user: /* Mac OSX - March 2010 */

=Apple OSX and g95=

* POWERPC, 1.5GHZ Powerbook
* OSX Tiger 10.4.7, Xcode 2.4

Genie compiles with g95, gcc and g++
* g95 0.90-1 (Fink download)
* gcc 4 (Xcode, probably)
* g++ 4 (Xcode, probably)

=Mac OSX - March 2010=
by Greg Colbourn

* Intel Core 2 Duo, 2.26GHz MacBook Pro
* OSX Snow Leopard 10.6.2, Xcode 3.2.1

1. Download netcdf from http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.0.1.tar.gz

2. Go to unzipped netcdf directory and type following commands:

export FFLAGS="-m32"; export FCFLAGS="-m32"; export CFLAGS="-m32"; export CXXFLAGS="-m32"

./configure --prefix=[your path]/netcdf-4.0.1 FC=/usr/local/bin/gfortran F90=/usr/local/bin/gfortran CC=gcc CXX=g++ CPPFLAGS="-DpgiFortran"

make check

make install

3. In user.mak have:

F77=gfortran
CC=gcc
CXX=g++-4.0
NETCDF_NAME=netcdf

==Need to exclude biogem (code from cvs early October 2006)==

In genie-main makefile
MODULE_NAMES = igcm3 \
slabocean \
slabseaice \
fixedocean \
fixedseaice \
goldstein \
embm \
seaice \
fixedatmos \
land \
fixedland \
fixedicesheet \
fixedchem \
ichem \
atchem
# biogem \
# ichem

genie-main/genie_ini_wrappers.f90: Lines 262+:
! call initialise_biogenie(t0,go_dt,go_lin,go_lout, &
! and all the arguments...

genie-main/genie_loop_wrappers.f90: Lines 676+ and 725:

! call biogenie( &
! and all the arguments...

! call rest_biogem(go_lout,'.'//go_ext)

genie-main/genie.F: Line 1688:

c call end_biogenie(go_sfcatm(:,:,:))

==In order to work with netcdf (v3.6.1 compiled from source with g96, gcc and g++)==
You must compile netcdf with identical compilers to those used for genie. You may need to edit the netcdf configure script to make sure it finds the right compilers. Netcdf binaries downloaded via fin are therefore unlikely to work.

Then in genie-main makefile.arc comment out two flags:
#FFLAGS += -fno-second-underscore
#LDFLAGS += -static

Alternatively, if you can work out how to do it, compile netcdf with -fno-second-underscore. I couldn't fathom where to put that in.

jules@jamstec.go.jp, 30th October 2006.

=Compilation error with NetCDF version 4=
If you are using identical compilers for genie and netcdf, but still get a compilation error message associated with netcdf (e.g. ''This module file was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read''), there may be a compatibility issue with your netcdf version. Switching from NetCDF version 4 (RHES4) to v3.6.1 has bypassed this problem (using Red Hat/ifort/icc), although the reason for this is not known.

k.i.c.oliver@open.ac.uk, 21st November 2006

=Intel Fortran v7.1, INT() and PARAMETER()=

ifcv7.1 will not compile statements of the form:

* PARAMETER (N=INT(..))

Hence they have been removed from genie-land/src/fotran/qsat.f

Gethin Williams Fri Dec 15 16:58:47 GMT 2006

=New line characters in text files (UNIX/Windows)=

===Description of problem===

UNIX uses a linefeed character (as should CVS internally), but Windows uses both carriage-return and linefeed (CR/LF). Some compilers/other tools may have trouble reading or displaying files that have the wrong new line characters for the platform. A symptom of this can be a large number of "odd-looking" compiler errors, and the problem may not be easy to spot because most code editors correctly display both UNIX and Windows new lines. Note that CVS should append the appropriate new line characters for the platform onto which a source file is checked out, but this may not be reliable.

===Suggested solutions===

If your text editor has an option allowing you to change the new line character, edit the option and save the file. UNIX commands are also available to do the job, for example:

* dos2unix -ascii my_source_file.f90 my_source_file.f90
* unix2dos -ascii my_source_file.f90 my_source_file.f90

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

=Standard Fortran compliance=

===Description of problem===

Most compilers allow extensions to the Fortran language, but using these extensions may cause errors when a different (often older) compiler is used. For instance, the only format descriptor that can be used without an explicit width is the character descriptor "A", however many compilers will allow other format descriptors to be used without a width, e.g. "G", to which a default width (and number of characters right of the decimal place) is applied by the compiler.

===Suggested solutions===

The GENIE overnight tests are carried out on several different platforms (Linux, Windows, Solaris) with different compilers. However, it isn't practicable to test every combination of platform and compiler, so when adding significant amounts of new code to GENIE it may be worth testing on more than one compiler/platform if available.

A good check for non-standard Fortran is to compile GENIE with an appropriate compiler option that checks for standards compliance (the compiler option can be added in makefile.arc). In general, it's best to avoid non-standard Fortran unless there's a strong argument for using it.

Compiler flags for popular Fortran compilers:

* -std -- Intel (ifort)
* -Mstandard -- Portland (pgf90)
* -ansi -- Sun (f95)

The ISO Fortran standard homepage is here: http://www.nag.co.uk/sc22wg5/

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

GENIE Compiling

2010-03-23T17:48:38Z

Genie-user: /* Mac OSX March 2010 */

=Apple OSX and g95=

* POWERPC, 1.5GHZ Powerbook
* OSX Tiger 10.4.7, Xcode 2.4

Genie compiles with g95, gcc and g++
* g95 0.90-1 (Fink download)
* gcc 4 (Xcode, probably)
* g++ 4 (Xcode, probably)

=Mac OSX - March 2010=
by Greg Colbourn

* Intel Core 2 Duo, 2.26GHz MacBook Pro
* OSX Snow Leopard 10.6.2, Xcode 3.2.1

1. Download netcdf from http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.0.1.tar.gz

2. Go to unzipped netcdf directory and type following commands:

export FFLAGS="-m32"; export FCFLAGS="-m32"; export CFLAGS="-m32"; export CXXFLAGS="-m32"

./configure --prefix=your path/netcdf-4.0.1 FC=/usr/local/bin/gfortran F90=/usr/local/bin/gfortran CC=gcc CXX=g++ CPPFLAGS="-DpgiFortran"

make

make check

make install

3. In user.mak have:

F77=gfortran
CC=gcc
CXX=g++-4.0
NETCDF_NAME=netcdf

==Need to exclude biogem (code from cvs early October 2006)==

In genie-main makefile
MODULE_NAMES = igcm3 \
slabocean \
slabseaice \
fixedocean \
fixedseaice \
goldstein \
embm \
seaice \
fixedatmos \
land \
fixedland \
fixedicesheet \
fixedchem \
ichem \
atchem
# biogem \
# ichem

genie-main/genie_ini_wrappers.f90: Lines 262+:
! call initialise_biogenie(t0,go_dt,go_lin,go_lout, &
! and all the arguments...

genie-main/genie_loop_wrappers.f90: Lines 676+ and 725:

! call biogenie( &
! and all the arguments...

! call rest_biogem(go_lout,'.'//go_ext)

genie-main/genie.F: Line 1688:

c call end_biogenie(go_sfcatm(:,:,:))

==In order to work with netcdf (v3.6.1 compiled from source with g96, gcc and g++)==
You must compile netcdf with identical compilers to those used for genie. You may need to edit the netcdf configure script to make sure it finds the right compilers. Netcdf binaries downloaded via fin are therefore unlikely to work.

Then in genie-main makefile.arc comment out two flags:
#FFLAGS += -fno-second-underscore
#LDFLAGS += -static

Alternatively, if you can work out how to do it, compile netcdf with -fno-second-underscore. I couldn't fathom where to put that in.

jules@jamstec.go.jp, 30th October 2006.

=Compilation error with NetCDF version 4=
If you are using identical compilers for genie and netcdf, but still get a compilation error message associated with netcdf (e.g. ''This module file was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read''), there may be a compatibility issue with your netcdf version. Switching from NetCDF version 4 (RHES4) to v3.6.1 has bypassed this problem (using Red Hat/ifort/icc), although the reason for this is not known.

k.i.c.oliver@open.ac.uk, 21st November 2006

=Intel Fortran v7.1, INT() and PARAMETER()=

ifcv7.1 will not compile statements of the form:

* PARAMETER (N=INT(..))

Hence they have been removed from genie-land/src/fotran/qsat.f

Gethin Williams Fri Dec 15 16:58:47 GMT 2006

=New line characters in text files (UNIX/Windows)=

===Description of problem===

UNIX uses a linefeed character (as should CVS internally), but Windows uses both carriage-return and linefeed (CR/LF). Some compilers/other tools may have trouble reading or displaying files that have the wrong new line characters for the platform. A symptom of this can be a large number of "odd-looking" compiler errors, and the problem may not be easy to spot because most code editors correctly display both UNIX and Windows new lines. Note that CVS should append the appropriate new line characters for the platform onto which a source file is checked out, but this may not be reliable.

===Suggested solutions===

If your text editor has an option allowing you to change the new line character, edit the option and save the file. UNIX commands are also available to do the job, for example:

* dos2unix -ascii my_source_file.f90 my_source_file.f90
* unix2dos -ascii my_source_file.f90 my_source_file.f90

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

=Standard Fortran compliance=

===Description of problem===

Most compilers allow extensions to the Fortran language, but using these extensions may cause errors when a different (often older) compiler is used. For instance, the only format descriptor that can be used without an explicit width is the character descriptor "A", however many compilers will allow other format descriptors to be used without a width, e.g. "G", to which a default width (and number of characters right of the decimal place) is applied by the compiler.

===Suggested solutions===

The GENIE overnight tests are carried out on several different platforms (Linux, Windows, Solaris) with different compilers. However, it isn't practicable to test every combination of platform and compiler, so when adding significant amounts of new code to GENIE it may be worth testing on more than one compiler/platform if available.

A good check for non-standard Fortran is to compile GENIE with an appropriate compiler option that checks for standards compliance (the compiler option can be added in makefile.arc). In general, it's best to avoid non-standard Fortran unless there's a strong argument for using it.

Compiler flags for popular Fortran compilers:

* -std -- Intel (ifort)
* -Mstandard -- Portland (pgf90)
* -ansi -- Sun (f95)

The ISO Fortran standard homepage is here: http://www.nag.co.uk/sc22wg5/

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

GENIE Compiling

2010-03-23T17:37:15Z

Genie-user: /* Mac OSX March 2010 */

=Apple OSX and g95=

* POWERPC, 1.5GHZ Powerbook
* OSX Tiger 10.4.7, Xcode 2.4

Genie compiles with g95, gcc and g++
* g95 0.90-1 (Fink download)
* gcc 4 (Xcode, probably)
* g++ 4 (Xcode, probably)

=Mac OSX March 2010=

* Intel Core 2 Duo, 2.26GHz MacBook Pro
* OSX Snow Leopard 10.6.2, Xcode 3.2.1

1. Download netcdf from http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.0.1.tar.gz

2. Go to unzipped netcdf directory and type following commands:

export FFLAGS="-m32"; export FCFLAGS="-m32"; export CFLAGS="-m32"; export CXXFLAGS="-m32"

./configure --prefix=your path/netcdf-4.0.1 FC=/usr/local/bin/gfortran F90=/usr/local/bin/gfortran CC=gcc CXX=g++ CPPFLAGS="-DpgiFortran"

make

make check

make install

3. In user.mak have:

F77=gfortran
CC=gcc
CXX=g++-4.0
NETCDF_NAME=netcdf

==Need to exclude biogem (code from cvs early October 2006)==

In genie-main makefile
MODULE_NAMES = igcm3 \
slabocean \
slabseaice \
fixedocean \
fixedseaice \
goldstein \
embm \
seaice \
fixedatmos \
land \
fixedland \
fixedicesheet \
fixedchem \
ichem \
atchem
# biogem \
# ichem

genie-main/genie_ini_wrappers.f90: Lines 262+:
! call initialise_biogenie(t0,go_dt,go_lin,go_lout, &
! and all the arguments...

genie-main/genie_loop_wrappers.f90: Lines 676+ and 725:

! call biogenie( &
! and all the arguments...

! call rest_biogem(go_lout,'.'//go_ext)

genie-main/genie.F: Line 1688:

c call end_biogenie(go_sfcatm(:,:,:))

==In order to work with netcdf (v3.6.1 compiled from source with g96, gcc and g++)==
You must compile netcdf with identical compilers to those used for genie. You may need to edit the netcdf configure script to make sure it finds the right compilers. Netcdf binaries downloaded via fin are therefore unlikely to work.

Then in genie-main makefile.arc comment out two flags:
#FFLAGS += -fno-second-underscore
#LDFLAGS += -static

Alternatively, if you can work out how to do it, compile netcdf with -fno-second-underscore. I couldn't fathom where to put that in.

jules@jamstec.go.jp, 30th October 2006.

=Compilation error with NetCDF version 4=
If you are using identical compilers for genie and netcdf, but still get a compilation error message associated with netcdf (e.g. ''This module file was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read''), there may be a compatibility issue with your netcdf version. Switching from NetCDF version 4 (RHES4) to v3.6.1 has bypassed this problem (using Red Hat/ifort/icc), although the reason for this is not known.

k.i.c.oliver@open.ac.uk, 21st November 2006

=Intel Fortran v7.1, INT() and PARAMETER()=

ifcv7.1 will not compile statements of the form:

* PARAMETER (N=INT(..))

Hence they have been removed from genie-land/src/fotran/qsat.f

Gethin Williams Fri Dec 15 16:58:47 GMT 2006

=New line characters in text files (UNIX/Windows)=

===Description of problem===

UNIX uses a linefeed character (as should CVS internally), but Windows uses both carriage-return and linefeed (CR/LF). Some compilers/other tools may have trouble reading or displaying files that have the wrong new line characters for the platform. A symptom of this can be a large number of "odd-looking" compiler errors, and the problem may not be easy to spot because most code editors correctly display both UNIX and Windows new lines. Note that CVS should append the appropriate new line characters for the platform onto which a source file is checked out, but this may not be reliable.

===Suggested solutions===

If your text editor has an option allowing you to change the new line character, edit the option and save the file. UNIX commands are also available to do the job, for example:

* dos2unix -ascii my_source_file.f90 my_source_file.f90
* unix2dos -ascii my_source_file.f90 my_source_file.f90

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

=Standard Fortran compliance=

===Description of problem===

Most compilers allow extensions to the Fortran language, but using these extensions may cause errors when a different (often older) compiler is used. For instance, the only format descriptor that can be used without an explicit width is the character descriptor "A", however many compilers will allow other format descriptors to be used without a width, e.g. "G", to which a default width (and number of characters right of the decimal place) is applied by the compiler.

===Suggested solutions===

The GENIE overnight tests are carried out on several different platforms (Linux, Windows, Solaris) with different compilers. However, it isn't practicable to test every combination of platform and compiler, so when adding significant amounts of new code to GENIE it may be worth testing on more than one compiler/platform if available.

A good check for non-standard Fortran is to compile GENIE with an appropriate compiler option that checks for standards compliance (the compiler option can be added in makefile.arc). In general, it's best to avoid non-standard Fortran unless there's a strong argument for using it.

Compiler flags for popular Fortran compilers:

* -std -- Intel (ifort)
* -Mstandard -- Portland (pgf90)
* -ansi -- Sun (f95)

The ISO Fortran standard homepage is here: http://www.nag.co.uk/sc22wg5/

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

GENIE Compiling

2010-03-23T17:37:02Z

Genie-user: /* Mac OSX March 2010 */

=Apple OSX and g95=

* POWERPC, 1.5GHZ Powerbook
* OSX Tiger 10.4.7, Xcode 2.4

Genie compiles with g95, gcc and g++
* g95 0.90-1 (Fink download)
* gcc 4 (Xcode, probably)
* g++ 4 (Xcode, probably)

=Mac OSX March 2010=

* Intel Core 2 Duo, 2.26GHz MacBook Pro
* OSX Snow Leopard 10.6.2, Xcode 3.2.1

1. Download netcdf from http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.0.1.tar.gz

2. Go to unzipped netcdf directory and type following commands:
export FFLAGS="-m32"; export FCFLAGS="-m32"; export CFLAGS="-m32"; export CXXFLAGS="-m32"

./configure --prefix=your path/netcdf-4.0.1 FC=/usr/local/bin/gfortran F90=/usr/local/bin/gfortran CC=gcc CXX=g++ CPPFLAGS="-DpgiFortran"

make
make check
make install

3. In user.mak have:
F77=gfortran
CC=gcc
CXX=g++-4.0
NETCDF_NAME=netcdf

==Need to exclude biogem (code from cvs early October 2006)==

In genie-main makefile
MODULE_NAMES = igcm3 \
slabocean \
slabseaice \
fixedocean \
fixedseaice \
goldstein \
embm \
seaice \
fixedatmos \
land \
fixedland \
fixedicesheet \
fixedchem \
ichem \
atchem
# biogem \
# ichem

genie-main/genie_ini_wrappers.f90: Lines 262+:
! call initialise_biogenie(t0,go_dt,go_lin,go_lout, &
! and all the arguments...

genie-main/genie_loop_wrappers.f90: Lines 676+ and 725:

! call biogenie( &
! and all the arguments...

! call rest_biogem(go_lout,'.'//go_ext)

genie-main/genie.F: Line 1688:

c call end_biogenie(go_sfcatm(:,:,:))

==In order to work with netcdf (v3.6.1 compiled from source with g96, gcc and g++)==
You must compile netcdf with identical compilers to those used for genie. You may need to edit the netcdf configure script to make sure it finds the right compilers. Netcdf binaries downloaded via fin are therefore unlikely to work.

Then in genie-main makefile.arc comment out two flags:
#FFLAGS += -fno-second-underscore
#LDFLAGS += -static

Alternatively, if you can work out how to do it, compile netcdf with -fno-second-underscore. I couldn't fathom where to put that in.

jules@jamstec.go.jp, 30th October 2006.

=Compilation error with NetCDF version 4=
If you are using identical compilers for genie and netcdf, but still get a compilation error message associated with netcdf (e.g. ''This module file was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read''), there may be a compatibility issue with your netcdf version. Switching from NetCDF version 4 (RHES4) to v3.6.1 has bypassed this problem (using Red Hat/ifort/icc), although the reason for this is not known.

k.i.c.oliver@open.ac.uk, 21st November 2006

=Intel Fortran v7.1, INT() and PARAMETER()=

ifcv7.1 will not compile statements of the form:

* PARAMETER (N=INT(..))

Hence they have been removed from genie-land/src/fotran/qsat.f

Gethin Williams Fri Dec 15 16:58:47 GMT 2006

=New line characters in text files (UNIX/Windows)=

===Description of problem===

UNIX uses a linefeed character (as should CVS internally), but Windows uses both carriage-return and linefeed (CR/LF). Some compilers/other tools may have trouble reading or displaying files that have the wrong new line characters for the platform. A symptom of this can be a large number of "odd-looking" compiler errors, and the problem may not be easy to spot because most code editors correctly display both UNIX and Windows new lines. Note that CVS should append the appropriate new line characters for the platform onto which a source file is checked out, but this may not be reliable.

===Suggested solutions===

If your text editor has an option allowing you to change the new line character, edit the option and save the file. UNIX commands are also available to do the job, for example:

* dos2unix -ascii my_source_file.f90 my_source_file.f90
* unix2dos -ascii my_source_file.f90 my_source_file.f90

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

=Standard Fortran compliance=

===Description of problem===

Most compilers allow extensions to the Fortran language, but using these extensions may cause errors when a different (often older) compiler is used. For instance, the only format descriptor that can be used without an explicit width is the character descriptor "A", however many compilers will allow other format descriptors to be used without a width, e.g. "G", to which a default width (and number of characters right of the decimal place) is applied by the compiler.

===Suggested solutions===

The GENIE overnight tests are carried out on several different platforms (Linux, Windows, Solaris) with different compilers. However, it isn't practicable to test every combination of platform and compiler, so when adding significant amounts of new code to GENIE it may be worth testing on more than one compiler/platform if available.

A good check for non-standard Fortran is to compile GENIE with an appropriate compiler option that checks for standards compliance (the compiler option can be added in makefile.arc). In general, it's best to avoid non-standard Fortran unless there's a strong argument for using it.

Compiler flags for popular Fortran compilers:

* -std -- Intel (ifort)
* -Mstandard -- Portland (pgf90)
* -ansi -- Sun (f95)

The ISO Fortran standard homepage is here: http://www.nag.co.uk/sc22wg5/

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

GENIE Compiling

2010-03-23T17:36:37Z

Genie-user: /* Mac OSX March 2010 */

=Apple OSX and g95=

* POWERPC, 1.5GHZ Powerbook
* OSX Tiger 10.4.7, Xcode 2.4

Genie compiles with g95, gcc and g++
* g95 0.90-1 (Fink download)
* gcc 4 (Xcode, probably)
* g++ 4 (Xcode, probably)

=Mac OSX March 2010=

* Intel Core 2 Duo, 2.26GHz MacBook Pro
* OSX Snow Leopard 10.6.2, Xcode 3.2.1

1. Download netcdf from http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.0.1.tar.gz

2. Go to unzipped netcdf directory and type following commands:
export FFLAGS="-m32"; export FCFLAGS="-m32"; export CFLAGS="-m32"; export CXXFLAGS="-m32"
./configure --prefix=your path/netcdf-4.0.1 FC=/usr/local/bin/gfortran F90=/usr/local/bin/gfortran CC=gcc CXX=g++ CPPFLAGS="-DpgiFortran"
make
make check
make install

3. In user.mak have:
F77=gfortran
CC=gcc
CXX=g++-4.0
NETCDF_NAME=netcdf

==Need to exclude biogem (code from cvs early October 2006)==

In genie-main makefile
MODULE_NAMES = igcm3 \
slabocean \
slabseaice \
fixedocean \
fixedseaice \
goldstein \
embm \
seaice \
fixedatmos \
land \
fixedland \
fixedicesheet \
fixedchem \
ichem \
atchem
# biogem \
# ichem

genie-main/genie_ini_wrappers.f90: Lines 262+:
! call initialise_biogenie(t0,go_dt,go_lin,go_lout, &
! and all the arguments...

genie-main/genie_loop_wrappers.f90: Lines 676+ and 725:

! call biogenie( &
! and all the arguments...

! call rest_biogem(go_lout,'.'//go_ext)

genie-main/genie.F: Line 1688:

c call end_biogenie(go_sfcatm(:,:,:))

==In order to work with netcdf (v3.6.1 compiled from source with g96, gcc and g++)==
You must compile netcdf with identical compilers to those used for genie. You may need to edit the netcdf configure script to make sure it finds the right compilers. Netcdf binaries downloaded via fin are therefore unlikely to work.

Then in genie-main makefile.arc comment out two flags:
#FFLAGS += -fno-second-underscore
#LDFLAGS += -static

Alternatively, if you can work out how to do it, compile netcdf with -fno-second-underscore. I couldn't fathom where to put that in.

jules@jamstec.go.jp, 30th October 2006.

=Compilation error with NetCDF version 4=
If you are using identical compilers for genie and netcdf, but still get a compilation error message associated with netcdf (e.g. ''This module file was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read''), there may be a compatibility issue with your netcdf version. Switching from NetCDF version 4 (RHES4) to v3.6.1 has bypassed this problem (using Red Hat/ifort/icc), although the reason for this is not known.

k.i.c.oliver@open.ac.uk, 21st November 2006

=Intel Fortran v7.1, INT() and PARAMETER()=

ifcv7.1 will not compile statements of the form:

* PARAMETER (N=INT(..))

Hence they have been removed from genie-land/src/fotran/qsat.f

Gethin Williams Fri Dec 15 16:58:47 GMT 2006

=New line characters in text files (UNIX/Windows)=

===Description of problem===

UNIX uses a linefeed character (as should CVS internally), but Windows uses both carriage-return and linefeed (CR/LF). Some compilers/other tools may have trouble reading or displaying files that have the wrong new line characters for the platform. A symptom of this can be a large number of "odd-looking" compiler errors, and the problem may not be easy to spot because most code editors correctly display both UNIX and Windows new lines. Note that CVS should append the appropriate new line characters for the platform onto which a source file is checked out, but this may not be reliable.

===Suggested solutions===

If your text editor has an option allowing you to change the new line character, edit the option and save the file. UNIX commands are also available to do the job, for example:

* dos2unix -ascii my_source_file.f90 my_source_file.f90
* unix2dos -ascii my_source_file.f90 my_source_file.f90

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

=Standard Fortran compliance=

===Description of problem===

Most compilers allow extensions to the Fortran language, but using these extensions may cause errors when a different (often older) compiler is used. For instance, the only format descriptor that can be used without an explicit width is the character descriptor "A", however many compilers will allow other format descriptors to be used without a width, e.g. "G", to which a default width (and number of characters right of the decimal place) is applied by the compiler.

===Suggested solutions===

The GENIE overnight tests are carried out on several different platforms (Linux, Windows, Solaris) with different compilers. However, it isn't practicable to test every combination of platform and compiler, so when adding significant amounts of new code to GENIE it may be worth testing on more than one compiler/platform if available.

A good check for non-standard Fortran is to compile GENIE with an appropriate compiler option that checks for standards compliance (the compiler option can be added in makefile.arc). In general, it's best to avoid non-standard Fortran unless there's a strong argument for using it.

Compiler flags for popular Fortran compilers:

* -std -- Intel (ifort)
* -Mstandard -- Portland (pgf90)
* -ansi -- Sun (f95)

The ISO Fortran standard homepage is here: http://www.nag.co.uk/sc22wg5/

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

GENIE Compiling

2010-03-23T17:36:00Z

Genie-user: /* Apple OSX March 2010 */

=Apple OSX and g95=

* POWERPC, 1.5GHZ Powerbook
* OSX Tiger 10.4.7, Xcode 2.4

Genie compiles with g95, gcc and g++
* g95 0.90-1 (Fink download)
* gcc 4 (Xcode, probably)
* g++ 4 (Xcode, probably)

=Mac OSX March 2010=

* Intel Core 2 Duo, 2.26GHz MacBook Pro
* OSX Snow Leopard 10.6.2, Xcode 3.2.1

1. Download netcdf from http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.0.1.tar.gz
2. Go to unzipped netcdf directory and type following commands:
export FFLAGS="-m32"; export FCFLAGS="-m32"; export CFLAGS="-m32"; export CXXFLAGS="-m32"
./configure --prefix=your path/netcdf-4.0.1 FC=/usr/local/bin/gfortran F90=/usr/local/bin/gfortran CC=gcc CXX=g++ CPPFLAGS="-DpgiFortran"
make
make check
make install
3. In user.mak have:
F77=gfortran
CC=gcc
CXX=g++-4.0
NETCDF_NAME=netcdf

==Need to exclude biogem (code from cvs early October 2006)==

In genie-main makefile
MODULE_NAMES = igcm3 \
slabocean \
slabseaice \
fixedocean \
fixedseaice \
goldstein \
embm \
seaice \
fixedatmos \
land \
fixedland \
fixedicesheet \
fixedchem \
ichem \
atchem
# biogem \
# ichem

genie-main/genie_ini_wrappers.f90: Lines 262+:
! call initialise_biogenie(t0,go_dt,go_lin,go_lout, &
! and all the arguments...

genie-main/genie_loop_wrappers.f90: Lines 676+ and 725:

! call biogenie( &
! and all the arguments...

! call rest_biogem(go_lout,'.'//go_ext)

genie-main/genie.F: Line 1688:

c call end_biogenie(go_sfcatm(:,:,:))

==In order to work with netcdf (v3.6.1 compiled from source with g96, gcc and g++)==
You must compile netcdf with identical compilers to those used for genie. You may need to edit the netcdf configure script to make sure it finds the right compilers. Netcdf binaries downloaded via fin are therefore unlikely to work.

Then in genie-main makefile.arc comment out two flags:
#FFLAGS += -fno-second-underscore
#LDFLAGS += -static

Alternatively, if you can work out how to do it, compile netcdf with -fno-second-underscore. I couldn't fathom where to put that in.

jules@jamstec.go.jp, 30th October 2006.

=Compilation error with NetCDF version 4=
If you are using identical compilers for genie and netcdf, but still get a compilation error message associated with netcdf (e.g. ''This module file was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read''), there may be a compatibility issue with your netcdf version. Switching from NetCDF version 4 (RHES4) to v3.6.1 has bypassed this problem (using Red Hat/ifort/icc), although the reason for this is not known.

k.i.c.oliver@open.ac.uk, 21st November 2006

=Intel Fortran v7.1, INT() and PARAMETER()=

ifcv7.1 will not compile statements of the form:

* PARAMETER (N=INT(..))

Hence they have been removed from genie-land/src/fotran/qsat.f

Gethin Williams Fri Dec 15 16:58:47 GMT 2006

=New line characters in text files (UNIX/Windows)=

===Description of problem===

UNIX uses a linefeed character (as should CVS internally), but Windows uses both carriage-return and linefeed (CR/LF). Some compilers/other tools may have trouble reading or displaying files that have the wrong new line characters for the platform. A symptom of this can be a large number of "odd-looking" compiler errors, and the problem may not be easy to spot because most code editors correctly display both UNIX and Windows new lines. Note that CVS should append the appropriate new line characters for the platform onto which a source file is checked out, but this may not be reliable.

===Suggested solutions===

If your text editor has an option allowing you to change the new line character, edit the option and save the file. UNIX commands are also available to do the job, for example:

* dos2unix -ascii my_source_file.f90 my_source_file.f90
* unix2dos -ascii my_source_file.f90 my_source_file.f90

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

=Standard Fortran compliance=

===Description of problem===

Most compilers allow extensions to the Fortran language, but using these extensions may cause errors when a different (often older) compiler is used. For instance, the only format descriptor that can be used without an explicit width is the character descriptor "A", however many compilers will allow other format descriptors to be used without a width, e.g. "G", to which a default width (and number of characters right of the decimal place) is applied by the compiler.

===Suggested solutions===

The GENIE overnight tests are carried out on several different platforms (Linux, Windows, Solaris) with different compilers. However, it isn't practicable to test every combination of platform and compiler, so when adding significant amounts of new code to GENIE it may be worth testing on more than one compiler/platform if available.

A good check for non-standard Fortran is to compile GENIE with an appropriate compiler option that checks for standards compliance (the compiler option can be added in makefile.arc). In general, it's best to avoid non-standard Fortran unless there's a strong argument for using it.

Compiler flags for popular Fortran compilers:

* -std -- Intel (ifort)
* -Mstandard -- Portland (pgf90)
* -ansi -- Sun (f95)

The ISO Fortran standard homepage is here: http://www.nag.co.uk/sc22wg5/

Ian Henderson Fri Jan 12 15:49:57 GMT 2007

GENIE experiments

2010-03-23T09:30:53Z

Genie-user: /* Howto */

This page introduces a new way to configure and run traceable (i.e. reproduceable) GENIE experiments. We hope that this new method of approaching the organisation of GENIE files will make more sense to new users too.

[[#creating_and_configuring_GENIE_experiments|ENOUGH WITH THE BLATHER! Just show me how to built an experiment]]

== The old way ==

By convention, the normal place for GENIE to output data is a directory outside of the genie source tree, normally at the same level as the top-level genie directory, called genie_output. When an experiment with experiment id 'my_experiment' is compiled and run using the confusingly named genie_example.job script (which is traditionally used to compile and run all GENIE model runs), a directory genie_output/my_experiment is made, and directories made within it for each GENIE component model (e.g. embm) to write data into.

So far, this is all very sensible, but then things get a bit confusing. The genie_example.job script generates namelist files of runtime parameters from the xml config file (or goin files in the soon-to-be-deprecated old way of specifying model configuration). These are used by the compiled executable so that it knows what configuration settings to run the model with (i.e. the details of the experiment you're doing, where to find input files, where to write output, whether or not do do x, or y etc). These namelist files (e.g. data_EMBM) and the executable are copied into genie_output/my_experiment and then the model is run from within the my_experiment directory. So, the my_experiment directory is more than just genie_output - it's in fact most of what you need to run the experiment. With the exception of a bunch of input files (topography, forcings etc), which are generally found within the source tree of the model, the location and details of which are specified in the config file, everything you need to run the experiment without the presence of the genie source tree is contained within my_experiment, along with the output data produced by the model.

There's nothing at all insensible about most of this - having the compiled model executable and namelist parameters along with the model output is good for traceability (in theory, if nothing in the source tree has been changed since you ran the experiment, you should be able to navigate to genie_output/my_experiment and launch genie.exe, and exactly reproduce your previous results. In practice, it's rarely that simple and there are some things we can do to improve traceability; but the main problem with the above is the misleading name of the genie_output folder and the difficulty of having it outside the source tree. Therefore we have made a new directory in the genie tree, called genie-experiments, from which experiments can be configured, built and run with relative ease and better traceability.

== GENIE experiments ==

The motivation behind the changes outlined here is to i) make GENIE easier to configure and run for new users by making it more obvious what's what and ii) to facilitate the creation of full traceable and portable (i.e. source-tree-independent) compiled experiments, which can be run manually (i.e. by executing genie.exe) or through a front end (e.g. the [[GENIE_ALADDIN2|ALADDIN launchpad]]). Thus we have come up with the following specification for the structure and content of a GENIE experiment directory, which is portable and traceable. It is as follows

<pre>
my_experiment/ // the experiment directory, by default written to genie/genie-experiments
|
|-aladdin/ // this directory not strictly part of the specification, but essential to an
| | // experiment's use with the [[GENIE_ALADDIN2|ALADDIN launchpad]].
| |-graphVarData.xml
| |-mapVarData.xml // see [[GENIE_ALADDIN2_varData_files]]
|
|-archive/ // directory containing information necessary to reproduce the experiment at a later date
| |-definition.xml // definition.xml containing the default values of all model parameters / settings
| |-my_experiment.xml // the user-defined experiment config used to generate the experiment
| |-svn.info // the result of doing svn info > svn.info in the top=level genie directory
| |-svn.diff // svn diff > svn.diff*
| |-genie_example.job
| |-genie_gridsizes.txt
| |-makefile.arc
|
|-<module_name>/ // e.g. 'embm' - directory for each component model containing output data (unchanged from
| // old genie_output directories). Can be empty if experiment compiled but not run
|
|-input/ // input directory contains model inputs for each component and mirrors directory structure
| | // of genie source tree to location of input files. i.e.:
| |-genie-<module_name>/
| |-data/
| |-input/
| |-<input files>
|
|-data_<MODULE_NAME> // e.g. data_EMBM, data_genie. Namelist files for experiment config
| // (unchanged from the old genie_output approach) as
|
|-genie.exe // compiled genie exectuable
|
|-genie_wrapper.sh // genie wrapper which logs output to ./genie.out and contains controls for ALADDIN2
// (not essential to the specification of a genie-experiment, but useful)
</pre>

<code>*</code> the commands svn info and svn diff together in theory allow the recreation of any particular state of the genie source tree, whether a committed version or one containing user-changed code which wasn't in the repository at the time of doing the experiment. In practice, it would be silly to take GENIE into battle without using a fully-committed-to-svn version of the model, otherwise getting back to the same state in the future could be extremely difficult and messy even with the help of svn info and svn diff. If you're working with the GENIE trunk and not doing your own development work, it would be advisable to use a tuned tagged release of the model, which is set in stone and can always be reproduced.

== Creating and configuring GENIE experiments ==

It is assumed that you're adopting our proposed new genie/genie-experiments directory as the location for creating your compiled experiments (if not, you should be able to work out what needs changing in the details below, but don't come running to us when it all goes wrong...).

=== Summary ===

in genie/genie-experiments directory:

<pre>
./build_experiment -f files/<file list> -c configs/<config file> (-m <mavVarData file> -g<graphVarData file> -n)
</pre>

The optional -n command-line argument will create an experiment without recompiling the model.
The optional mapVarData and graphVarData files are specific to ALADDIN, where they are used to interpret ascii output files to extract parameters to be visualised in ALADDIN during the experiment. See [[GENIE_ALADDIN2_varData_files]]

=== Howto ===

You will need:

# a working version of the genie source code and its prerequisites
# an experiment you want to build - i.e. an xml config file with your parameters of interest set to the values you want (note if you're doing this for ALADDIN you may wish to 'expose' them for user-configuration and set a range of available values - see the [[GENIE_ALADDIN_DOCS|ALADDIN documentation]]).
# knowledge of which data input files the experiment you want to do requires (see below).
# a terminal to run commands on
# a text editor

You will also need to make sure the OUTROOT and RUNTIME_ROOT environment variables are set correctly in user.sh:

<pre>
CODEDIR =/path/to/genie // ~/genie by default
OUTROOT =${CODEDIR}/genie-experiments
RUNTIME_ROOT = ${RUNTIME_ROOT:=../..}
</pre>

and also OUT_DIR and RUNTIME_ROOT in user.mak:

<pre>
GENIE_ROOT = /path/to/genie
OUT_DIR = $(GENIE_ROOT)/genie-experiments
RUNTIME_ROOT = ../..
</pre>

==== File lists ====

Now, because we are creating a standalone experiment, we need to make sure that (i) all the necessary input files (topography, restart files, tracer initialisations, forcings etc) are in the correct places within the genie experiment structure (see specification) and (ii) that your xml config file is pointing GENIE to the correct place to look for them.

The first part of this is non-trivial - as well as knowing how many files of what type are required for a particular run/ setup, you also need to know which of a selection of files are most appropriate. This isn't obvious, or documented anywhere at the moment, but I hope in the future [[GENIE_input_files]] might contain what you need to know. For now, a good starting point is to look around in the genie/genie-<module-name>/data/input directories and see what you can see. Also trial and error works OK - GENIE is pretty good at telling you when it's missing a file and the correct files can be diagnosed from this.

To make life easier, there are a number of file lists provided for 'standard' model setups in genie-experiments/files. If you need to make a new one for a particular config / model setup, we'd be grateful if you'd add a filelist with a self-explanatory filename into the files directory and document it in [[GENIE_input_files]] if appropriate.

These filelists must contain soleley a list of files required and all of the files must be situated within the genie source tree, preferably in their default locations, so that minimum changes are required to experiment config file to point GENIE to the correct place in the experiment directory when these files have been copied across by build_experiment.sh.

e.g. a filelist for a standard 8 level eb_go_gs_el run might look like this:

<pre>
genie-embm/data/input/worbe2.k1
genie-embm/data/input/taux_u.interp
genie-embm/data/input/taux_v.interp
genie-embm/data/input/tauy_u.interp
genie-embm/data/input/tauy_v.interp
genie-embm/data/input/uncep.silo
genie-embm/data/input/vncep.silo
genie-embm/data/input/ta_ncep.silo
genie-embm/data/input/qa_ncep.silo
genie-goldstein/data/input/worbe2.k1
genie-goldstein/data/input/worbe2.psiles
genie-goldstein/data/input/worbe2.paths
genie-goldstein/data/input/tempann.silo
genie-goldstein/data/input/saliann.silo
genie-goldsteinseaice/data/input/worbe2.k1
genie-ents/data/k_constants.dat
genie-ents/config/ents_config.par
genie-ents/data/atm_albedo_monthly.dat
genie-ents/data/uvic_windx.silo
genie-ents/data/uvic_windy.silo
genie-ents/data/monthly_windspd.silo
genie-ents/data/inv_linterp_matrix.dat
genie-ents/data/orography.dat
genie-ents/data/icemask.dat
genie-ents/config/sealevel_config.par
</pre>

==== input (and output) directory information in my_experiment.xml ====

In definitions.xml, the default settings for genie, which are overridden by those specified in your experiment config file, default directory locations are specified, e.g. for the EMBM:

<pre>
<param name="indir_name">
<value datatype="string"><varref>RUNTIME_ROOT</varref><sep/>genie-embm<sep/>data<sep/>input</value>
</param>

<param name="rstdir_name">
<value datatype="string"><varref>RUNTIME_ROOT</varref><sep/>genie-embm<sep/>data<sep/>input</value>
<description>restart (input) directory</description>
</param>

<param name="outdir_name">
<value datatype="string"><varref>RUNTIME_OUTDIR</varref><sep/>embm</value>
</param>

</pre>

Note that the output directory for EMBM is already set correctly to meet with the specification of a GENIE experiment. However, it could be simplified by replacing '<varref>RUNTIME_OUTDIR</varref>' with '.' as genie.exe is executed from within the experiment directory.

The input directories however have to be changed to point at the input directory of the experiment directory. Therefore, in the embm section of your config file, you will need to override the default values:

<pre>
<param name="indir_name">.<sep/>input<sep/>genie-embm<sep/>data<sep/>input</param>
<param name="rstdir_name">.<sep/>input<sep/>genie-embm<sep/>data<sep/>input</param>
</pre>

=== build_experiment.sh ===

The build_experiment.sh script does the following:

# creates an experiment directory within genie-experiments and input and aladdin subdirectories
# copies user-specified (by -m and -g) or default mapVarData and graphVarData files to the ALADDIN directory
# copies input files specified in the file list (as <path-to-file>) from genie/<path-to-file> to my_experiment/input/<path-to-file>
# copies genie_wrapper.sh to my_experiment
# copies config file to genie-main/configs
# changes directory to genie-main and runs make cleanall (unless -n option specified)
# executes genie_example.job -f <configfile> -x which does most of the work

note that the -x command-line argument to genie_example.job supresses the execution of the model i.e. compilation and file copying to experiment directory only.

Your GENIE experiment can now be moved to anywhere and run from there (by ./genie_wrapper.sh for logged output or ./genie.exe for command-line output) or used with ALADDIN, independent from the genie source tree. Yay!

GENIE ALADDIN2

2010-03-23T09:21:59Z

Genie-user: /* Get ALADDIN */

=ALADDIN: the GENIE launchpad=

ALADDIN has been developed as part of the [[http://engage.ac.uk/ ENGAGE]] programme, in collaboration with the Open Middleware Infrastructure Institute [[http://omii.ac.uk OMII]].

==Get ALADDIN==
Aladdin2 is available in the GENIE trunk since release 2-6-0 or thereabouts. It can be found in genie-gui/package where you can execute <pre>java -jar GenieGUI.jar</pre>

==What ALADDIN can do==
The ALADDIN launchpad is designed as a means to run [[GENIE_experiments|GENIE experiments]] through a graphical user interface (GUI). It requires an experiment directory with a compiled instance of the model, which may or may not have parameters exposed (through the xml config file). While the model is running it will provide real-time visualisation of key 2d and 3d parameters on a graph and a globe. When directed to an ALADDIN run directory (the output from a particular run of a GENIE experiment - normally found as a subdirectory of the experiment directory) it will re-plot the data from the run for the purposes of simple visualisation of old runs. For compley data visualisation an application such as MatLab is recommended.

For more information, see the [[GENIE_ALADDIN_DOCS| ALADDIN Documentation]]

==Where we'd like to go with ALADDIN==
Currently, ALADDIN works as standalone tool for running GENIE from a pre-compiled experiment directory, and as such is well suited for teaching and outreach purposes. In the future ALADDIN will also be able to fully configure, compile and launch GENIE, working with a copy of the GENIE source tree. It will read and plot sensible NetCDF output (it currently only works with ascii output files. It will be able to configure and launch mulitple instances of GENIE on remote computing resources such as the national grid service, or produce genie experiment directories ready to be copied to your local HPC resource and launched through the queueing system of your (or more likely your sysadmins) choice.

GENIE experiments

2010-03-23T09:20:15Z

Genie-user:

This page introduces a new way to configure and run traceable (i.e. reproduceable) GENIE experiments. We hope that this new method of approaching the organisation of GENIE files will make more sense to new users too.

[[#creating_and_configuring_GENIE_experiments|ENOUGH WITH THE BLATHER! Just show me how to built an experiment]]

== The old way ==

By convention, the normal place for GENIE to output data is a directory outside of the genie source tree, normally at the same level as the top-level genie directory, called genie_output. When an experiment with experiment id 'my_experiment' is compiled and run using the confusingly named genie_example.job script (which is traditionally used to compile and run all GENIE model runs), a directory genie_output/my_experiment is made, and directories made within it for each GENIE component model (e.g. embm) to write data into.

So far, this is all very sensible, but then things get a bit confusing. The genie_example.job script generates namelist files of runtime parameters from the xml config file (or goin files in the soon-to-be-deprecated old way of specifying model configuration). These are used by the compiled executable so that it knows what configuration settings to run the model with (i.e. the details of the experiment you're doing, where to find input files, where to write output, whether or not do do x, or y etc). These namelist files (e.g. data_EMBM) and the executable are copied into genie_output/my_experiment and then the model is run from within the my_experiment directory. So, the my_experiment directory is more than just genie_output - it's in fact most of what you need to run the experiment. With the exception of a bunch of input files (topography, forcings etc), which are generally found within the source tree of the model, the location and details of which are specified in the config file, everything you need to run the experiment without the presence of the genie source tree is contained within my_experiment, along with the output data produced by the model.

There's nothing at all insensible about most of this - having the compiled model executable and namelist parameters along with the model output is good for traceability (in theory, if nothing in the source tree has been changed since you ran the experiment, you should be able to navigate to genie_output/my_experiment and launch genie.exe, and exactly reproduce your previous results. In practice, it's rarely that simple and there are some things we can do to improve traceability; but the main problem with the above is the misleading name of the genie_output folder and the difficulty of having it outside the source tree. Therefore we have made a new directory in the genie tree, called genie-experiments, from which experiments can be configured, built and run with relative ease and better traceability.

== GENIE experiments ==

The motivation behind the changes outlined here is to i) make GENIE easier to configure and run for new users by making it more obvious what's what and ii) to facilitate the creation of full traceable and portable (i.e. source-tree-independent) compiled experiments, which can be run manually (i.e. by executing genie.exe) or through a front end (e.g. the [[GENIE_ALADDIN2|ALADDIN launchpad]]). Thus we have come up with the following specification for the structure and content of a GENIE experiment directory, which is portable and traceable. It is as follows

<pre>
my_experiment/ // the experiment directory, by default written to genie/genie-experiments
|
|-aladdin/ // this directory not strictly part of the specification, but essential to an
| | // experiment's use with the [[GENIE_ALADDIN2|ALADDIN launchpad]].
| |-graphVarData.xml
| |-mapVarData.xml // see [[GENIE_ALADDIN2_varData_files]]
|
|-archive/ // directory containing information necessary to reproduce the experiment at a later date
| |-definition.xml // definition.xml containing the default values of all model parameters / settings
| |-my_experiment.xml // the user-defined experiment config used to generate the experiment
| |-svn.info // the result of doing svn info > svn.info in the top=level genie directory
| |-svn.diff // svn diff > svn.diff*
| |-genie_example.job
| |-genie_gridsizes.txt
| |-makefile.arc
|
|-<module_name>/ // e.g. 'embm' - directory for each component model containing output data (unchanged from
| // old genie_output directories). Can be empty if experiment compiled but not run
|
|-input/ // input directory contains model inputs for each component and mirrors directory structure
| | // of genie source tree to location of input files. i.e.:
| |-genie-<module_name>/
| |-data/
| |-input/
| |-<input files>
|
|-data_<MODULE_NAME> // e.g. data_EMBM, data_genie. Namelist files for experiment config
| // (unchanged from the old genie_output approach) as
|
|-genie.exe // compiled genie exectuable
|
|-genie_wrapper.sh // genie wrapper which logs output to ./genie.out and contains controls for ALADDIN2
// (not essential to the specification of a genie-experiment, but useful)
</pre>

<code>*</code> the commands svn info and svn diff together in theory allow the recreation of any particular state of the genie source tree, whether a committed version or one containing user-changed code which wasn't in the repository at the time of doing the experiment. In practice, it would be silly to take GENIE into battle without using a fully-committed-to-svn version of the model, otherwise getting back to the same state in the future could be extremely difficult and messy even with the help of svn info and svn diff. If you're working with the GENIE trunk and not doing your own development work, it would be advisable to use a tuned tagged release of the model, which is set in stone and can always be reproduced.

== Creating and configuring GENIE experiments ==

It is assumed that you're adopting our proposed new genie/genie-experiments directory as the location for creating your compiled experiments (if not, you should be able to work out what needs changing in the details below, but don't come running to us when it all goes wrong...).

=== Summary ===

in genie/genie-experiments directory:

<pre>
./build_experiment -f files/<file list> -c configs/<config file> (-m <mavVarData file> -g<graphVarData file> -n)
</pre>

The optional -n command-line argument will create an experiment without recompiling the model.
The optional mapVarData and graphVarData files are specific to ALADDIN, where they are used to interpret ascii output files to extract parameters to be visualised in ALADDIN during the experiment. See [[GENIE_ALADDIN2_varData_files]]

=== Howto ===

You will need:

# a working version of the genie source code and its prerequisites
# an experiment you want to build - i.e. an xml config file with your parameters of interest set to the values you want (note if you're doing this for ALADDIN you may wish to 'expose' them for user-configuration and set a range of available values - see the [[GENIE_ALADDIN_DOCS|ALADDIN documentation]]).
# knowledge of which data input files the experiment you want to do requires (see below).
# a terminal to run commands on
# a text editor

You will also need to make sure the OUTROOT environment variable is set correctly in user.sh:

<pre>
CODEDIR=/path/to/genie // ~/genie by default
OUTROOT=${CODEDIR}/genie-experiments
</pre>

and OUT_DIR in user.mak:

<pre>
GENIE_ROOT = /path/to/genie
OUT_DIR = $(GENIE_ROOT)/genie-experiments
</pre>

==== File lists ====

Now, because we are creating a standalone experiment, we need to make sure that (i) all the necessary input files (topography, restart files, tracer initialisations, forcings etc) are in the correct places within the genie experiment structure (see specification) and (ii) that your xml config file is pointing GENIE to the correct place to look for them.

The first part of this is non-trivial - as well as knowing how many files of what type are required for a particular run/ setup, you also need to know which of a selection of files are most appropriate. This isn't obvious, or documented anywhere at the moment, but I hope in the future [[GENIE_input_files]] might contain what you need to know. For now, a good starting point is to look around in the genie/genie-<module-name>/data/input directories and see what you can see. Also trial and error works OK - GENIE is pretty good at telling you when it's missing a file and the correct files can be diagnosed from this.

To make life easier, there are a number of file lists provided for 'standard' model setups in genie-experiments/files. If you need to make a new one for a particular config / model setup, we'd be grateful if you'd add a filelist with a self-explanatory filename into the files directory and document it in [[GENIE_input_files]] if appropriate.

These filelists must contain soleley a list of files required and all of the files must be situated within the genie source tree, preferably in their default locations, so that minimum changes are required to experiment config file to point GENIE to the correct place in the experiment directory when these files have been copied across by build_experiment.sh.

e.g. a filelist for a standard 8 level eb_go_gs_el run might look like this:

<pre>
genie-embm/data/input/worbe2.k1
genie-embm/data/input/taux_u.interp
genie-embm/data/input/taux_v.interp
genie-embm/data/input/tauy_u.interp
genie-embm/data/input/tauy_v.interp
genie-embm/data/input/uncep.silo
genie-embm/data/input/vncep.silo
genie-embm/data/input/ta_ncep.silo
genie-embm/data/input/qa_ncep.silo
genie-goldstein/data/input/worbe2.k1
genie-goldstein/data/input/worbe2.psiles
genie-goldstein/data/input/worbe2.paths
genie-goldstein/data/input/tempann.silo
genie-goldstein/data/input/saliann.silo
genie-goldsteinseaice/data/input/worbe2.k1
genie-ents/data/k_constants.dat
genie-ents/config/ents_config.par
genie-ents/data/atm_albedo_monthly.dat
genie-ents/data/uvic_windx.silo
genie-ents/data/uvic_windy.silo
genie-ents/data/monthly_windspd.silo
genie-ents/data/inv_linterp_matrix.dat
genie-ents/data/orography.dat
genie-ents/data/icemask.dat
genie-ents/config/sealevel_config.par
</pre>

==== input (and output) directory information in my_experiment.xml ====

In definitions.xml, the default settings for genie, which are overridden by those specified in your experiment config file, default directory locations are specified, e.g. for the EMBM:

<pre>
<param name="indir_name">
<value datatype="string"><varref>RUNTIME_ROOT</varref><sep/>genie-embm<sep/>data<sep/>input</value>
</param>

<param name="rstdir_name">
<value datatype="string"><varref>RUNTIME_ROOT</varref><sep/>genie-embm<sep/>data<sep/>input</value>
<description>restart (input) directory</description>
</param>

<param name="outdir_name">
<value datatype="string"><varref>RUNTIME_OUTDIR</varref><sep/>embm</value>
</param>

</pre>

Note that the output directory for EMBM is already set correctly to meet with the specification of a GENIE experiment. However, it could be simplified by replacing '<varref>RUNTIME_OUTDIR</varref>' with '.' as genie.exe is executed from within the experiment directory.

The input directories however have to be changed to point at the input directory of the experiment directory. Therefore, in the embm section of your config file, you will need to override the default values:

<pre>
<param name="indir_name">.<sep/>input<sep/>genie-embm<sep/>data<sep/>input</param>
<param name="rstdir_name">.<sep/>input<sep/>genie-embm<sep/>data<sep/>input</param>
</pre>

=== build_experiment.sh ===

The build_experiment.sh script does the following:

# creates an experiment directory within genie-experiments and input and aladdin subdirectories
# copies user-specified (by -m and -g) or default mapVarData and graphVarData files to the ALADDIN directory
# copies input files specified in the file list (as <path-to-file>) from genie/<path-to-file> to my_experiment/input/<path-to-file>
# copies genie_wrapper.sh to my_experiment
# copies config file to genie-main/configs
# changes directory to genie-main and runs make cleanall (unless -n option specified)
# executes genie_example.job -f <configfile> -x which does most of the work

note that the -x command-line argument to genie_example.job supresses the execution of the model i.e. compilation and file copying to experiment directory only.

Your GENIE experiment can now be moved to anywhere and run from there (by ./genie_wrapper.sh for logged output or ./genie.exe for command-line output) or used with ALADDIN, independent from the genie source tree. Yay!