User Guide 009

Extracted Water Level Tidal Constituents from a Database

CMS supports extracting water level tidal constituent information directly from regional and world tidal databases. The constituent information is then used internally to generate boundary information along cellstrings according to

${\bar {\eta }}_{E}({\overrightarrow {x}},t)=\Sigma f_{i}A_{i}cos(\omega _{i}t+V_{i}^{0}+{\hat {u}}_{i}-\kappa _{i})$

(2-20)

where

 i = subscript indicating a tidal constituent 

${\bar {\eta }}_{E}({\overrightarrow {x}},t)$ = external boundary water surface elevation

$A_{i}({\overrightarrow {x}})$ = mean amplitude [m]

fi = node (nodal) factor [-]

$\omega _{i}$ = frequency [deg/hr]

t = elapsed time from midnight of the starting year [hrs]

$V_{i}^{0}+{\hat {u}}_{i}$ = equilibrium phase [deg]

$\kappa _{i}({\overrightarrow {x}}))$ = phase lag or epoch [deg]

The nodal factor is a time-varying correction to the mean amplitude. The equilibrium phase has a uniform component $V_{i}^{0}$ and a relatively smaller periodic component. The zero-superscript of $V_{i}^{0}$ indicates that the constituent phase is at time zero.

All tidal databases have constituent information for water levels and some also have constituent information for current velocities. The table below lists the tidal databases currently supported in SMS and some basic information.

table 2-60

The Le Provost tidal database can be downloaded from http://sms.aquaveo.com/leprovost.zip. The ADCIRC tidal databases can be downloaded from http://www.unc.edu/ims/ccats/tides/tides.htm. The FES2004 tidal database can be downloaded from http://www.legos.obs-mip.fr/en/share/soa/cgi/getarc/v0.0/index.pl.cgi?contexte=SOA&donnees=maree&produit=modele_fes.

Notes:

• The accuracies of the nonlinearly generated constituents STEADY, M4, and M6 in the ADCIRC tidal databases have not been verified and should therefore be used with caution.

The CMS-Flow cards used to specify the tidal database information are described in the table below.

table 2-61

The example below only 4 tidal constituents are selected from the tidal database. In addition an WSE offset is specified to correct for a tidal datum shift.

example 2-57

Example: CMS simulation of Southern California using Tidal Databases

The CMS model is setup for southern California coast. The computation grid is presented in the figure below.

Figure 2-66. Example computational grid for southern California.

The offshore boundary is specified a tidal database boundary condition. The tidal dabase selected is the EC2001 database which is based on a regional ADCIRC simulation. In the case, the same regional database was used to generate the bathymetry for the CMS simulation. The CMS-Flow input cards used to specify the offshore boundary are described in the example below.

example 2-58

Figure 2-67. Sample water levels and current velocites for southern California forced with the water surface elevation constituents extracted from the ENPAC2003 tidal datbase.

Figure 2-68. Location of Oil Platform Harvest, CA.

In order to show the variability in tidal constituents between different databases, the amplitudes and phases of three databases are presented in Figure 2 69 at the Oil Platform Harvest, CA. The ENPAC2003 database has the largest tidal amplitudes compared to the FES2004 and FES95.2 databases. It is noted that the FES95.2 database does not contain the P1 constituent. The phases are relatively similar with the largest differences occurring for the K2 constituent.

a.

b.

Figure 2-69. Comparison of tidal constituent amplitudes (a) and phases (b) at Oil Platform Harvest, CA, for three different tidal databases.

Mixed Water Level and Current Velocity Boundaries

There are three types of mixed water level and velocity boundary condi-tions supported using block structures

7. Multiple water level and velocity boundary condition

8. Nested water level and velocity boundary condition

9. Extracted water level and velocity using a tidal constituent database

table 2-62

Multiple Water Level and Current Velocity Time Series Boundary

TBC

Example: SMS-generated Multiple Water Levels and Current Velocities

