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 (2 20) where
i = subscript indicating a tidal constituent = external boundary water surface elevation = mean amplitude [m] = node (nodal) factor [-] = frequency [deg/hr] = elapsed time from midnight of the starting year [hrs] = equilibrium phase [deg] = phase lag or epoch [deg]
The nodal factor is a time-varying correction to the mean amplitude. The equilibrium phase has a uniform component and a relatively smaller periodic component. The zero-superscript of 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 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
figure 2-68
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.
figure 2-69
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