CSTMS UNSW2008

Adding Sediment to the Latte Example

On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the Monday tutorial.

UNDER CONSTRUCTION - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.

Set up and test the LATTE case

These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.

• If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the exact version used in this tutorial, then cd to the parent directory for your source code and then:

mkdir src
svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src

replacing bruce with your ROMS user name. Omitting the -r 342 will get you the most current (HEAD) version of the code.

• Make sure you can compile and run UPWELLING.

• Make a directory structure that looks like this:

../Latte
../Latte/original
../Latte/in
../Latte/out
../Latte/run01

We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of original and in.

Copy the Latte case to your local directory

For this tutorial, we will work with a directory structure that looks like:

./Lattec
./Latte/in
./Latte/out
./Latte/run01 etc for additional cases.

Change the advection scheme (Run01)

Start with a copy of the .h and .in files.

Latte/run01/latte_c.h run02
Latte/run01/ocean_lattec.in

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. This will be the only change, so recompile and make sure it works 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. A summary of sediment-related cppdefs is listed in sediment_cppdefs.h
• 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

Simplest possible case (Run 02)

It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps (see Run 03).

In the latte_c.h file:

#define TS_MPDATA
#define sediment
#define ana_sediment

In the ocean_lattec.in file:

NNS = 1  ! Number of non-cohesive (sand) sediment tracers
...
SPARNAM = ./sediment_lattec.in

The best way to get a template for the sediment input file is to copy one from the source code to your local directory.

cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in

then edit to suit.

Make an init file (Run03)

Why so boring? Its the waves!

In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are SSW_BBL, MB_BBL, and SG_BBL (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).

Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space. In the first instance, the near bottom wave-orbital velocities are calculated from H_s and T using linear wave theory, using #define SSW_CALC_UB

Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e

Make and use a simple wave forcing file (Run04)

In this section, we will use buoy data to make a simple wave forcing file.

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).