In the example below the SMS interface is used to create a multiple water level and current velocity time-series boundary and the CMS project files are saved. The CMS-Flow card file is then modified by commenting out the SMS generated cards MULTI_HDRIVER_CELLSTRING and MULTI_VDRIVER_CELLSTRING, and placing the card information in the user-specified boundary block. It is noted that both the cellstring infor-mation and the extracted water levels are contained within the same path of the CMS-Flow Model Parameters File (*_mp.h5). This is the reason why both the CELLSTRING and DATASET cards contain the same file name and path.

example 2-59

Example: User-specified Multiple Water Levels and Current Velocities TBC

example 2-60

example 2-61

Notes:

• If the number of time steps is set to zero (forth entry in second line of TSD file), CMS will automatically determine the number from the in-put file. Therefore, the parameter may be considered optional when using as an input for CMS.

Extracted Water Levels and Current Velocities from a Parent Simulation

As described previously, CMS supports automated one-way nesting within parent CMS and ADCIRC models. When using this feature, the CMS automatically extracts the boundary condition information from the parent model solution. The user only has to specify to point to the boundary cellstring and the location and name of the parent model simulation. The user may force the CMS with either water levels or water levels and velocities extracted from the parent simulation.

The table below describes the CMS cards used to specify a nested water level boundary condition in CMS.

table 2-63

Example: Nesting a CMS simulation within an ADCIRC simulation

If the ADCIRC simulation is 3D, it is important to export the depth-averaged current velocity file (fort.63 or *_.h5) so that this file can be used for current velocity extraction.

example 2-62

It is noted that since the ADCIRC simulation files do not contain infor-mation on the starting date or horizontal projection, this information should to be provided in the model input. If the horizontal projection is not specified, then it is assumed to be NAD83 Geographic in degrees.

In the example below, only the CMS Card file is specified for the parent simulation. The model automatically obtains the parent simulation start-ing time, horizontal projection, and output file names. The water level and velocity blocks are left empty so all of the default parameters are used.

example 2-63

Example: Nesting a CMS simulation within a CMS simulation

example 2-64

Extracted Water Level and Current Velocity Tidal Constituents from a Data-base

TBC

example 2-65

example 2-66

Step-by-Step Instructions for Setting-up Advanced Boundary Conditions

Advanced boundary conditions using boundary blocks are not yet supported in SMS and are therefore entered manually by editing the CMS-Flow Control File.

Option 1: Reassigning an existing boundary condition

This is the simplest option and requires the least amount of work from the user. The option is basically creating a “fake” boundary condition in SMS, saving the project files, so that SMS generates the important cellstring identification (ID) cells to the CMS-Flow Model Parameters File and then manually reassigning the boundary a different boundary condition in the CMS-Flow Control File.

1. Create and select a cellstring in SMS. Open the CMS-Flow Boundary Conditions window (see section Cellstrings for more information).

2. Assign any boundary condition to the boundary such as a tidal or river flux boundary condition. It is recommended to use a boundary condition type that is different from all of the others if possible so that it can be easily identified in the CMS-Flow Control File later. Note: The boundary information does not need to be specified in order for SMS to write out the cellstring information.

3. Save the CMS-Flow Project Files by going to File | CMS-FLOW.

4. Open the CMS-Flow Control File in a text editor.

5. Create an advanced boundary condition block.

6. Copy-paste the cellstring file and path from the corresponding “fake” boundary condition which is being reassigned to the cellstring card within the new boundary block (see example below).

7. Specify any addition cards for the advanced boundary condition.

8. Either comment out or delete the corresponding “fake” boundary condition which is being reassigned (see example below).

example 2-67

Option 2: Copying cellstring ID’s from the CMS-Flow Model Parameters File into a Boundary ID File

1. Create and select a cellstring in SMS.

2. Assign any boundary condition to the boundary such as a tidal or flux boundary condition.

3. Save the CMS-Flow Project Files by going to File | CMS-FLOW.

4. Open the CMS-Flow Model Parameters File using HDFView.

5. Find the cellstring for the corresponding boundary condition and copy-paste the cell ID’s to an ASCII Boundary ID File (*.bid) (see Section Cellstrings for more information on the Boundary ID File).

6. Open the CMS-Flow Control (Card) File in a text editor, and enter the advanced boundary condition using a block structure making sure to reference the Boundary ID File and cellstring ID (see example below).

