View source for Input Parameter Files

<div class="title">Input Parameters Files</div>

{{note}}'''NOTE:''' Starting with '''revision 460''' file names can be up to 256 characters long. Previously only 80 characters were allowed.


ROMS has several ASCII text files to set application input parameters. The templates for these files are located in the '''User/External''' or '''ROMS/External''' subdirectories:

# Physical input parameters (default standard input file): [[ocean.in]].
# Multiple models coupling input parameters: [[coupling.in]].
# Biological models input parameters: [[bio_Fennel.in]], [[ecosim.in]], [[nemuro.in]], [[npzd_Franks.in]], [[npzd_iron.in]], [[npzd_Powell.in]].
# Sediment model input parameters: [[sediment.in]].
# Stations input parameters: [[stations.in]].
# Floats input parameters: [[floats.in]].
# 4DVar data assimilation input parameters: [[s4dvar.in]].
# SWAN wave model input parameters: [[swan.in]].

These files use ROMS own '''namelist''' syntax.  The are processed (read) in [[inp_par.F]]. The syntax has similar functionality as Fortran input '''namelist''' but with additional capabilities.

==Important Notes on File Syntax==

* Prior to '''revision 460''' file name length was limited to 80 characters. Now the limit is 256 characters.

* Comment lines are allowed and begin with an exclamation mark (<span class="red">!</span>) in column one.  Comments may appear to the right of a parameter specification to improve the documentation of your choices.  All comments will ignored during reading.

* Blank lines are also allowed and ignored.

* Continuation lines in a parameter specification are allowed and must be preceded by a backslash ( <span class="red">\</span> ).

* Multiple NetCDF files are allowed for input field(s).  This is useful when splitting input data (climatology,  boundary,  forcing)  time records into several files (say monthly, annual, etc). In this case, each multiple file entry line needs to be ended by the vertical bar ( <span class="red">'''|'''</span> ) symbol. For example:<div class="box"><span class="twilightBlue">! Input forcing NetCDF file name(s).</span><br /><br />     [[Variables#nFfiles|NFFILES]] == 7                                             <span class="twilightBlue">! number of forcing files</span><br /><br />     [[FRCname|FRCNAME]] == my_tides.nc       \<br />                my_lwrad_year1.nc |<br \>                my_lwrad_year2.nc \<br />                my_swrad_year1.nc |<br />                my_swrad_year2.nc \<br />                my_winds_year1.nc |<br />                my_winds_year2.nc \<br />                my_Pair_year1.nc  |<br />                my_Pair_year2.nc  \<br />                my_Qair_year1.nc  |<br />                my_Qair_year2.nc  \<br />                my_Tair_year1.nc  |<br />                my_Tair_year2.nc</div>Notice that [[nFfiles|NFFILES]] is 7 and not 13. There are 7 uniquely different fields in the file list, we '''do not''' count file entries followed by the vertical bar symbol. This is because multiple file entries are processed in ROMS with derived type structures.                                               

* Input parameters can be entered in '''any''' order, provided that the parameter '''KEYWORD''' (usually, uppercase) is typed correctly followed by <span class="red">=</span> or <span class="red">==</span> symbols for singular and plural assignments, respectively. A singular assignment indicates that there is not nested grid dependency whereas the plural assignment indicates that each nested grid has a parameter value. 
 
* In multiple levels of nesting and/or multiple connected domains, [[Ngrids]] entries are expected for some of these parameters. The double equals symbols <span class="red">==</span> syntax is for those parameters which will need to be assigned distinct values for each grid in multiple grid applications. The order of the entries for multigrid parameters is extremely important.  It must follow the same order (1:[[Ngrids]]) as in the state variable declaration.

* Parameters that are not used can be omitted from the list, so the input file for a specific application can be very concise.

* Frequently, more than one value is required for a parameter. If fewer values are provided, the last value is assigned for the entire parameter array.  For convenience, the multiplication symbol (<span class="red">*</span>) without blank spaces in between is allowed for a repeated value in a long list specification.  For example, in a three grids nested application [[Akt_bak|AKT_BAK]] must be specified for temperature and salinity for all three grids, i.e. six values in total. The line:<div class="box">     [[Akt_bak|AKT_BAK]] == 2*1.0d-6  2*5.0d-6  2*3.0d-6                     <span class="twilightBlue">! m2/s</span></div> indicates that the first two entries of array [[Akt_bak|AKT_BAK]] will have the same value of '''1.0d-6''' for grid 1, the next two entries will have the same value of '''5.0d-6''' for grid 2, and grid 3 will use '''3.0d-6'''. Thus the line is short-hand for:<div class="box">     [[Akt_bak|AKT_BAK]] == 1.0d-6 1.0d-6 5.0d-6 5.0d-6 3.0d-6 3.0d-6        <span class="twilightBlue">! m2/s</span></div>The comment at the end is provided as a reminder of the correct units for this parameter.