Getting Started

Getting Started

ROMS is a very complex model with many options and capabilities. ROMS is composed of many Fortran files (*.F), a few header files (*.h), various input script files (*.in), a metadata variable definition file (varinfo.dat), and a single makefile. The ROMS algorithms are distributed with the following directory structure:

 
 trunk/                               Main trunk directory
      /Atmosphere/                    Atmosphere models root directory
                 /COAMPS              COAMPS root directory (empty)
                 /WRF                 WRF root directory (empty)
      /Compilers/                     make configuration files
      /Data/                          Input data root directory
           /ROMS/                     ROMS data root directory
                /CDL                  ROMS Metadata design
                /Forcing              Input test cases forcing NetCDF files
                /Grid                 Input test cases grid NetCDF files
                /Initial              Input test cases initial conditions NetCDF files
      /Lib/                           External libraries
          /ARPACK                     Arpack eigenvalue problems library
          /MCT                        Modeling Coupling Tool library
          /MCT_WRF                    WRF Modeling Coupling Tool library
      /Master                         Main standalone and coupling programs
      /ROMS/                          ROMS root directory
           /Adjoint                   Adjoint model
           /Bin                       Executable scripts
           /Drivers                   Computational drivers
           /External                  Standard input scripts
           /Functionals               Analytical expression header files
           /Include                   Test cases configuration header files
           /Modules                   Declaration modules
           /Nonlinear                 Nonlinear model
           /Obsolete                  Discontinued files
           /Programs                  Support programs
           /SeaIce                    Sea-ice model (empty)
           /Representer               Representer model
           /Tangent                   Tangent linear model
           /Utility                   Generic utility files
           License_ROMS.text          Open source license
           Version                    SVN Version information
      /User/                          ROMS User interface root directory
           /External                  User standard input scripts
           /Functionals               User analytical expresions templates
           /Include                   User application header files
      /WAVES/                         Waves models root directory
            /SWAN                     SWAN root directory
                 /External            SWAN input data and standard input files
                 /Src                 SWAN model

ROMS uses extensively C-preprocessing to activate and/or deactivate the various numerical and physical algorithm options. It also uses NetCDF to manage input and output data streams. It is highly recommended that first time users learn the basics about NetCDF before starting working with ROMS.

Basic Steps

• Register at the ROMS website (www.myroms.org) to get access to the algorithms and other user privileges. Select an username and password which will be used in the future to login and post messages in the ROMS forum, algorithm downloads, and contributing to wikiROMS.

• Use a Subversion client to "checkout" the latest version of the ROMS trunk (Detailed information can be found here).

• Make roms by typing 'make' This will run the makefile at the top of the directory structure. This file will include a special makefile particular to your operating system and compiler, found in the Compilers subdirectory. You may need to edit this so that ROMS can find your netcdf libraries. You can also modify the compiler flags here if you want to, say, compile ROMS to run with the MPI libraries.

• TIP: You can type make -j <number of processors> to make ROMS faster. This will spread the make process over more than one processor. Often, you can also compile in debug mode (FFLAG=-g) -- that will typically compile much faster, so you can make sure the code compiles. However, it will cause the code to run *much* more slowly. Usually, you will want to optimize the code with a compiler flag -O. We have found that level 2 optimization (FFLAG=-O2) is usually good enough, and compiles faster than higher level optimization.

• TIP: You can also build ROMS without modifying the makefile or anything else in the source distribution by using the "build.sh" script. See a detailed example of using "build.sh" to build the LAKE_SIGNELL test case.

Questions from New Users

• My build finished with no errors. Where is the ROMS executable?

It is either in oceanS (serial), oceanO (OpenMP), oceanM (MPI), or oceanG (debug). Check the makefile to see which options are on.

• What do I have to do to run an application?

There are basically four levels of complexity in running an application.

1. Canned applications that come with the ROMS distribution and don't need input. These can be run by editing ./Include/cppdefs.h to #define one (all others should be #undef) of the pre-defined model applications. Then make (good practice to make clean first) and, if you are lucky, the program will build. It should run with the command ./oceanS
2. Canned applications that come with ROMS and require input files. Same as above, but now they have to be run with a command like ./oceanS < External/ocean_some_predefined_app.in. These may also require netCDF input files with names like ocean_some_predefined_app.nc.
3. User-specified applications with no input data. These are the best test beds for new users or new algorithms. They consist of a set of selected cpp options in /Include/cppdefs.h, a user-generated .in file, and usually modifications to /Nonlinear/analytical.F to specify intial, boundary, and forcing conditions internally.
4. User applications with input data...the real deal. These require changes to cppdefs.h, some_app.in, and appropriate input files for initialization and forcing.

• Why the _r8 at the end of real constants?

Some computers use 32 bits for single precision real numbers and 64 bits for double precision, and some use 64 and 128, respectively. For consistent results on various machines, ROMS takes advantage of the intrinsic F90/95 function SELECTED_REAL_KIND( ). (See ./Modules/mod_kinds.F). This allows you to associate an integer parameter with a specific data type...in this case r8 is associated with 64-bit precision. RTFM (Read the Fortran90 Manual), or better yet, chapter 11 in Chapman, 2004.