build roms

From WikiROMS
(Redirected from build Script)
Jump to: navigation, search
GNU Make Build Script - build_roms.csh,

As mentioned in makefile, you need to provide settings for some user-defined choices before you can compile ROMS. If you have more than one application (or more than one compiler), you may get tired of editing the makefile. One option is to have a makefile for each configuration. The recommended solution, however, is to use the ROMS build script.

Note Note: in SVN revision 1030 (April 30, 2020) the ROMS build scripts (and other shell scripts) were renamed to follow accepted naming conventions; *.sh scripts were changed to *.csh and *.bash where changed to *.sh.


There are two of these build scripts in the ROMS/Bin directory: build_roms.csh and The build scripts use environment variables to provide values for the user-defined make variables, overwriting those found in the ROMS makefile. Just as in the multiple makefile option, you will need as many copies of the build script as you have applications. However, the scope of these variables is local to the build script, allowing you to compile different applications at the same time from the same sources as long as each $(SCRATCH_DIR) is unique.


./build_roms.csh [options]


-j [N] Compile in parallel using N CPUs
omit argument for all available CPUs.

-p macro Prints any makefile variable value. For example, -p FFLAGS

-noclean Do not clean already compiled objects.


./ -j 2

User Definable Compilation Options

ROMS has a growing list of choices the user must make about the compilation before starting the compile process. These user-defined variables can be set in the build script. Since we use gnu make, it is possible to set the value of these variables in the Unix environment, rather than inside the Makefile (see gmake). The user-definable variables understood by the ROMS makefile are:

CPP option defining a particular application (for example, UPWELLING). The makefile will include its associated header file which is located in either the ROMS/Include directory or the path specified in the MY_HEADER_DIR definition. The header file name is the lowercase value of ROMS_APPLICATION with the .h extension (for example, upwelling.h). Recall the CPP option defining an application must be unique.

This path is internal to the build script and has no equivalent in the makefile. It can be used to set the base path to your ROMS source code and/or your application input and output files. This variable is not strictly necessary but can make setting the necessary paths easier.

This path is internal to the build script and has no equivalent in the makefile. MY_PROJECT_DIR is most often used to set the paths: MY_HEADER_DIR, MY_ANALYTICAL_DIR, and BINDIR and to set the base path to SCRATCH_DIR. This can be seen near the bottom of the build script.

This path is internal to the build script and has no equivalent in the makefile. It is the location of your ROMS source code and is necessary for the build script to work properly.

