CBLAST model of southest New England shelf

[wilkin]

Coupled Boundary Layers and Air-Sea Transfer (CBLAST)

Configuration and input files for a model of the southeast New England shelf in the environs of the Martha's Vineyard Coastal Observatory (MVCO) during the ONR Coupled Boundary Layers and Air-Sea Transfer (CBLAST) experiment are now available from the Softwate|Datasets link on the ROMS Forum www.myroms.org

These files are provided as one example of how we recommend users configure realistic applications with the latest release of the code. A description of how to use the CBLAST files is presented on the ROMS Wiki under Applications: https://www.myroms.org/wiki/index.php/Applications

We invite other users who wish to distribute pre-configured realistic applications to describe their applications on the Wiki and provide links to the data files and ROMS configuration files. If you wish to distribute your files on www.myroms.org under the same Software|Applications entry contact me.

The CBLAST model configuration requires only a single include file cblast.h, an input script ocean_cblast.in, and the netcdf files that define the grid, boundary and forcing data.

This is possible because recent changes to the code structure now make it straightforward to confine application-specific options to a small number of files maintained separately from the central code. Most users configuring a typical application of the forward simulation model need only edit:

* a file containing the CPP definitions, e.g. project.h. (The cppdefs.h file in previous ROMS versions has been re-structured to do this).
* an input ocean.in script
* initial, forcing and/or boundary netcdf files
* application-specific analytical options following the templates for ana_*.F files in the User/Functionals directory. (The analytical.F subroutine in previous versions has been re-structured to do this).

This approach has the advantages that:
* Users can update their central code, adding newly developed features and fixing reported bugs, without upsetting personal options for a specific project. Using SubVersion svn is our recommended way to keep current with the most recent ROMS development branch
* Users can work on more than one project at once using a single up-to-date code stem
* Applications can be shared with colleagues without redistributing the entire source code, thereby fostering user community use of the most up-to-date ROMS release