Difference between revisions of "build roms"

From WikiROMS
Jump to navigationJump to search
Line 3: Line 3:
An alternative way to compile and link ROMS is to use the <span class="red">build.sh</span> script located in the '''ROMS/Bin''' directory. Instead of editing the [[makefile]] often, the user may generate a build script for each of his/her applications. The build script uses environmental variables that overwrite the makefile targets defined with <span class="red">?=</span> syntax. This means that [[gmake | make]] will check whether an environment variable by that name is set in the script that calls make. The environmental variable take precedence and overwrites makefile default value. Its scope is local to the build script execution, allowing compiling different applications at the same time. There is not need to maintain separate makefiles, or frequently edit the makefile to run separated applications.
An alternative way to compile and link ROMS is to use the <span class="red">build.sh</span> script located in the '''ROMS/Bin''' directory. Instead of editing the [[makefile]] often, the user may generate a build script for each of his/her applications. The build script uses environmental variables that overwrite the makefile targets defined with <span class="red">?=</span> syntax. This means that [[gmake | make]] will check whether an environment variable by that name is set in the script that calls make. The environmental variable take precedence and overwrites makefile default value. Its scope is local to the build script execution, allowing compiling different applications at the same time. There is not need to maintain separate makefiles, or frequently edit the makefile to run separated applications.


   <div class="box">'''Usage:'''<br /><br /><span class="red" style="padding-left:2em">./build.sh [options]</span><br /><br />'''Options:'''<br /><br /><span class="red" style="padding-left:2em;padding-right:70px;">-j [N]</span>Compile in parallel using <span class="red">N</span> CPUs.  Omit argument to compile on all availabe CPUs.<br /><span class="red" style="padding-left:2em;padding-right:30px;">-noclean</span>Do not clean already compiled objects.<br /><br />'''Example:'''<br /><br /><span class="blue" style="padding-left:2em">./build.sh -j 2</span></div>
   <div class="box">'''Usage:'''<br /><br /><span class="red" style="padding-left:2em">./build.sh [options]</span><br /><br />'''Options:'''<br /><br /><span class="red" style="padding-left:2em;padding-right:70px;">-j [N]</span>Compile in parallel using <span class="red">N</span> CPUs.  Omit argument to compile on all availabe CPUs.<br /><span class="red" style="padding-left:2em;padding-right:30px;">-noclean</span>Do not clean already compiled objects.<br /><br />'''Example:'''<br /><br /><span class="green" style="padding-left:2em">./build.sh -j 2</span></div>
 
The new structure of ROMS version 3.0 or higher allows user specific CPP definitions and analytical options to be set in a small number of separate standalone header files. Therefore, users no longer have to modify small blocks of code like was neccessary in previous versions of [[cppdefs.h]] and [[analylitical.F]]. This makes it easy to distribute the configuration for a specific application via a small number of source code related files plus the inputs (grid, initial conditions, and forcing NetCDF files), while allowing users of the application to keep current with central code improvements via [[Subversion | svn]]. This also takes care of all licensing issues. You are free to include your own statement of your contributions in the files you distribute. The license and copyright statements by the ROMS developer group remain in the source code distributed at [https://www.myroms.org www.myroms.org].
 
We recommend users to work with a local source code that is regularly updated with the official version at the ROMS [https://www.myroms.org/projects/src svn repository] using '''svn update'''. This will allow bug fixes and new code developments to be pushed out to users and minimize the risk of a user unwittingly working with code with known flaws. There are few standalone applications in ROMS website [http://www.myroms.org/index.php?page=Datasets Datasets] menu. The user can download any of these set-up. Notice that these applications do not include the source code since the user can checkout the latest version of ROMS from the '''svn''' repository. We usually create a Projects root directory containing all applications.  For example, the double gyre test case ('''double_gyre.tar.gz''') has the following directory structure:
 
  <span class="purple">Projects                              root directory
          /double_gyre                  idealized double gyre test case
                      /Data              input NetCDF files
                      /Forward          nonlinear model, ensembles
                      /IS4DVAR          incremental, strong contraint 4DVar
                      /OBS              data assimilation observations</span>
 
If you check the '''IS4DVAR''' sub-directory, you will find the following files:
 
  <span class="purple">Projects
          /double_gyre
                      /IS4DVAR
                              /build.sh
                              /double_gyre.h
                              /job_is4dvar.sh
                              /is4dvar.in
                              /ocean_double_gyre.in
                              /s4dvar.in</span>
 
Notice that there is a copy of the header file double_gyre.h

Revision as of 18:20, 14 June 2007

Build Script - build.sh

An alternative way to compile and link ROMS is to use the build.sh script located in the ROMS/Bin directory. Instead of editing the makefile often, the user may generate a build script for each of his/her applications. The build script uses environmental variables that overwrite the makefile targets defined with ?= syntax. This means that make will check whether an environment variable by that name is set in the script that calls make. The environmental variable take precedence and overwrites makefile default value. Its scope is local to the build script execution, allowing compiling different applications at the same time. There is not need to maintain separate makefiles, or frequently edit the makefile to run separated applications.

Usage:

./build.sh [options]

Options:

-j [N]Compile in parallel using N CPUs. Omit argument to compile on all availabe CPUs.
-nocleanDo not clean already compiled objects.

Example:

./build.sh -j 2

The new structure of ROMS version 3.0 or higher allows user specific CPP definitions and analytical options to be set in a small number of separate standalone header files. Therefore, users no longer have to modify small blocks of code like was neccessary in previous versions of cppdefs.h and analylitical.F. This makes it easy to distribute the configuration for a specific application via a small number of source code related files plus the inputs (grid, initial conditions, and forcing NetCDF files), while allowing users of the application to keep current with central code improvements via svn. This also takes care of all licensing issues. You are free to include your own statement of your contributions in the files you distribute. The license and copyright statements by the ROMS developer group remain in the source code distributed at www.myroms.org.

We recommend users to work with a local source code that is regularly updated with the official version at the ROMS svn repository using svn update. This will allow bug fixes and new code developments to be pushed out to users and minimize the risk of a user unwittingly working with code with known flaws. There are few standalone applications in ROMS website Datasets menu. The user can download any of these set-up. Notice that these applications do not include the source code since the user can checkout the latest version of ROMS from the svn repository. We usually create a Projects root directory containing all applications. For example, the double gyre test case (double_gyre.tar.gz) has the following directory structure:

 Projects                               root directory 
         /double_gyre                   idealized double gyre test case 
                     /Data              input NetCDF files 
                     /Forward           nonlinear model, ensembles 
                     /IS4DVAR           incremental, strong contraint 4DVar 
                     /OBS               data assimilation observations

If you check the IS4DVAR sub-directory, you will find the following files:

 Projects 
          /double_gyre 
                      /IS4DVAR 
                              /build.sh
                              /double_gyre.h
                              /job_is4dvar.sh
                              /is4dvar.in
                              /ocean_double_gyre.in
                              /s4dvar.in

Notice that there is a copy of the header file double_gyre.h