example 2-68

Preprocessing CMS-Flow Input Time Series

Typically, time series of water levels, winds, river fluxes, salinity, and other types are specified as boundary conditions and it is extremely important that this data be prepared properly for use in the model. Although measured data is often regarded as the “truth”, no instrument is free of errors, failures, or immune to human misuse and mistakes. In numerical models “If junk goes in, junk goes out”. Time series analysis is a topic much too large to be covered in this manual, and only key points are described. For an in-depth review of time series analysis the reader is referred to Emery and Thompson (1998). The general steps for preprocessing time series for CMS are:

1. Data Assembly and Conversion

2. Quality Control (QC)

3. Interpolation

4. Filtering

Data Assembly and Conversion

This step includes the download, format conversion (e.g. binary to ASCII), and conversion of units, reference frames, datum’s, etc. Often time series must be compiled from several raw data files.

Quality Control

Before any manipulation of the data is made, a QC must be performed to remove inaccurate or unreliable data. The definition of inaccurate data depends on the measurement type and its use in a model. Bad data should be removed from the time series before continuing and manipulating the data any further.

Interpolation

Gaps or “holes in data are very common in geophysical measurements. In some cases the model input may require that it be spaced at regular inter-vals. Therefore, any gaps in the data must be interpolated. It is more con-venient to have the data at uniformly spaced intervals.

Note:

• CMS input time series can have irregular intervals.

• It is important that the input time series cover the extent of the simulation to avoid extrapolation issues.

• CMS uses a piece-wise quadratic interpolation for input boundary condition forcing by default. This may be changed but requires us-ing advanced boundary blocks (see Section Advanced Boundary Specification).

Filtering

Measured data often noise or physical processes at frequencies other than the frequencies that want to be used as a mode input. Filtering is the process of removing the signals at any frequencies other than the desired frequencies.

Tip:

• A Matlab Guided User Interface (GUI) for preprocessing model time series is provided on the CIRP wiki (http://cirp.usace.army.mil/wiki/Utilities#Time_Series_Analysis) called filter1d.m. A hands-on tutorial on how to use this utility is pro-vided in Appendix G.

Notes:

• The wave grid for most inlet and coastal cases will be not much longer alongshore than the flow model. If the wave model does not extend far enough, there are model parameters to smoothly interpolate the wave data to some distance alongshore in the flow model.

• Because the grid boundary is often the location of a wave buoy, the cross-shore domain tends to extend further.

• In some cases the best IJ location for the half-plane model may not be apparent, especially for open coasts. Often the degree of energy in the open ocean is dominantly from one direction or the other, and the i-direction should be aligned to that direction.

Salinity Transport

Overview

Salinity refers to the salt content of water. Its value runs typically from 0 for fresh water to 31-35 ppt (parts per thousand) for ocean water. In water bodies with poor mixing and limited water exchange, or experiencing high evaporation, salinity can be higher and lead to formation of brine (see Table 4-21) taken from the Wikipedia, presents typical values and nomenclature for describing degree of saline water:

table 2-64

In coastal zones and estuaries, both temporal and spatial variations in sa-linity are controlled by changes in circulation, waves, tides, precipitation, evaporation, and freshwater inflows. These changes in salinity can have major effects on water density and water stratification, changing circula-tion patterns. Dynamic behavior of suspended sediment can be controlled by the salinity-driven flow and mixing. Any sustained changes to salinity can directly change the aggregation and consolidation of cohesive sediment as well (Nicholson and O’Connor 1986). Salinity can also alter the water chemistry that is closely related to marine organisms. Distribution and abundance of marine life will change water turbidity and define water quality in coastal and estuarine systems. Modifications of coastal inlets, such as channel deepening and widening and rehabilitation or extension of jetties may alter the salinity distribution within the estuary.

Setup

The salinity transport is activated within the CMS-Flow Model Control window (see figure below).

Figure 2-70. Salinity tab in the CMS-Flow Model Control window in SMS 11.1.

The CMS card used to turn on or off the salinity transport is described in Table 2-68.

table 2-65