CSTMS UNSW2008

Adding Sediment to the Latte Example

On Friday, 3 April, there will be a tutorial for new ROMS users interested in sediments. This tutorial continues using the LATTE example presented during the Monday tutorial.

Test the LATTE case

Make sure you can run the examples discussed in the Monday tutorial.

Input files are at http://coast-enviro.er.usgs.gov/models/Latte/in

Change the advection scheme

You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). TS_MPDATA is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of Piotr Smolarkiewicz. See the [[1]wiki discussion.]

Anyway, make sure you

#define TS_MPDATA

and

#undef TS_U3HADVECTION
#undef TS_SVADVECTION

(or remove) any other horizontal advection switches. It is a good idea to recompile and test again after this small change...if something goes awry, it is good not to have accumulated lots of changes.

Turn on sediment

What is different about sediment?

External differences

The external differences are required changes in user input and output. They include:

• Switches in .h file
• Changes in .in file
• Need sediment.in file
• Need to modify (a copy of) ana_sediment.F
• New output in his.nc file

Many applications also need

• More info in init.nc file (initial bed)
• Wave input
• River sediment input
• Boundary conditions

Internal differences

Components of the sediment model include:

• TS_MPDATA – Positive-definite advection scheme
• Wave model (as input via a forcing file, or directly coupled)
• Wave-current combined bottom stresses
• Erosion / deposition / bed model (sand)
• Settling
• Bedload transport and flux divergence
• Morphological evolution
• Wetting and drying
• Cohesive and mixed sediments

SWAN - A Digression

Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because the coupling to ROMS is not seamless...you still have to specify the SWAN INPUT file, bathymetry, and some of the forcing for SWAN as separate files.

Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:

SET NAUTICAL
COORDINATES SPHERICAL
CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &
CIRCLE 36 0.0418 1.0 24
READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE

NAUTICAL implies that directions are specified in degrees and (for wind and waves) indicate the direction from which the wind/waves are approaching, For example, a uniform southwesterly wind (blowing toward the northeast) at 5 m/s for a stationary run would be specified as

WIND 5 225

SWAN output in .mat files should be interpreted this way as well.

In the Latte example, we have good wind forcing files that work with ROMS, and we want to use the same files to force waves in SWAN. We will use the SWAN commands

INPGRID WIND CURVILINEAR 0 0 145 81 EXC 9.999000e+003 &
NONSTATIONARY 20060405.000000 1 HR 20060608.230000
READINP WIND 1 'swan_lattec_wind.dat' 4 0 FREE

We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting file swan_lattec_wind.dat has sequences of u and v velocities written for each time step. The u- and v- components are aligned with the x- and y-axes of the SWAN grid. The order in which they are written is determined by the 'layout' parameter (in this case, 4), which means the

file looks like this.

u(1,1,1) u(1,1,2) ... u(1,1,nj)
u(1,2,1) u(1,2,2) ... u(1,2,nj)
...
u(1,ni,1) u(1,ni,2)... u(1,ni,nj)
v(1,1,1) v(1,1,2) ... v(1,1,nj)
v(1,2,1) v(1,2,2) ... v(1,2,nj)
...
v(1,ni,1) v(1,ni,2)... v(1,ni,nj)
u(1,1,1) u(1,1,2) ... u(1,1,nj)
u(1,2,1) u(1,2,2) ... u(1,2,nj)
...
u(1,ni,1) u(1,ni,2)... u(1,ni,nj)
v(2,1,1) v(2,1,2) ... v(2,1,nj)
v(2,2,1) v(2,2,2) ... v(2,2,nj)
...
v(2,ni,1) v(2,ni,2)... v(2,ni,nj)
...etc

where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).