where the first column is the node count (1, 2, 3, 4, etc.), the second is the grid node number and the third is 1. All values should be integers and refer to the grid nodes (not the elements).

The nodes in the NCNEST_NODE_FILES should be those which describe the elements along the nested boundary. So, the nodes must describe a set of elements from which the velocity data can also be extracted. Essentially, the nodes in the nest must be two rows deep (each side of a line of elements - see figure below).

The manual contains more information on the configuration (see section describing format for Casename_node_nest.dat). More information on this can probably be gleaned from mod_nesting.F, particularly around line 650 in subroutine SETUP_NEST_DOMAIN.

Weighted nesting (type 3)

I will put information here about creating FVCOM nesting files with weights. The examples comes from coupling POLCOMS MED (GCOMS Mediterranean domain) with the Nadoor domain. The functions to do this are included in the MATLAB fvcom-toolbox.

The nesting with a relaxation method (an example is to get nesting data from HYCOM/POLCOMS/NEMO) we need specific variables interpolated to the nested domain.

tseries_dir = '/users/modellers/rito/Models/MEDINA/polcoms/timeseries'; % all physseries, biolseries and zet_UBVB files should be in there

The above list allows the MATLAB scripts to read the details about the POLCOMS model configuration and details of the data timeseries provided. The ipexu array is extracted directly from one of the netCDF files from POLCOMS.

netCDF information

All grid related variables complying with size of data variables (below) in nesting netCDF file. These variables are the same as in any output netCDF file generated that includes grid information. The grid is read first using subroutine LOAD_GRID_TYPE(NCF,G) in mod_input.F.

The interpolated variables from the structured grid model (forcing, weighting etc.) are given below:

Variable

Long name

Dimensions

zeta

Sea surface elevation

[node, time]

ua

Vertically averaged x velocity

[node, time]

va

Vertically averaged y velocity

[nele, time]

u

Eastward Water Velocity

[nele, siglay, time]

v

Northward Water Velocity

[nele, siglay, time]

temp

Temperature

[node, siglay, time]

salinity

Salinity

[node, siglay, time]

weight_cell

Weighting for elements

[nele, time]

weight_node

Weighting for nodes

[node, time]

hyw

Hydro static vertical velocity

[node, siglev, time]

Itime

Days since 1858-11-17 00:00:00

[time]

Itime2

msec since 00:00:00

[time]

Unweighted (DIRECT/INDIRECT) nesting (types 1 and 2)

This section describes how to 'fake' nesting using existing FVCOM model output (without using the NML_NCNEST section of the FVCOM namelist.

For the unweighted (i.e. direct and indirect nesting, referred to as type 1 and 2 in the FVCOM namelists) nesting, the situation is similar to the type 3 (relaxation nesting) except no weight_cell or weight_node arrays are required for the nesting netCDF file.

Using existing FVCOM ouptput

I (Pierre) wrote a Python script to generate a new model grid nest region which is based on a nested grid region (defined as a nodestring from an SMS grid) and a coarse model domain. The script searches for and extracts node and element positions and writes a new section of grid to append to the nested region in SMS. This means an arbitrary nested region can be created from an existing model output. As such, the NML_NCNEST section of the FVCOM namelist need not have been enabled in order to use the coarse model output.

There's a MATLAB script which will take a coarse model output and the new nested grid (complete with nested buffer which shares its nodes with the coarse grid) and extract the required variables for running a nested domain.

The MATLAB fvcom-toolbox routine to write out the netCDF output once the data have been loaded is write_FVCOM_nested_forcing.m.

Currently, I don't know what to use for the hydrostatic vertical velocity, so the values are zero. This may well break things!