Difference between revisions of "Frequently Asked Questions"
From WikiROMS
Jump to navigationJump to search (New page: <div class="title">Frequently Asked Questions</div> * '''My build finished with no errors. Where is the ROMS executable?'''<br /> It is either in '''oceanS''' (serial), '''oceanO''' (shar...) (change visibility) |
|||
| Line 1: | Line 1: | ||
<div class="title">Frequently Asked Questions</div> | <div class="title">Frequently Asked Questions</div> | ||
__TOC__ | |||
== Installation and Configuration == | |||
=== My build finished with no errors. Where is the ROMS executable? === | |||
It is either in '''oceanS''' (serial), '''oceanO''' (shared-memory, OpenMP), '''oceanM''' (distributed-memory, MPI), or '''oceanG''' (debug). Check the [[makefile]] to see which options are on. The makefile definition <span class="red">BINDIR</span> controls where to write the compiled ROMS executable. | |||
# | |||
=== What do I have to do to run an application? === | |||
There are basically four levels of complexity in running an application: | |||
# Mostly all canned [[Test Cases | applications]] that come with the ROMS distribution do not need input NetCDF files. The grid, initial conditions and forcing conditions are specified with analytical expressions in [[analytical.F | ROMS/Functionals/analytical.F]]. Any of these test cases can be run by editing the <span class="red">ROMS_APPLICATION</span> definition in the [[makefile]] with the application flag. A [[cppdefs.h#Options_for_idealized_test_problems | list]] of all pre-defined model applications can be found in header file [[cppdefs.h]]. The next step is to compile and link using the [[gmake | make]] tool and, if you are lucky, the program will build. It is good practice to execute '''make clean''' first. Then, the application should run with the command: <div class="box"><span class="red">oceanS < ocean_*.in > & log & </span></div> | |||
# 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. | # 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. | ||
# 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 initial, boundary, and forcing conditions internally. | # 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 initial, boundary, and forcing conditions internally. | ||
# 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. | # 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. | ||
== Compiling and Linking == | |||
== Basic Usage == | |||
== Algorithm Design == | |||
=== 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 [[mod_kinds | ROMS/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 [[Bibliography#ChapmanSJ_2004a | Chapman, 2004]]. | |||
Revision as of 04:33, 12 June 2007
Frequently Asked Questions
Installation and Configuration
My build finished with no errors. Where is the ROMS executable?
It is either in oceanS (serial), oceanO (shared-memory, OpenMP), oceanM (distributed-memory, MPI), or oceanG (debug). Check the makefile to see which options are on. The makefile definition BINDIR controls where to write the compiled ROMS executable.
What do I have to do to run an application?
There are basically four levels of complexity in running an application:
- Mostly all canned applications that come with the ROMS distribution do not need input NetCDF files. The grid, initial conditions and forcing conditions are specified with analytical expressions in ROMS/Functionals/analytical.F. Any of these test cases can be run by editing the ROMS_APPLICATION definition in the makefile with the application flag. A list of all pre-defined model applications can be found in header file cppdefs.h. The next step is to compile and link using the make tool and, if you are lucky, the program will build. It is good practice to execute make clean first. Then, the application should run with the command: oceanS < ocean_*.in > & log &
- 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.
- 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 initial, boundary, and forcing conditions internally.
- 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.
Compiling and Linking
Basic Usage
Algorithm Design
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 [[mod_kinds | ROMS/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.