Directory where make can find your system/compiler specific mk include files as described in FORT. In some situations you will need to edit the appropriate mk file in the Compilers directory (i.e. Compilers/ Rather than editing the mk files released with ROMS and possibly creating conflicts during updates, we suggest that you copy the appropriate system specific mk file and the Compilers/ to another folder and set COMPILERS to that folder.

Additional CPP options to activate. Sometimes it is desirable to activate one or more CPP options to run different variants of the same application without modifying its header file. If this is the case, specify such options here using the -D syntax. Notice that you need to use your shell's quoting syntax to enclose the definitions. For example:
can be use to write time-averaged fields and use analytical initial conditions. Notice that you can have as many definitions as you want by appending values.

WarningWarning: Be sure to leave environment variables meant to be off set to an empty string or commented out. Any string value (including off) will evaluate to TRUE in conditional if-statements.

Compile your application using MPI (distributed-memory) libraries.

If USE_MPI is activated, use this to turn on compilation via the script mpif90. This is needed in most Linux operating systems. In some systems with native MPI libraries the compilation does not require MPICH type scripts. This macro is also convenient when there are several Fortran compiliers (ifort, pgf90, pathf90) in the system that use mpif90. In this case, the user needs to select the desired compiler via the FORT variable and turn on both USE_MPI and USE_MPIF90 macros.

If USE_MPI and USE_MPIF90 are activated, this macro is used to determine which mpif90 to compile with. This macro is convenient when there are several Fortran compiliers (ifort, pgf90, etc.) in the system that use mpif90. The choice of which mpif90 to use will be determined by the combination of this macro and the FORT macro.

Compile your application using OpenMP librairies and compiler options. Note: you cannot set USE_OpenMP and USE_MPI at the same time.

The ROMS make system will include a file with all the settings that depend on the system and the compiler. The name of this file is determined from the output of the uname command and the value of FORT (i.e. Set your compiler here from the following list:
Operating System Compiler(s)

AIX: xlf
CYGWIN: df, g95, gfortran, ifort
Darwin: f90, gfortran, ifort, pgi, xlf
IRIX64: f90
Linux: ftn, g95, gfortran, ifc, ifort, necsx, path, pgi
MINGW: g95, gfortran
OSF1: f90
SunOS: f95, ftn
UNICOS-mk: f90
UNICOS-mp: ftn
UNICOS-sk: f90
Feel free to send us additional rule files to include!

Activate debugging compiler options.

If applicable, activate 64-bit compilation.

If applicable, link with NetCDF-4 library. Notice that the NetCDF-4 library needs both the HDF5 and, if you want to enable parallel I/O, MPI libraries. In order to write the output files in NetCDF-4/HDF5 format, you will need to set the HDF5 CPP Option.

Activate parallel I/O using parallel enabled NetCDF-4/HDF5 libraries. You will also need to set the HDF5 and PARALLEL_IO CPP Options to enable parallel I/O.

Activate parallel I/O using Parallel IO (PIO) libraries developed at NCAR. More information can be found on on the ROMS I/O page.

Activate parallel I/O using the Software for Caching Output and Reads for Parallel I/O (SCORPIO) library intended for the DOE's Energy Exascale Earth Model System (E3SM). More information can be found on on the ROMS I/O page.

If any of the coupling components use the HDF5 Fortran API for primary I/O, we need to compile the main driver with the HDF5 Fortran library.

WRF cannot be built in a directory specified by the user; it must be built in its own root directory and cannot be moved when debugging with tools like TotalView. If you wish to couple ROMS with the Earth Systems Model (ESM) WRF, ROMS needs to know the WRF root directory.

Use custom library paths for ESMF, HDF5, NetCDF libraries, etc.

Path to your my_build_paths.csh (or .sh) file that contains custom library paths for your system.

This is the Directory where your application's header file is located. Recall that a ROMS header file contains all the CPP options defining a particular application. This is the header file that is included in cppdefs.h. Notice that if the header file is located in the ROMS/Include directory, it is possible to include the same header file name located somewhere else because the full directory path is specified here. The user may copy the distributed header file(s) into a different directory and modify it to explore different CPP options.

This is the directory containing the user's analytic files, if any. Templates of the analytic expressions are provided in the User/Functionals directory. If analytic expressions are activated, the makefile will first load the ones located in MY_ANALYTICAL_DIR and then the ones located in ROMS/Functionals. We recommended that you do not modify the analytical expressions in the ROMS/Functionals directory since these are the official versions of these files and updates will conflict with your changes. The user however can modify those in User/Functionals or some other directory and specify which directory with this variable.

Directory where your romsG, romsM, romsO, or romsS executable will be created.

Directory where your temporary objects and files will be placed during the build process.

Build Script Debugging

NoteNote: The build script has the -p option to inquire and report about any of the environmental and local variables used in the makefile or build scripts. Usefull build commands are: -p LIBS -p libraries -p modules -p includes -p sources -p CPPFLAGS -p MY_CPP_FLAGS -p MY_ROOT_DIR -p MY_ROMS_SRC -p MKFILE -p FFLAGS
We highly recommend to use this option to inquire your environment when having errors during compiling and linking. For Example: -p MKFILE

Using customized library paths from: /Users/arango/Compilers/ROMS/

MKFILE = /Users/arango/Compilers/ROMS/
Notice that there is not a compilation, but a report about the value of local makefile variable MKFILE.

Library and Executable Paths

NoteNote: in SVN revision 933 (January 26, 2019) the custom libraries section was removed from the ROMS build script and placed in Compilers/my_build_paths.csh and Compilers/ to both streamline the ROMS build script and make setting up new applications less tedious. More information can be found in ROMS Trac ticket #794. Prior to ROMS release 933, library and executable paths where set in ROMS build script.

The path of the libraries and MPI implementations required by ROMS can be set using environment variables which take precedence over the values specified in the makefile macro definitions file (Compilers/*.mk). If so desired, set USE_MY_LIBS to yes and properly set MY_PATHS. Visit my build paths for more details.