# Introduction¶

XBeach is an open-source numerical model which is originally developed to simulate hydrodynamic and morphodynamic processes and impacts on sandy coasts with a domain size of kilometers and on the time scale of storms. Since then, the model has been applied to other types of coasts and purposes.

The model includes the hydrodynamic processes of short wave transformation (refraction, shoaling and breaking), long wave (infragravity wave) transformation (generation, propagation and dissipation), wave-induced setup and unsteady currents, as well as overwash and inundation. The morphodynamic processes include bed load and suspended sediment transport, dune face avalanching, bed update and breaching. Effects of vegetation and of hard structures have been included. The model has been validated with a series of analytical, laboratory and field test cases using a standard set of parameter settings.

XBeach has two modes: a hydrostatic and a non-hydrostatic mode. In the hydrostatic mode, the short wave amplitude variation is solved separately from the long waves, currents and morphological change. This saves considerable computational time, with the expense that the phase of the short waves is not simulated. A more complete model is the non-hydrostatic model which solves all processes including short wave motions, but with more computational demand.

The original application, funded by the U.S. Corps of Engineers in the framework of the Morphos project and the U.S. Geological Survey, was to be able to assess hurricane impacts on sandy beaches. Since then with funding from the Dutch Public Works Department, the model has been extended, applied and validated for storm impacts on dune and urbanized coasts for the purpose of dune safety assessments. With support from the European Commission XBeach has been validated on a number of dissipative and reflective beaches bordering all regionall seas in the EU.

Beyond sandy coasts, the model has been applied to coral fringing and atoll reefs, in cooperation with and with funding by the University of Western Australia, the USGS and the Asian Development Bank. The model now also includes vegetative damping effects, with support of the U.S. Office of Naval Research.

The non-hydrostatic model has been developed initially by the TU Delft (as a prototype version of the SWASH model). For the purpose of simulating the morphodynamic processes on gravel beaches, the model was extended and validated with support from the University of Plymouth. In this mode, ship-induced waves can be simulated as well, demonstrating the flight that the model has taken since its first inception.

This development of XBeach could not have been possible without all of the above mentioned funding agencies and partners. It would also not have been possible without the enthusiastic, critical and constructive approach of all consultants, researchers, M.Sc. and Ph.D. students who have taken up XBeach, and made it into the tool that it is today.

This manual serves as an introduction to the model and a reference guide to its many functionalities, options and parameters. We sincerely hope that this document will help existing and new researchers apply the model for their purposes and advance our knowledge of coastal hydro- and morphodynamics.

# Processes and model formulation¶

## Domain and definitions¶

### Coordinate system¶

XBeach uses a coordinate system where the computational x-axis is always oriented towards the coast, approximately perpendicular to the coastline, and the y-axis is alongshore, see Fig. 1 and Fig. 2. This coordinate system is defined in world coordinates. The grid size in x- and y-direction may be variable but the grid must be curvilinear. Alternatively, in case of a rectangular grid (a special case of a curvilinear grid) the user can provide coordinates in a local coordinate system that is oriented with respect to world coordinates (xw, yw) through an origin (xori, yori) and an orientation (alfa) as depicted in Fig. 1. The orientation is defined counter-clockwise w.r.t. the xw-axis (East).

Fig. 1 Rectangular coordinate system of XBeach

### Grid set-up¶

The grid applied is a staggered grid, where the bed levels, water levels, water depths and concentrations are defined in cell centers, and velocities and sediment transports are defined in u- and v-points, viz. at the cell interfaces. In the wave energy balance, the energy, roller energy and radiation stress are defined at the cell centers, whereas the radiation stress gradients are defined at u- and v-points.

Velocities at the u- and v-points are denoted by the output variables uu and vv respectively; velocities u and v at the cell centers are obtained by interpolation and are for output purpose only. The water level, zs, and the bed level, zb, are both defined positive upward. uv and vu are the u-velocity at the v-grid point and the v-velocity at the u-grid point respectively. These are obtained by interpolation of the values of the velocities at the four surrounding grid points.

The model solves coupled 2D horizontal equations for wave propagation, flow, sediment transport and bottom changes, for varying (spectral) wave and flow boundary conditions.

Fig. 2 Curvilinear coordinate system of XBeach

## Hydrodynamics options¶

XBeach was originally developed as a short-wave averaged but wave-group resolving model, allowing resolving the short wave variations on the wave group scale and the long waves associated with them. Since the original paper by [RRvD+09] a number of additional model options have been implemented, thereby allowing users to choose which time-scales to resolve:

1. Stationary wave model (keyword: wavemodel = stationary), efficiently solving wave-averaged equations but neglecting infragravity waves;

2. Surfbeat mode (instationary) (keyword: wavemodel = surfbeat), where the short wave variations on the wave group scale (short wave envelope) and the long waves associated with them are resolved;

3. Non-hydrostatic mode (wave-resolving) (keyword: wavemodel = nonh), where a combination of the non-linear shallow water equations with a pressure correction term is applied, allowing to model the propagation and decay of individual waves.

In the following these options are discussed in more detail. Important to note that all times in XBeach are prescribed on input in morphological time. If you apply a morphological acceleration factor (keyword: morfac) all input time series and other time parameters are divided internally by morfac. This way, you can specify the time series as real times, and vary the morfac without changing the rest of the input files (keyword: morfacopt = 1).

Fig. 3 Principle sketch of the relevant wave processes

### Stationary mode¶

The stationary mode is implemented in mod:wave_stationary_module.

In stationary mode the wave-group variations and thereby all infragravity motions are neglected. This is useful for conditions where the incident waves are relatively small and/or short, and these motions would be small anyway. The model equations are similar to HISWA ([HBH89]) but do not include wave growth or wave period variations. Processes that are resolved are wave propagation, directional spreading, shoaling, refraction, bottom dissipation and wave breaking, and a roller model is included; these processes are usually dominant in nearshore areas of limited extent. For the breaking dissipation we use the [BHBvW98] model, which is valid for wave-averaged modeling. The radiation stress gradients from the wave and roller model force the shallow water equations, drive currents and lead to wave setdown and setup. Additionally, wind and tidal forcing can be applied.

The mean return flow due to mass flux and roller is included in the model and affects the sediment transport, leading to an offshore contribution. To balance this, effects of wave asymmetry and skewness are included as well. Bed slope effects can further modify the cross-shore behavior. A limited number of model coefficients allow the user to calibrate the profile shape resulting from these interactions.

A typical application would be to model morphological changes during moderate wave conditions, often in combination with tides. The wave boundary conditions can be specified as constant (keyword: wbctype = stat) or as a time-series of wave conditions (keyword: wbctype = stat_table). Typical examples of such model applications are given below for tombolo formation behind an offshore breakwater (left panel) and development of an ebb delta at a tidal inlet (right panel). A big advantage of the stationary XBeach wave model over other models is that the lateral boundaries are entirely without disturbance if the coast is longshore uniform near these boundaries.

Root-mean square wave height (left panels) and final bathymetry (right panels) for an offshore breakwater case (upper panels) and a tidal inlet with waves from 330 degrees (lower panels).

### Surf beat mode (instationary)¶

The surfbeat mode is implemented in mod:wave_instationary_module.

The short-wave motion is solved using the wave action equation which is a time-dependent forcing of the HISWA equations ([HBH89]). This equation solves the variation of short-waves envelope (wave height) on the scale of wave groups. It employs a dissipation model for use with wave groups ([Roe93][DRvD+12]) and a roller model ([Sve84][NRS90][SDeVriend94]) to represent momentum stored at the surface after breaking. These variations, through radiation stress gradients ([LHS62][LHS64]) exert a force on the water column and drive longer period waves (infragravity waves) and unsteady currents, which are solved by the nonlinear shallow water equations (e.g. [Phi77]). Thus, wave-driven currents (longshore current, rip currents and undertow), and wind-driven currents (stationary and uniform) for local wind set-up, long (infragravity) waves, and runup and rundown of long waves (swash) are included.

Using the surfbeat mode is necessary when the focus is on swash zone processes rather than time-averaged currents and setup. It is fully valid on dissipative beaches, where the short waves are mostly dissipated by the time they are near the shoreline. On intermediate beaches and during extreme events the swash motions are still predominantly in the infragravity band and so is the runup.

Under this surfbeat mode, several options are available, depending on the circumstances:

1. 1D cross-shore; in this case the longshore gradients are ignored and the domain reduces to a single gridline (keyword: ny = 0). Within this mode the following options are available:

#. Retaining directional spreading (keyword: dtheta < thetamax - thetamin); this has a limited effect on the wave heights because of refraction, but can also allow obliquely incident waves and the resulting longshore currents;

#. Using a single directional bin (keyword: dtheta = thetamax- thetamin); this leads to perpendicular waves always and ignores refraction. If the keyword snells = 1 is applied, the mean wave direction is determined based on Snells law. In this case also longshore currents are generated.

2. 2DH area; the model is solved on a curvilinear staggered grid (rectilinear is a special case). The incoming short wave energy will vary along the seaward boundary and in time, depending on the wave boundary conditions. This variation is propagated into the model domain. Within this mode the following options are available:

1. Resolving the wave refraction ‘on the fly’ using the propagation in wave directional space. For large directional spreading or long distances this can lead to some smoothing of groupiness since the waves from different directions do not interfere but their energy is summed up. This option is possible for arbitrary bathymetry and any wave direction. The user must specify the width of the directional bins for the surfbeat mode (keyword: dtheta)

2. Solving the wave direction at regular intervals using the stationary solver, and then propagating the wave energy along the mean wave direction. This preserves the groupiness of the waves therefore leads to more forcing of the infragravity waves (keyword: single_dir = 1). The user must now specify a single directional bin for the instationary mode (dtheta = thetamax - thetamin) and a smaller bin size for the stationary solver (keyword: dtheta_s).

3. For schematic, longshore uniform cases the mean wave direction can also be computed using Snells law (keyword: snells = 1). This will then give comparable results to the single_dir option.

In the figures below some typical applications of 1D and 2D models are shown; a reproduction of a large-scale flume test, showing the ability of XBeach to model both short-wave (HF) and long-wave (LF) wave heights and velocities; and a recent 2DH simulation ([NLB+15]) of the impact of hurricane Sandy on Camp Osborne, Brick, NJ.

Fig. 4 Computed and observed hydrodynamic parameters for test 2E of the LIP11D experiment. Top left: bed level and mean water level. Top right: measured (dots) and computed

Pre (left) and post-Sandy (right) in a three dimensional plot with both bed and water levels as simulated by XBeach ([NLB+15])

### Non-hydrostatic mode (wave resolving)¶

The non-hydrostatic mode is implemented in mod:nonh_module.

For non-hydrostatic XBeach calculations (keyword: wavemodel = nonh) depth-averaged flow due to waves and currents are computed using the non-linear shallow water equations, including a non-hydrostatic pressure. The depth-averaged normalized dynamic pressure () is derived in a method similar to a one-layer version of the SWASH model ([ZSS11]). The depth averaged dynamic pressure is computed from the mean of the dynamic pressure at the surface and at the bed by assuming the dynamic pressure at the surface to be zero and a linear change over depth.

Under these formulations dispersive behavior is added to the long wave equations and the model can be used as a short-wave resolving model. Wave breaking is implemented by disabling the non-hydrostatic pressure term when waves exceed a certain steepness, after which the bore-like breaking implicit in the momentum-conserving shallow water equations takes over.

In case the non-hydrostatic mode is used, the short wave action balance is no longer required. This saves computation time. However, in the wave-resolving mode we need much higher spatial resolution and associated smaller time steps, making this mode much more computationally expensive than the surfbeat mode.

The main advantages of the non-hydrostatic mode are that the incident-band (short wave) runup and overwashing are included, which is especially important on steep slopes such as gravel beaches. Another advantage is that the wave asymmetry and skewness are resolved by the model and no approximate local model or empirical formulation is required for these terms. Finally, in cases where diffraction is a dominant process, wave-resolving modeling is needed as it is neglected in the short wave averaged mode. The XBeach-G formulations for gravel beaches ([MMP+14]) are based on the non-hydrostatic mode. Although sandy morphology can be simulated using the wave-resolving mode, it has not been extensively validated and it is likely that changes in the sediment transport formulations will be implemented in the near future.

To improve the dispersive behaviour a (reduced) 2-layer non-hydrostatic is implemented as well ([dRSvD+21]). In this version (keyword: nhq3d = 1, see Section sec-twolayer), the pressure in the vertical is described by a hydrostatic pressure assumption in the bottom layer, and a non-hydrostatic distribution in the upper layer.

An interesting recent application that has been validated for a number of cases concerns the modeling of primary waves generated by large ships, see Ship-induced wave motions.

Fig. 5 Measured (black) and modeled (red) time series of overtopping during BARDEX experiment, from [MMP+14].

## Short wave action¶

### Short wave action balance¶

The short wave action balance is implemented in func:wave_instationary_module/wave_instationary.

The wave forcing in the shallow water momentum equation is obtained from a time dependent version of the wave action balance equation. Similar to Delft University (stationary) HISWA model ([HBH89]) the directional distribution of the action density is taken into account, whereas the frequency spectrum is represented by a frequency, best represented by the spectral parameter . The wave action balance (keyword: swave) is then given by:

(1)

In which the wave action is calculated as:

(2)

where represents the angle of incidence with respect to the x-axis, represents the wave energy density in each directional bin and the intrinsic wave frequency. The intrinsic frequency and group velocity is obtained from the linear dispersion relation. The intrinsic frequency is for example obtained with:

(3)

The wave action propagation speeds in , and directional space are given by:

(4)

where represents the local water depth and the wave number. The intrinsic wave frequency is determined without wave current interaction (keyword: wci = 1, see Section 2.3.1.1), which means it is equal to the absolute radial frequency .

#### Wave-current interaction (wci)¶

The wave-current interaction is implemented in func:wave_instationary_module/wave_instationary.

Wave-current interaction is the interaction between waves and the mean flow. The interaction implies an exchange of energy, so after the start of the interaction both the waves and the mean flow are affected by each other. This feature is especially of importance in gullies and rip-currents ([RMTS07]).

In XBeach this is taken into account by correcting the wave number with the use of Eikonal equations, which will have impact on the group and wave propagation speed (x, y, and directional space). The cross-shore and alongshore wave numbers, and , are defined according to equation (5). In these formulations the subscripts refer to the direction of the wave vector components.

(5)

Where subscript refers the wave number of the previous time step, and are the wave number corrections and and are the corrected wave numbers that take into account the presence of a current. The correction terms are determined with a second set of equations, the Eikonal equations:

(6)

The wave number is then given by:

(7)

The absolute radial frequency is calculated with:

(8)

where and are the cross-shore and alongshore depth-averaged Lagrangian velocities respectively. The wave action propagation speed (in x and y direction) is given by:

(9)

The propagation speed in directional () space, where bottom refraction (first term) and current refraction (last two terms) are taken into account, is obtained from:

(10)

### Dissipation¶

In XBeach there are three short wave dissipation processes that can be accounted for: wave breaking (), bottom friction () and vegetation (). The three processes are explained in more detail in the following subsections.

#### Wave breaking¶

Short wave dissipation by breaking is implemented in mod:roelvink_module.

Five different wave breaking formulations are implemented in XBeach. The formulations can be selected using the keyword break (Table 1).

Table 1 Different wave breaking formulations implemented

Wave breaking formula

Type of waves

keyword

Roelvink (1993a)

Instationary

roelvink1

Roelvink (1993a) extended

Instationary

roelvink2

Daly et al. (2010)

Instationary

roelvink_daly

Baldock et al. (1998)

Stationary

baldock

Janssen & Battjes (2007)

Stationary

janssen

For the surf beat approach the total wave energy dissipation, i.e. directionally integrated, due to wave breaking can be modeled according to [Roe93] (keyword: break = roelvink1). In the formulation of the dissipation due to wave breaking the idea is to calculate the dissipation with a fraction of breaking waves () multiplied by the dissipation per breaking event. In this formulation is applied as wave dissipation coefficient of O (keyword: alpha), is the representative wave period and is the energy of the wave. The fraction of wave breaking is determined with the root-mean-square wave height () and the maximum wave height (). The maximum wave height is calculated as ratio of the water depth () plus a fraction of the wave height (, keyword: delta) using a breaker index (keyword: gamma). In the formulation for the represents the water density and the gravitational constant. The total wave energy is calculated by integrating over the wave directional bins.

(11)

In variation of (11), one could also use another wave breaking formulation, presented in (12). This formulation is somewhat different than the formulation of [Roe93] and selected using keyword break = roelvink2. The main difference with the original formulation is that wave dissipation with break = roelvink2 is proportional to instead of .

(12)

Alternatively the formulation of [DRvD+10] states that waves are fully breaking if the wave height exceeds a threshold () and stop breaking if the wave height fall below another threshold (). This formulation is selected by break = roelvink_daly and the second threshold, , can be set using keyword gamma2.

(13)

In case of stationary waves [BHBvW98] is applied (keyword: break = baldock), which is presented in (14). In this breaking formulation the fraction breaking waves and breaking wave height are calculated differently compared to the breaking formulations used for the non-stationary situation. In is applied as wave dissipation coefficient, represents a representative intrinsic frequency and is a calibration factor.

(14)

Finally, it is possible to use the [JB07] formulation for wave breaking of stationary waves (keyword: break = janssen). This formulation is a revision of Baldock’s formulation.

(15)

In both the instationary or stationary case the total wave dissipation is distributed proportionally over the wave directions with the formulation in (16).

(16)

#### Bottom friction¶

Short wave dissipation by bottom friction is implemented in func:wave_instationary_module/wave_instationary.

The short wave dissipation by bottom friction is modeled as

(17)

In (17) the is the short-wave friction coefficient. This value only affects the wave action equation and is unrelated to bed friction in the flow equation. Studies conducted on reefs (e.g. [LFK+07]) indicate that should be an order of magnitude (or more) larger than the friction coefficient for flow () due to the dependency of wave frictional dissipation rates on the frequency of the motion.

The derivation of the short wave dissipation term is based time-averaged instantaneous bottom dissipation using the Johnson friction factor of the bed shear stress:

(18)

The evaluation of the term , the so-called third even velocity moment, depends on the situation. First we need expressions for the orbital velocity amplitude, which is expressed as:

(19)

In this formulation is the peak wave period, is the root-mean-square wave height, is the wave number and is the local water depth.

If we consider the slowly-varying dissipation in wave groups, we need only to average over a single wave period and we can use a monochromatic (regular wave) expression. If we want to have the time-average dissipation over a full spectrum we get the best approximation from considering a linear Gaussian distribution. [GT85] give pragmatic expressions for both cases.

For the monochromatic case:

(20)

For the linear Gaussian approximation:

(21)

Combining (18) and orbital-velocity-monochromatic we get:

(22)

In XBeach the orbital velocity amplitude is computed as in orbital-velocity-monochromatic and the dissipation according to (22), which is correct for the case of instationary simulations on wave-group scale.

For the stationary case formulations (18) and (21) are similarly combined into:

(23)

#### Vegetation¶

Short wave dissipation by vegetation is implemented in mod:vegetation_module.

The presence of aquatic vegetation within the area of wave propagation or wave breaking results in an additional dissipation mechanism for short waves. This is modeled using the approach of [ML04], which was adjusted by [SZB+12] to take into account vertically heterogeneous vegetation, see [vRVanTdVriesM+15]. The short wave dissipation due to vegetation is calculated as function of the local wave height and several vegetation parameters. The vegetation can be schematized in a number of vertical elements with each specific property. In this way the wave damping effect of vegetation such as mangrove trees, with a relatively dense root system but sparse stem area, can be modeled. The dissipation term is then computed as the sum of the dissipation per vegetation layer ([SZB+12]):

(24)

where is the dissipation by vegetation in vegetation layer and is the number of vegetation layers. The dissipation per layer is given by:

(25)

where is a (bulk) drag coefficient, is the vegetation stem diameter, is the vegetation density, and is the relative vegetation height (= ) for layer . In case only one vegetation layer is specified, the plants are assumed to be vertically uniform, which would for example typically apply in case of modeling sea grass.

Given the spatial distribution of the wave action (and therefore wave energy) the radiation stresses can be evaluated by using linear wave theory as described by:

(26)

### Wave shape¶

Wave shapes are implemented in func:morphevolution/RvR and func:morphevolution/vT.

The morphodynamic model considered is (short) wave averaged and resolves hydrodynamics associated with the wave group time scale. As a result the short wave shape is not solved for. However, as waves propagate from deep water onto beaches, their surface form and orbital water motion become increasingly non-linear because of the amplification of the higher harmonics.

There are two wave forms implemented to take this non-linearity into account:

1. A formulation of [RRvR12] based on a parameterization with the Ursell number. (keyword: waveform = ruessink_vanrijn)

2. A formulation of [vanTdVries09] based on the parameterized wave shape model of [RF81] (keyword: waveform = vanthiel)

The formulation of [RRvR12] relies on parameterizations for the non-linearity parameter and phase . The parameterizations are based on a data set of 30.000+ field observations of the orbital skewness and asymmetry , collected under non-breaking and breaking wave conditions. The only variable parameter is the Ursell number, since according to [RRvR12] the Ursell that includes , and , describes the variability in and well. The Ursell number is calculated with the equation below.

(27)

The value for the skewness and asymmetry is calculated with the use of a Boltzmann sigmoid. The skewness and asymmetry are a function of . In the formulation of [RRvR12] the are used as parameterized factors on the data set of field observations.

(28)

Alternatively, [vanTdVries09] utilized and extended the wave shape model of [RF81]. In this model the short wave shape is described by a Rienecker and Fenton lookup table with amongst others amplitudes non-linear components obtained with stream function theory. Therefore, wave skewness () and asymmetry ( is computed in each grid point based on the water depth, dimensionless wave height and dimensionless wave period.

For equals one a skewed (Stokes) wave is obtained with high peaks and flat troughs whereas equals zero results in an asymmetric (saw tooth) wave with steep wave fronts. It is hypothesized that the weighting can be expressed as a function of wave skewness and asymmetry. The relation between the phase and the weighting is studied in more detail by [vanTdVries09] by varying between zero and one in small steps and computing the amplitudes with Rienecker and Fenton for a range of wave heights, wave periods and water depths. It is found that a unique relation between and exists for any combination of wave height, wave period and water depth that is described by:

(29)

As explained in the next section, short-wave turbulence can be computed averaged over the bore interval (). The bore interval is directly related to the wave shape and hence requires the weighting function is determined. For the formulation of [RRvR12] no exact wave shape is determined and therefore no bore interval can be calculated. Therefore this approach cannot be combined with bore averaged short-wave turbulence.

### Turbulence¶

Wave breaking induced turbulence is implemented in func:morphevolution/waveturb.

Wave breaking induced turbulence at the water surface has to be transported towards the bed in order to affect the up-stirring of sediment. [RS89] used an exponential decay model with the mixing length proportional to to estimate the time averaged turbulence energy at the bed from turbulence at the water surface:

(30)

where is turbulence variance at the bed and is the time averaged turbulence variance at the water surface.

There are three possibilities for the turbulence variance at the bed () implemented into XBeach:

1. Wave averaged near-bed turbulence energy (keyword: turb = wave_averaged):

(31)

2. Bore-averaged near-bed turbulence energy 2 (keyword: turb = bore_averaged)

(32)

3. Not taking into account the turbulence variance at the bed (keyword: turb = none)

Both formulations make use of the wave-averaged turbulence energy () and a mixing length (). The wave averaged turbulence energy at the surface is computed from the roller energy dissipation and following [Bat75] in which is roller dissipation:

(33)

The mixing length () is expressed as thickness of the surface roller near the water surface and depends on the roller volume ([Sve84]):

(34)

### Roller energy balance¶

The roller energy balance is implemented in func:wave_instationary_module/wave_instationary.

While the short wave action balance adequately describes the propagation and decay of organized wave energy, it has often been found that there is a delay between the point where the waves start to break (which is where you would expect the strongest radiation stress gradients to occur) and the point where the wave set-up and longshore current start to build. This transition zone effect is generally attributed to the temporary storage of shoreward momentum in the surface rollers. Several authors have analyzed the typical dimensions of such rollers and their effect on the radiation stress (e.g. [LHT74], [Sve84], [RS89], [NRS90], [Dei93], [SDeVriend94]).

The rollers can be represented as a blob of water with cross-sectional area A that slides down the front slope of a breaking wave. The roller exerts a shear stress on the water beneath it equal to:

(35)

where is the slope of the breaking wave front, is the roller area and is the wave length. The roller has a kinetic energy equal to:

(36)

and a contribution to the radiation stress equal to:

(37)

We can now formulate an energy balance for the roller as follows:

(38)

where is the loss of organized wave motion due to breaking and is the dissipation. The latter is equal to the work done by the shear stress between the roller and the wave:

(39)

Given the complex motion in the breaking waves, we can only give approximate estimates of the order of magnitude of the parameters in equations (35) till (39). Various authors have suggested that the velocity in the roller can be approximated as purely horizontal and equal to the wave celerity . In that case we get (for waves travelling in x-direction):

(40)

However, this must be seen as an (unrealistic) upper limit on the radiation stress contribution as this can only be valid for . [NRS90] showed that the conceptual model of [RS89] would lead to a factor 0.22 instead of 2. However, a ratio in the order of 1 seems more realistic. [SDeVriend94] found a discrepancy between the roller shear stress derived from an energy balance and that derived from the momentum balance, in the order of a factor two. They explained this by a complicated analysis of the effect of water entering and leaving the roller, which led to a modification of the propagation term in the roller energy balance by a factor two. As this leads to the unphysical result that rollers would propagate at twice the wave celerity, we believe that the discrepancy must be sought in the ratio between roller energy and radiation stress contribution. Therefore we stick to the roller energy balance suggested by [NRS90] in equation (41) and the roller contribution to the radiation stress:

(41)

This leads to an elegant and consistent distribution of the wave-induced forcing through the surfzone. To close the roller energy balance we need to express the dissipation of the roller as a function of . This can be done by introducing:

(42)

Combining this with equations (36) and (42) we then find:

(43)

The coefficients and are usually lumped together into a single coefficient. This coefficient is in the O (keyword: beta), which may vary through the surf zone. The forcing of the longshore current by the radiation stress gradient can be derived from the wave and roller energy balances and :

(44)

In a longshore uniform situation, according to Snell’s law, the first term on the right-hand side equals zero; the second term exactly equals the sum of the wave energy dissipation and the roller energy input and dissipation terms, so the forcing term reduces to:

(45)

## Shallow water equations¶

The shallow water equations are implemented in func:flow_timestep_module/flow.

For the low-frequency waves and mean flows we use the shallow water equations. To account for the wave induced mass-flux and the subsequent (return) flow these are cast into a depth-averaged Generalized Lagrangian Mean (GLM) formulation ([AM78], [WRG00]). In such a framework, the momentum and continuity equations are formulated in terms of the Lagrangian velocity which is defined as the distance a water particle travels in one wave period, divided by that period. This velocity is related to the Eulerian velocity (the short-wave-averaged velocity observed at a fixed point) by:

(46)

where and represent the Stokes drift in x- and y-direction respectively ([Phi77]). The Strokes drift is calculated with in which the wave-group varying short wave energy and direction are obtained from the wave-action balance.

(47)

The resulting GLM-momentum equations are given by:

(48)

where and are the wind shear stresses, and are the bed shear stresses, is the water level, and are the wave-induced stresses, , and are the stresses induced by vegetation, is the horizontal viscosity and is the Coriolis coefficient. Note that the shear stress terms are calculated with the Eulerian velocities as experienced by the bed and not with the GLM velocities, as can be seen in .

### Horizontal viscosity¶

The Smagorinsky model is implemented in func:flow_timestep_module/visc_smagorinsky.

The horizontal viscosity () is by default computed using the [Sma63] model to account for the exchange of horizontal momentum at spatial scales smaller than the computational grid size, which is given as:

(49)

In is the Smagorinsky constant (keyword: nuh), set at 0.1 in all model simulations. It is also possible to use a user-defined value for the horizontal viscosity by turning off the Smagorinsky model (keyword: smag = 0) and specifying the value directly (also keyword: nuh).

### Bed shear stress¶

Bed shear stresses are implemented in mod:bedroughness_module.

The bed friction associated with mean currents and long waves is included via the formulation of the bed shear stress (). Using the approach of [RMF+01] the bed shear stress is calculated with:

(50)

There are 5 different formulations in order to determine the dimensionless bed friction coefficient (keyword: bedfriction) implemented in XBeach (Table 2).

Table 2 Different bed friction formulations implemented

Bed friction formulation

Relevant coefficient

keyword

Dimensionless friction coefficient

cf

Chezy

C

chezy

Manning

n

manning

White-Colebrook

white-colebrook

White-Colebrook grain size

D90

white-colebrook-grainsize

The dimensionless friction coefficient can be calculated from the Chezy value with equation (51). A typical Chezy value is in the order of .

(51)

In the Manning formulation the Manning coefficient () must be specified. The dimensionless friction coefficient is calculated from equation (52). Manning can be seen as a depth-dependent Chezy value and a typical Manning value would be in the order of .

(52)

In the White-Colebrook formulation the geometrical roughness of Nikuradse () must be specified. The dimensionless friction coefficient is calculated from equation (53) The White-Colebrook formulation has al log relation with the water depth and a typical value would be in the order of 0.01 - 0.15 m.

(53)

The option of White-Colebrook based on the grain size is somewhat different than the other four formulations. This formulation is based on the relation between the of the top bed layer and the geometrical roughness of Nikuradse according to equation (54). The user does not have to specify a value for the bed friction coefficient.

(54)

Values of the drag coefficient for different seabed sediment grain sizes (flat beds) and similarly for bed form scenarios have been empirically derived from field and laboratory data in previous studies for different bed friction coefficients. The value of the friction coefficient (, , or ) can be defined with one single value (keyword: bedfriccoef) or for a separate value per grid cell (keyword: bedfricfile).

In XBeach-G, the bed shear stress is described in terms of a drag and an inertia component. This approach allows the effect of acceleration on sediment transport to be explicitly taken into account in the bed shear stress, rather than in a modification of the effective Shields parameter.

(55)

where and are bed shear stress terms due to drag and inertia, respectively. Note that the inertia component of the bed shear stress does not represent the actual inertia of the particles, but refers to the force on particles in the bed due to pressure gradients, as well as due to the disturbance of the accelerating flow, following potential flow theory.

The bed shear stress due to drag is computed with the XBeach-G default of White-Colebrook grain size (keyword: bedfriction=white-colebrook-grainsize). The bed friction factor is computed following the description of [Con94] to account for modified bed shear stress due to ventilated boundary layer effects in areas of infiltration and exfiltration

(56)

Bed shear due to inertia effects (keyword: friction_acceleration) is computed through analogy with the force exerted by water on a sphere in non-stationary flow. In this case, the force on an object due to inertia can be computed from the local flow acceleration:

(57)

where is an inertia coefficient, is the added mass coefficient for spheres with zero autonomous acceleration),:math:c_{v} is the volume shape factor ( for spheres) and is the characteristic grain size. Note that the inertial force is therefore the sum of the Froude Krylov force and the hydrodynamic mass force . For the purpose of XBeach-G, the shear stress on the bed due to inertia is computed by assuming the characteristic grain size to be the median sediment grain size and the number of grains affected by flow acceleration per unit area to scale with such that:

(58)

XBeach-G supports two different formulation to compute the bed shear due to inertia effects (keyword: friction_acceleration): the McCall equation and the Nielsen equation. In the case of the McCall equation (keyword: friction_acceleration = McCall), ROBERT. In the case of the Nielsen equation (keyword: friction_acceleration = Nielsen), ROBERT.

### Damping by vegetation¶

Infra-gravity wave damping by vegetation is implemented in mod:vegetation_module.

The presence of aquatic vegetation within the area of wave propagation or wave breaking may not only result in short wave dissipation (Dissipation), but also in damping of infragravity waves and/or mean flow. Since both long waves and mean flow are fully resolved with the nonlinear shallow water equations, the effect of vegetation can be modeled using a drag force (e.g. [DKH84]), which can be directly added to the momentum equations ([vRVanTdVriesM+15], equation (48)):

(59)

Where is a drag coefficient, is the vegetation stem diameter, is the vegetation density and is the wave or current related velocity. To take into account the velocity due to mean flow and infragravity waves, we use the Lagrangian velocity () here. The vegetation-induced time varying drag force is then calculated as the sum of the vegetation-induced drag force per vegetation layer:

(60)

where is a (bulk) drag coefficient, is the vegetation stem diameter, is the vegetation density, and is the vegetation height for layer .

### Porous in-canopy flow¶

To include the resistance of corals in the simulations or when the in-canopy velocity is required, the porous in-canopy model can be applied. This model computes the flow though the coral canopy, based on the porosity () and canopy height (). The in-canopy cell is formulated within the flow grid-cell, which means that the forcing of the flow is used as forcing terms in the canopy cell. The horizontal in-canopy momentum equation, derived by , is given as,

(61)

Where is the dimensional plan area (), the canopy height, the kinematic viscosity, the laminar permeability, a drag coefficient and an empirical friction factor. Based on the in-canopy flow, the canopy-induced force (on the mean flow) can be derived. This canopy-induced force is given as,

(62)

This canopy-induced force is included in the horizontal momentum equation (48) to represent the resitsance of the corals. For emergent corals, the canopy height is bounded by the water depth.

### Wind¶

The first term on the right hand side of the momentum equations (equation (48)) represents the forcing due to the wind stress. These forcing terms due to the wind are formulated as:

(63)

where is wind stress, is density of air, is the wind drag the coefficient, is the wind velocity. The wind stress is turned off by default, and can be turned on specifying a constant wind velocity (keyword: windv) or by specifying a time varying wind file.

### Rainfall (beta feature)¶

It is possible to include rainfall in the simulation. Based on a constant or temporally- and/or spatially-varying rainfall rate (), the continuity equation is given by,

(64)

Note that this functionality is a beta feature and not fully tested.

## Non-hydrostatic pressure correction¶

The non-hydrostatic pressure correction is implemented in mod:nonh_module.

For non-hydrostatic XBeach calculations (keyword: waveform = nonh) depth-averaged flow due to waves and currents are computed using the non-linear shallow water equations, including a non-hydrostatic pressure. The non-hydrostatic model accounts for all wave motions (including short waves) within the shallow water equations, so the wave action balance should be turned off (keyword: swave = 0). The depth-averaged normalized dynamic pressure () is derived in a method similar to a one-layer version of the SWASH model ([ZSS11]). The depth averaged dynamic pressure is computed from the mean of the dynamic pressure at the surface and at the bed by assuming the dynamic pressure at the surface to be zero and a linear change over depth. In order to compute the normalized dynamic pressure at the bed, the contributions of advective and diffusive terms to the vertical momentum balance are assumed to be negligible.

(65)

In is the vertical velocity and is the vertical coordinate. The vertical velocity at the bed is set by the kinematic boundary condition:

(66)

Combining the Keller-box method ([LS76]), as applied by [SZ03] for the description of the pressure gradient in the vertical, the dynamic pressure at the bed can be described by:

(67)

Substituting in allows the vertical momentum balance at the surface to be described by:

(68)

In the subscript refers to the location at the surface. The dynamic pressure at the bed is subsequently solved by combining and the local continuity equation:

(69)

In order to improve the computed location and magnitude of wave breaking, the hydrostatic front approximation (HFA) of [SJHS14] is applied, in which the pressure distribution under breaking bores is assumed to be hydrostatic. Following the recommendations of [SJHS14], we consider hydrostatic bores if and reform if . The values can respectively be changed with the keywords maxbrsteep and secbrsteep.

Although this method greatly oversimplifies the complex hydrodynamics of plunging waves, [MMP+14] shows that the application of this method provides sufficient skill to describe dominant characteristics of the flow, without requiring computationally expensive high-resolution discretization of the vertical and surface tracking of overturning waves.

## Reduced two layer model (nh+)¶

The non-hydrostatic pressure correction is implemented in mod:nonh_module.

The reduced two layer model was implemented to improve the dispersive behaviour of the non-hydrostatic model (keyword: par:nhq3d). Due to the additional layer, frequency dispersion is more accurately modelled than with the depth-averaged formulation. Mostly, the addition of an extra layer will increase the computational time significantly, but a simplified (reduced) lower layer is applied to reduce the extra computational effort. It is assumed that the non-hydrostatic pressure is constant in the lower layer. This means that the non-hydrostatic pressure at the bottom has the same value as the non-hydrostatic pressure between the layers. Still the non-hydrostatic pressure at the surface is zero, which means that for every location in the domain there is one non-hydrostatic unknown.

To make the simplification of the reduced layer, the layer velocities are transformed to a depth-averaged velocity and a velocity difference according to,

(70)

Where is the layer distribution. Then, the momentum equations for , and are given by,

(71)

(72)

(73)

Due to the simplified non-hydrostatic pressure in the lower layer, the vertical velocity between the layers is neglected. Thus, only the continuity relation for the upper layer is required. This relation in terms of the reduced two layer formulation is given as,

(74)

To determine the water elevation, the global continuity equation is applied,

(75)

These equatuons are used to solve , , and

When using the reduced two layer model, the model is forced with both and . Linear wave theory is used to generate the layer-averaged velocities, which can be transformed to and by applying equation (70).

## Groundwater flow¶

Groundwater flow is implemented in mod:groundwaterflow.

The groundwater module (keyword: gwflow = 1) in XBeach utilizes the principle of Darcy flow for laminar flow conditions and a parameterization of the Forchheimer equations for turbulent groundwater flow. The module includes a vertical interaction flow between the surface water and groundwater. This flow is assumed to be a magnitude smaller than the horizontal flow and is not incorporated in the momentum balance.

### Continuity¶

In order to solve mass continuity in the groundwater model, the groundwater is assumed to be incompressible. Continuity is achieved by imposing a non-divergent flow field:

(76)

where is the total specific discharge velocity vector, with components in the horizontal (, ) and vertical () direction:

(77)

### Equation of motions¶

Laminar flow of an incompressible fluid through a homogeneous medium can be described using the well-known Law of [Dar56], valid for laminar flow conditions (keyword: gwscheme = laminar)

(78)

in which is the hydraulic conductivity of the medium (keyword: , , for each horizontal and vertical direction) and is the hydraulic head.

In situations in which flow is not laminar, turbulent and inertial terms may become important. In these cases the user can specify XBeach to use a method (keyword: gwscheme = turbulent) that is comparable with the USGS MODFLOW-2005 groundwater model ([Har05]), in which the turbulent hydraulic conductivity is estimated based on the laminar hydraulic conductivity () and the Reynolds number at the start of turbulence () ([Hal00]):

(79)

In the Reynolds number () is calculated using the median grain size (), the kinematic viscosity of water () and the groundwater velocity in the pores (), where is the porosity. Similar expressions exist for the other two components of the groundwater flow.

The critical Reynolds number for the start of turbulence () is specified by the user, based on in-situ or laboratory measurements, or expert judgment (keyword: gwReturb). Since the hydraulic conductivity in the turbulent regime is dependent on the local velocity, an iterative approach is taken to find the correct hydraulic conductivity and velocity.

#### Determination of the groundwater head¶

The XBeach groundwater model allows two methods to determine the groundwater head: a hydrostatic approach (keyword: gwnonh = 0) and a non-hydrostatic approach (keyword: gwnonh = 1).

Hydrostatic approach

In the hydrostatic approach, the groundwater head is computed as follows:

1. In cells where there is no surface water the groundwater head is set equal to the groundwater surface level .

2. In cells where there is surface water, but the groundwater surface level is more than (keyword: dwetlayer) below the surface of the bed, the groundwater head is set equal to the groundwater surface level.

3. In cells where there is surface water and the groundwater surface level is equal to the surface of the bed, the groundwater head is set equal to the surface water level.

4. In cells where there is surface water and the groundwater surface level is equal to or less than below the surface of the bed, the groundwater head is linearly weighted between that of the surface water level and the groundwater level, according to the distance from the groundwater surface to the surface of the bed.

It should be noted that the numerical parameter is required to ensure numerical stability of the hydrostatic groundwater model. Larger values of will increase numerical stability, at the expense of numerical accuracy.

Non-hydrostatic approach

Groundwater flow in the swash and surf zone has been shown to be non-hydrostatic (e.g., [LB00]; [LMHK07]). In order to capture this, it may be necessary in certain cases to reject the Dupuit–Forchheimer assumption of hydrostatic groundwater pressure.

In the non-hydrostatic approach, the groundwater head is not assumed to be constant in the vertical. Since XBeach is depth-averaged, the model cannot compute true vertical profiles of the groundwater head and velocity. In order to estimate of the groundwater head variation over the vertical, a quasi-3D modeling approach is applied, which is set by two boundary conditions and one non-hydrostatic shape assumption:

1. There is no exchange of groundwater between the aquifer and the impermeable layer below the aquifer.

2. The groundwater head at the upper surface of the groundwater is continuous with the head applied at the groundwater surface.

3. The shape of the non-hydrostatic head profile is parabolic (keyword: gwheadmodel = parabolic), implying that the vertical velocity increases or decreases linearly from the bottom of the aquifer to the upper surface of the groundwater, or the non-hydrostatic head profile is hyperbolic (keyword: gwheadmodel = exponential), cf., [RGE99].

The vertical groundwater head approximation can be solved for the three imposed conditions by a vertical head function, shown here for the parabolic head assumption. The depth-average value of the groundwater head is used to calculate the horizontal groundwater flux and is found by integrating the groundwater head approximation over the vertical:

(80)

In the mean vertical ground water head () is calculated using the groundwater head imposed at the groundwater surface (), the groundwater head parabolic curvature coefficient () and the height of the groundwater level above the bottom of the aquifer ().

The unknown curvature coefficient () in the vertical groundwater head approximation is solved using the coupled equations for continuity and motion (equations (76) and (78)), thereby producing the depth-average horizontal groundwater head gradients and vertical head gradients at the groundwater surface.

Although the requirement for non-hydrostatic pressure has the benefit of being a more accurate representation of reality, and does not require the numerical smoothing parameter , resolving the non-hydrostatic pressure field can be computationally expensive, particularly in 2DH applications.

#### Exchange with surface water¶

In the groundwater model there are three mechanisms for the vertical exchange of groundwater and surface water: 1) submarine exchange, 2) infiltration and 3) exfiltration. The rate of exchange between the groundwater and surface water () is given in terms of surface water volume, and is defined positive when water is exchanged from the surface water to the groundwater.

Infiltration and exfiltration can only occur in locations where the groundwater and surface water are not connected. Infiltration takes place when surface water covers an area in which the groundwater level is lower than the bed level. The flux of surface water into the bed is related to the pressure gradient across the wetting front.

(81)

In equation (81) the surface water-groundwater exchange flow of infiltration () is calculated using the effective hydraulic conductivity (), the surface water pressure at the bed () and the thickness of the wetting front ().

Since the groundwater model is depth-averaged and cannot track multiple layers of groundwater infiltrating into the bed, the wetting front thickness is reset to zero when there is no available surface water, the groundwater exceeds the surface of the bed, or the groundwater and the surface water become connected. In addition, all infiltrating surface water is instantaneously added to the groundwater volume, independent of the distance from the bed to the groundwater table. Since the groundwater model neglects the time lag between infiltration at the beach surface and connection with the groundwater table a phase error may occur in the groundwater response to swash dynamics

Exfiltration () occurs where the groundwater and surface water are not connected and the groundwater level exceeds the bed level. The rate of exfiltration is related to the rate of the groundwater level exceeding the bed level.

(82)

Submarine exchange () represents the high and low frequency infiltration and exfiltration through the bed due pressure gradients across the saturated bed. This process only takes place where the groundwater and surface water are connected. In the case of the non-hydrostatic groundwater model, the rate of submarine exchange is determined by the vertical specific discharge velocity at the interface between the groundwater and surface water. The value of this velocity can be found using the vertical derivative of the approximated groundwater head at the groundwater-surface water interface (shown for the parabolic head approximation).

(83)

In the case of the hydrostatic groundwater model, the difference between the surface water head and the groundwater head is used to drive submarine discharge when the groundwater level is less than from the bed surface.

While most beach systems can acceptably described through vertical exchange of surface water and groundwater, in cases of very steep permeable slopes (e.g., porous breakwaters), it is necessary to include the horizontal exchange of groundwater and surface water between neighboring cells (keyword: gwhorinfil = 1). In this case the horizontal head gradient between the surface water and groundwater across vertical interface between the cells is used to determine the horizontal exchange flux:

(84)

where is the head gradient between the surface water and groundwater in neighboring cell, is the gradient distance, defined as the numerical grid size, and is the surface area through which the exchange takes place, defined as the difference in bed level between the neighboring cells.

#### Calculation of groundwater and surface water levels¶

Groundwater levels are updated through the continuity relation:

(85)

In these same areas the surface water level is modified to account for exchange fluxes:

(86)

#### Boundary conditions¶

Since the groundwater dynamics are described by a parabolic equation, the system of equations requires boundary conditions at all horizontal and vertical boundaries, as well as an initial condition:

1. A zero flux condition is imposed at the horizontal boundaries and bottom of the aquifer.

2. The initial condition for the solution is specified by the model user in terms of the initial groundwater head (keyword: gw0, or gw0file).

## Sediment transport¶

Sediment transport is implemented in func:morphevolution/transus.

Sediment concentrations in the water column are modeled using a depth-averaged advection-diffusion scheme with a source-sink term based on equilibrium sediment concentrations ([GV83]):

(87)

In represents the depth-averaged sediment concentration which varies on the wave-group time scale and is the sediment diffusion coefficient. The entrainment of the sediment is represented by an adaptation time , given by a simple approximation based on the local water depth and sediment fall velocity . A small value of corresponds to nearly instantaneous sediment response. The adaptation time is limited with a minimum period () which is defined as a factor (dtlimts) times the timestep. The factor is a correction and calibration factor to take into account the fact that is determined on depth-averaged data (keyword: tsfac).

(88)

The entrainment or deposition of sediment is determined by the mismatch between the actual sediment concentration and the equilibrium concentration thus representing the source term in the sediment transport equation.

The sediment transport rate, required for the bed level update, is defined as (shown for the x-direction),

### General parameters¶

In the sediment transport formulations, the equilibrium sediment concentration (for both the bed load and the suspended load) is related to the velocity magnitude (), the orbital velocity () and the fall velocity (). This section elaborates how these are calculated. Important to note: XBeach calculates the equilibrium concentration for the bed and suspended load separately.

First of all the Eulerian , if long wave stirring is turned on (keyword: lws = 1), the velocity magnitude is equal to the magnitude of the Eulerian velocity, as can be seen in .

(89)

If wave stirring is turned off (keyword: lws = 0), the velocity magnitude will be determined by two terms: first of all a factor of the velocity magnitude of the previous time step () and secondly a current-averaged part. Averaging will be carried out based on a certain factor (keyword: cats) of the representative wave period .

(90)

Secondly, the , the is obtained from the wave group varying wave energy using linear wave theory. In this formulation is the representative wave period and the is the root-mean-square wave height. In this equation the water depth is enhanced with a certain factor of the wave height (keyword: delta).

(91)

To account for wave breaking induced turbulence due to short waves, the orbital velocity is adjusted ([vanTdVries09]). In this formulation is the wave breaking induced turbulence due to short waves. The turbulence is approximated with an empirical formulation in XBeach.

(92)

Thirdly, the , the is calculated using the formulations of [Ahr00] which are derived based on a relationship suggested by [Hal81]:

(93)

(94)

(95)

For high sediment concentrations, the fall velocity is reduced (keyword: fallvelred = 1) using the expression of [RZ54]:

(96)

The exponent a is estimated using the equation of [Row87], which depends purely on the Reynolds particle number R:

(97)

(98)

### Transport formulations¶

The sediment transport formulations are implemented in func:sedtransform

In the present version of XBeach, two sediment transport formulations are available. The formulae of the two formulations are presented in the following sections. For both methods the total equilibrium sediment concentration is calculated with equation (99). In this equation the minimum value of the equilibrium sediment concentration (for both bed load en suspended load) compared to the maximum allowed sediment concentration (keyword: cmax).

(99)

The transport formulations implemented into XBeach distinguishes bed load and suspended load transport. It is possible to in- and exclude these transports components (keywords: bed & sus, with bed = 1 will include bed load transport). There is also a possibility to compute the total bulk transport rather than bed and suspended load separately (keyword: bulk = 1). The bed load will be calculated if it is suspended transport. On top of that this switch will have impact on how the bed slope effect (see Section 2.7.6) will be calculated

#### Soulsby-Van Rijn¶

The first possible sediment transport formulation are the Soulsby-Van Rijn equations (keyword: form = soulsby_vanrijn) ([Sou97]; [vR85]). The equilibrium sediment concentrations are calculated according to:

(100)

For which the bed load and suspended load coefficients are calculated with:

(101)

In which the dimensionless sediment diameter (D*) can be calculated with the following formulation. The is the kinematic viscosity based on the expression of Van Rijn and is a function of the water temperature. XBeach assumes a constant temperature of 20 degrees Celsius, this result in a constant kinematic viscosity of .

(102)

The critical velocity () defines at which depth averaged velocity sediment motion is initiated:

(103)

Finally the drag coefficient () is calculated with equation (104). A drag coefficient is used to determine the equilibrium sediment concentrations. On top of that [Sou97] gives a relation between the bed shear stress of the depth-averaged current speed.

(104)

In this equation is used for the bed roughness length and is used as zero flow velocity level in the formulation of the sediment concentration. In XBeach this is a fixed value (keyword: z0), but [Sou97] argues there is a relation between the Nikuradse and kinematic viscosity.

#### Van Thiel-Van Rijn¶

The second possible sediment transport formulation are the Van Thiel-Van Rijn transport equations (keyword: form = vanthiel_vanrijn) ([vR07]; [vanTdVries09]). The major difference between the Soulsby - Van Rijn equations is twofold. First of all, there is no drag coefficient calculated anymore and secondly the critical velocity is determined by calculating separately the critical velocity for currents () according to [Shi36] and for waves () according to [KM75].

The equilibrium sediment concentrations are calculated according to

(105)

(106)

The critical velocity is computed as weighted summation of the separate contributions by currents and waves ([vR07]):

(107)

The critical velocity for currents is based on [Shi36]:

(108)

The critical velocity for waves is based on [KM75]:

(109)

#### Van Rijn (1993)¶

The third possible sediment transport formulation are the Van Rijn (1993 equations (keyword: form = vanrijn1993) Van Rijn (1993) distinguishes between sediment transport below the reference height at which sediment is treated as bed-load transport and above the reference height which is treated as suspended-load.

The bed-load transport is computed with

(110)

In which the sediment mobility number due to waves and currents ( () ) can be calculated with the following formulation with () being the effective velocity. The excess sediment mobility number ( () ) is computed with the difference between the effective and critical velocity ( () ).

(111)

For the suspended-load, first the reference concentration is calculated in accordance with ([VanRijn84])

(112)

Secondly, the concentration profile is resolved by calculating the bed-shear stresses due to waves and currents and estimating the concentration profile where the combined bed shear stress exceeds the critical bed shear stress. Depth-averaged mixing due to waves and currents.

#### Implementation of increased sediment grain size dependency¶

The default sediment transport relations in XBeach are not greatly sensitive to the sediment grain size (equilibrium sediment concentration approximately proportional to and bed load transport approximately proportional to . Addition processes such as infragravity waves and wave turbulence often further decrease the sensitivity of the model morphodynamics to the grain size.

To increase model sensitivity to grain size, a calibration term on the equilibrium sediment concentration and nonlinear wave-driven transport has been developed based on the work of [Ste93].

The increased grain size sensitivity in this approach is achieved firstly by updating the equilibrium concentration at each time step, such that this concentration becomes relatively larger for small grain sizes, and smaller of large grain sizes:

(113)

In which is the updated equilibrium concentration, is a fixed reference grain size, and is a calibration factor for the sensitivity set by keyword alfaD50.

The sensitivity to grain size is secondly increased through a modification of the effective sediment transport velocity in the direction of the waves due to nonlinear wave effects ( , see Section sec-effects-of-wave-non-linearity ):

(114)

In which is the updated effective transport velocity. In this approach, the effective transport velocity in the direction of the waves increases (i.e., greater onshore transport) for grainsizes greater than , and decreases for grain sizes smaller than . By default, alfaD50 is set to 0, which means that the sediment transport rate is computed without increased grain size sensitivity.

#### Gravel formulations¶

In XBeach-G, gravel sediment transport is, by default, computed using the bed load transport equation of [vR07], excluding coefficients for silt:

(115)

where is the volumetric bed load transport rate (excluding pore space), , is the non-dimensional grain size, and is the critical Shields parameter for the initiation of transport, in this thesis computed using the relation of [Sou97].

(116)

In the case of the Nielsen equation is applied, the sediment transport model is modified slightly from that presented in Chapter ref{chap:Morphodynamics}. In this model the total gravel sediment transport is computed using a modification of the citet{Meyer-Peter1948} equation for bed load transport derived by citet{Nielsen2002}:

(117)

Besides the McCall - Van Rijn and the Nielsen equation there are several other sediment gravel transport formulae implemented in XBeach-G. For more information on XBeach-G, download the PhD thesis of McCall (2015) on URL: http://hdl.handle.net/10026.1/3929.

Table 3 Sediment gravel transport formulae implemented in XBeach-G

Sediment transport formulae

keyword

McCall - Van Rijn

mccall_vanrijn

Nielsen (2006)

nielsen2006

Wilcock & Crow

wilcock_crow

Engelund & Fredsoe

engelund_fredsoe

Meyer-Peter & Muller

mpm

Wong & Parker

wong_parker

Fernandez Luque & van Beek

fl_vb

Fredoe & Deigaard

fredsoe_deigaard

### Effects of wave non-linearity¶

Effects of wave skewness and asymmetry are accounted for in the advection-diffusion equation, repeated here:

(118)

XBeach considers the wave energy of short waves as averaged over their length, and hence does not simulate the wave shape. A discretization of the wave skewness and asymmetry was introduced by [vanTdVries09], to affect the sediment advection velocity. In this equation is calculated as function of wave skewness (), wave asymmetry parameter (), root-mean square velocity and two calibration factor and (keyword: facSk & facAs), see equation (119). To set both values one can use the keyword: facua. The method to determine the skewness and asymmetry is described in section 2.3.4. A higher value for will simulate a stronger onshore sediment transport component.

(119)

### Hindered erosion by dilatancy¶

Under overwash and breaching conditions (high flow velocities and large bed level variations in time), dilatancy might hinder the erosion rates ([dV14]). To account for this effect, the theory of [vR10] could be applied (keyword: dilatancy = 1), reducing the critical Shields parameter at high flow velocities:

(120)

In this equation, refers to the erosion velocity, is the permeability, is the porosity prior, is the porosity in the sheared zone (keyword: pormax) and the parameter (keyword: rheeA) is equal to 3/4 for single particles and approximately 1.7 for a continuum.

The larger the permeability of the bed, the smaller the dilatancy effect. [vR10] suggests using the equation proposed by [dA87]:

(121)

Finally, the erosion velocity , is the velocity at which the bottom level decreases:

(122)

### Bed slope effect¶

The bed slope affects the sediment transport in various ways ([WvRVanOrmondt+07]):

1. The bed slope influences the local near-bed flow velocity;

2. The bed slope may change the transport rate once the sediment is in motion;

3. The bed slope may change the transport direction once the sediment is in motion;

4. The bed slope will change the threshold conditions for initiation of motion.

The influence of the bed slope on the local hydrodynamics is not considered in XBeach.

Two possible expressions are implemented to change the magnitude of the sediment transport. The first method is the default one in XBeach:

(123)

This method could be applied on either the total sediment transport (keyword: bdslpeffmag = roelvink_total) or only on the bed load transport (keyword: bdslpeffmag = roelvink_bed). The second method is based on the engineering formula of [Sou97]:

(124)

Also this method could be applied on the total transport (keyword: bdslpeffmag = soulsby_total) or on the bed load transport only (keyword: bdslpeffmag = soulsby_total). To change the direction of the bed load transport, the expressions of [vB47] and [TvMS95] could be used (keyword: bdslpeffdir = talmon):

(125)

(126)

(127)

Finally, it is possible to adjust the initiation of motion criteria for the total transport (keyword: bdslpeffini = total) or the bed load transport only (keyword: bdslpeffini = bed) through ([Sou97]):

(128)

In this equation is the difference in angle between the flow direction and the on-slope directed vector, the bed slope and the angle of repose.

[dV14] provides a detailed overview on how the bed slope and flow direction are calculated and how the bed slope effect is combined with the dilatancy concept if the adjustment to the initiation of motion is considered.

It is also possible to prescribe a given bed slope. The result is that the swash zone profile is teased towards a given bermslope. This functionality Works in surfbeat mode (where H/h>1) and in stationary mode (where h<1m) and have been tested for profiles Praia de Faro (keyword: bermslope = desired slope).

In XBeach-G, bed slope effects on sediment transport are included by changing the effective Shields parameter is modified according to [Fre92]:

(129)

where is the local angle of the bed, is the angle of repose of the sediment (approximately 30-40), and the right-hand term is less than 1 for up-slope transport, and greater than 1 for down-slope transport.

## Bottom updating¶

Bed updating is implemented in func:morphevolution/bed_update.

### Due to sediment fluxes¶

Based on the gradients in the sediment transport the bed level changes according to:

(130)

In is the porosity, (keyword: morfac) is a morphological acceleration factor of O(1-10) ([RRT04]) and and represent the sediment transport rates in x- and y-direction respectively. Sediment transport can be activated with the keyword: sedtrans.

The morphological acceleration factor speeds up the morphological time scale relative to the hydrodynamic timescale. It means that if you have a simulation of 10 minutes with a morfac of 6 you effectively simulate the morphological evolution over one hour. There are now two ways in which you can input the time-varying parameters in combination with morfac:

1. All times are prescribed on input in morphological time. If you apply a morfac all input time series and other time parameters are divided internally by morfac. This is determined with keyword morfacopt = 1. If you now specify a morfac of 6, the model just runs for 10 (hydrodynamic) minutes each hour, during which the bottom changes per step are multiplied by a factor 6. This of course saves a factor of 6 in computation time.

This method is appropriate for short-term simulations with extreme events. This approach is only valid as long as the water level changes that are now accelerated by morfac do not modify the hydrodynamics too much. This is the case if the tide is perpendicular to the coast and the vertical variations do not lead to significant currents. If you have an alongshore tidal current, as is the case in shallow seas, you cannot apply this method because you would affect the inertia terms and thus modify the tidal currents.

1. Alternatively you run the model over, say, over a tidal cycle, and apply the morfac without modifying the time parameters. This means you leave all the hydrodynamic parameters unchanged and just exaggerate what happens within a tidal cycle. As long as the evolution over a single tidal cycle is limited, the mean evolution over a tidal cycle using a morfac is very similar to running morfac tidal cycles without morfac. See [Roe06] for a more detailed description of this approach. This option is enabled with keyword: morfacopt = 0.

This method is more appropriate for longer-term simulations with not too extreme events.

### Avalanching¶

To account for the slumping of sandy material from the dune face to the foreshore during storm-induced dune erosion avalanching (keyword: avalanching) is introduced to update the bed evolution. Avalanching is introduced via the use of a critical bed slope for both the dry and wet area (keyword: wetslp and dryslp). It is considered that inundated areas are much more prone to slumping and therefore two separate critical slopes for dry and wet points are used. The default values are 1 and 0.3 respectively. When this critical slope is exceeded, material is exchanged between the adjacent cells to the amount needed to bring the slope back to the critical slope.

(131)

To prevent the generation of large shockwaves due to sudden changes of the bottom level, bottom updating due to avalanching has been limited to a maximum speed, defined by a characteristic length and time scale. This speed is found by distributing the vertical change in bed level required to fulfill the criterium for the critical slope over the characteristic time scale (avaltime). This avaltime is proportional to the trep by the nTrepAvaltime parameter. Moreover, to remove grid size dependency, the bed level change is scaled with a ratio between the infragravity swash motion (following [Stockdon2006]) and the local grid size.

### Bed composition¶

If the effect of different sediment fractions, sorting and armoring are of importance, a bed composition constituting multiple sediment fractions can be defined. Each sediment fraction is characterized by a median grain size () and possible a and as well. When using multiple sediment fractions, multiple bed layers are needed as well to describe the vertical distribution of the sediment fractions in the bed.

By specifying multiple bed layers, XBeach can keep track of the different sediment fractions both in the horizontal and in the vertical. Coarse sediments may be deposited on top of fine sediment after which erosion of the coarse sediment is needed to expose the fine sediment again, effectively armoring the bed. Three types of bed layers are distinguished: 1) the top layers 2) the variable or ‘breathing’ layer and 3) the bottom layers. The top layer is the only layer that interacts with the water column and can be eroded, but preserves its thickness. The bottom layers are layers of constant thickness that move with the top layer. A single variable or’breathing’ layer is defined that adapts its thickness to the erosion and sedimentation of the bed. For example: if a grid cell is eroded, particular fractions of sediment are removed from the top layer, but the top layer preserves its thickness and thus it takes the same volume of sediment, likely of different composition than the eroded sediment, from the layer below. If this layer is a top layer as well, the thickness is preserved and again the same volume of sediment is taken form a lower bed layer. This continues until the variable or ‘breathing’ layer is reached. This layer adapts its thickness to the amount of erosion. If the thickness of the layer becomes too small, the variable layer is merged with an adjacent bottom layer and a new bottom layer is defined underneath the existing ones to ensure a constant number of bed layers. Reversely, if a grid cell is accreting, the thickness of the variable layer will be increased and with sufficient increase the variable layer will be split in two effectively creating a new bottom layer. The lowest existing bottom layer is then discarded to ensure a constant number of bed layers. The ‘breathing’ layer can be the upper or bottom layer in which case the top layer or bottom layer class does not exist. The thickness of the different layer classes can be set separately (keyword: dzg1, dzg2 and dzg3) or at once (keyword: dzg).

Each grid cell in XBeach holds its own sediment distribution and the sediment transport formulations are used differentiate between fractions. Therefore the distribution of sediment may change over time and processes like armoring and sorting can be simulated. Due to the shifting of sediment between bed layers numerical mixing of sediment occurs. Choosing bed layer thicknesses that are in balance with the expected erosion and deposition during the simulation should keep the numerical mixing to a minimum. A bed layer thickness that is too large will result in relatively uniform behavior, while a bed layer thickness that is too small will result in a lot of shifting and thus numerical mixing (Fig. 6).

Fig. 6 Visualization of the diffusion that occurs when XBeach calculates sediment compositions. After sedimentation of fine sediment on top of coarser material it is uniformly mixed over the whole layer. Subsequent erosion erodes both the fines as the coarser material. To avoid this phenomenon, layers should not be too thick ([vdZ14]).

## Ship-induced wave motions¶

Ship-induced wave motions are implemented in mod:ship_module.

A relatively new application field for XBeach is the generation and propagation of waves induced by sailing vessels. This functionality has been implemented recently ([ZRVL13]), and has currently been used in several studies (e.g. [ZRZvW14], [dJRB13]), showing very good results.

For computing ship-induced waves the non-hydrostatic version of XBeach is used. A moving ship is represented as a pressure head that moves along a pre-defined track through the model domain. The ship is defined on a separate grid, where the ship draft is specified per grid point. Each computational time step the ship draft is interpolated from the ship grid to the global grid, where the ship volume is kept constant. Then the water pressure head in each global grid cell is updated based on the interpolated ship draft. By moving the pressure fields, the waves are generated and will propagate further through the global domain.

In fig-ship-example an example XBeach setup for ship waves is shown. The ship track is user defined and can, for instance, be obtained from the Automatic Identification System (AIS) for marine traffic. In this example, the model results were compared with measurements taken at Bath, The Netherlands. A filtered time series of the measured and computed water level is shown in Fig. 7. The time series was filtered to focus on the computation of the primary ship wave.

Example XBeach setup (left) and result (right) for a ship wave simulation in the Scheldt Estuary (The Netherlands). The ship track (red dashed line) is user-defined, and the measurement location is indicated (magenta dot).

Fig. 7 Example XBeach result for ship-induced waves. Measurements are taken at Bath, in the Scheldt Estuary, The Netherlands ([SHvdWT11]).

In addition to the propagation of ship-induced waves, XBeach computes the forces and moments acting on the ship body. With this functionality, passing ship effects can be analyzed (e.g. [ZRVL13]).

## Gravel (XBeach-G)¶

XBeach-G was a branch of the main XBeach development that has been developed to simulate storm impacts on gravel beaches. The development of XBeach-G have been taking place as a joint collaboration between Plymouth University and Deltares, as part of the EPSRC-funded NUPSIG-project. The relevant XBeach-G formulations have been merged back into to the XBeach trunk for the XBeachX release (fall 2017). XBeach-G formulations can be activated with the keyword useXBeachGSettings = 1).

XBeach-G uses the one-layer, depth-averaged, non-hydrostatic extension to the XBeach model (nonh=1), which is similar to the SWASH model ([ZSS11]) to solve wave-by-wave flow and surface elevation variations due to short waves in intermediate and shallow water depths. This is particularly important for application on gravel beaches, where due to steep slopes swash motion is mainly at incident wave frequencies, and infragravity wave motion, which dominates the inner surf and swash zone on sandy beaches during storms, is of secondary importance. To correctly account for upper swash infiltration losses and exfiltration effects on lower swash hydrodynamics on gravel beaches, XBeach-G computes groundwater dynamics and the exchange between groundwater and surface water using the XBeach groundwater model (gwflow = 1). Again, interaction between swash flows and the beach groundwater table are considered particularly important on gravel beaches due to the relatively large hydraulic conductivity of the sediment, while on sandy beaches this process is of significantly less importance. Finally, gravel sediment transport processes (McCall & Van Rijn) have been included in XBeach-G to simulate the morphodynamics of gravel beaches during storms. These transport processes are currently under further development and validation.

# Boundary conditions¶

## Waves¶

Wave boundary conditions are implemented in mod:waveparams. The latest functionalities, like spatially varying spectral conditions are implemented in mod:spectral_wave_bc_module.

XBeach allows users to include two different options for wave boundary conditions in the model. These wave boundary conditions can be applied only at the seaward boundary (keyword: wbctype). First of all, in Spectral conditions the method to specify wave spectra is discussed. Secondly, in Non-spectral conditions the method to apply non-spectra, such as stationary wave conditions or time-series is elaborated. In Lateral boundary conditions the lateral boundary conditions for waves are discussed. There is currently not a possibility to force waves on the landward boundary of a model.

### Spectral conditions¶

The most-used wave boundary condition in XBeach is a spectral type. The input description of spectral wave boundary conditions can be found in Spectral wave boundary conditions. XBeach allows the user to define these with three possibilities:

1. : With this option you define the boundary condition as parametric spectral input. The parameters (i.e. the spectral shape, the wave period and the directional spreading) can be specified. The option is especially handy when there is no nested model or measured spectrum. Here are two options:

1. Specify a single parametric spectrum (keyword wbctype = jons).

2. Specify a series of parametric spectra (keyword wbctype = jons_table).

2. : In this case the two-dimensional (frequency-direction) output by the spectral wave model SWAN (.sp2 files) can be specified. (keyword wbctype = swan). This option is especially convenient when nesting XBeach into a SWAN model.

3. : In this case a more general type spectrum can be specified. (keyword wbctype = vardens). This option is often used when a measured spectrum is available.

### Non-spectral conditions¶

XBeach also allows the user to define non-spectral wave boundary conditions. This is a variation of both wave conditions without wave groups and time series. The input description of non-spectral wave boundary conditions can be found in Non-spectral wave boundary conditions. XBeach allows the user to define these with two possibilities:

1. This means that a uniform and constant wave energy is specified, based on the given values of , , direction and power of the directional distribution function. The station boundary condition will contain wave groups. Here there are two options:

1. Specify a single sea state (keyword wbctype = stat)

2. Specify a series of sea states (keyword wbctype = stat_table)

2. . The user can also specify the variation in time of the wave energy. There are three options:

1. First-order time series of waves (keyword wbctype = ts_1). XBeach will calculate the bound long wave based on the theory of [LHS64]).

2. Second-order time series of waves (keyword wbctype = ts_2). The bound long wave is specified by the user via a long wave elevation.

3. It is also possible to specify a variation in time of the horizontal velocity, vertical velocity and the free surface elevation (keyword: wbctype = ts_nonh). Last two terms are optional in this boundary conditions type.

### Special conditions¶

Besides clear spectral or non-spectral wave boundary conditions, there are also three special boundary condition types implemented in XBeach.

1. (keyword wbctype = bichrom). In this case, XBeach will be forced with regular wave groups as the two short-wave components force one difference (infragravity) wave period. The user needs to specify not only variables of the stationary situation but also a wave period for the long wave. This wave period will be used to calculate the long wave based on the theory of [LHS64]. The bichromatic boundary condition is the most simplified form of a wave spectrum.

2. (keyword wbctype = off). This is a simple no wave action boundary condition. It still allows for a tidal record to be specified, however this trough the zs0file parameter.

3. (keyword: wbctype = reuse). If the user does not wish to recalculate boundary condition files or specifically wants to reuse the boundary condition files of another XBeach simulation should be used. No further wave boundary condition data need be given. Obviously, the calculation grid should remain the same between runs, as the angles and number of grid points are embedded in the boundary condition files.

### Lateral boundary conditions¶

There are two options to set the lateral boundaries for the wave model:

1. Neumann boundaries (keyword: lateralwave = neumann): here the longshore gradient is set to zero.

2. Wave crest boundaries (keyword: lateralwave = wavecrest). here the gradient in the wave energy along the wave crest is set to zero.

For the stationary wave mode (keyword: wavemodel = stationary) this is the only option. It allows a correct representation of the wave propagation near the lateral boundaries, without the usual shadow zones in e.g. SWAN. By neglecting the longshore gradients, the model automatically computes a consistent 1D solution.

For the surfbeat mode (keyword: wavemodel = surfbeat), Neumann leads to shadow zones, not so much in the wave height, but in the groupiness; the ‘blobs’ propagating in the mean wave direction turn into elongated, longshore uniform patches. To reduce this effect, the gradient along the wave crests of the wave energy can be set to zero, instead of the longshore gradient (keyword: lateralwave = wavecrest). This way the crests of the wave groups have approximately the right orientation, though the along-crest groupiness also disappears. In the wavecrest case, the wave refraction may be overestimated leading to somewhat too large longshore currents. The effects of both boundary conditions are shown in Fig. 8.

Fig. 8 Effect of the lateral wave boundary conditions on root-mean square wave height patterns (top) and longshore velocity (bottom) for the Delilah test case. In this figure the left panels are used for simulations with Neumann boundaries and the right panel with the wavecrest boundary.

## Shallow water equations¶

### Offshore boundary¶

Typically, an offshore or lateral boundary is an artificial boundary which has no physical meaning. On the offshore boundary wave and flow conditions are imposed. In the domain waves and currents will be generated which need to pass through the offshore boundary to the deep sea with minimal reflection. One way to do this is to impose a weakly reflective-type boundary condition (absorbing-generating), but there are also other possibilities implemented in XBeach (keyword: front). This method can be applied in 1D or 2D, is recommended and therefore the default value for XBeach.

In XBeach, there are two options with regard to the offshore absorbing-generating boundary condition. With the parameter setting front = abs1d a simple one-dimensional absorbing-generating boundary condition is activated. This option allows for a time-varying water level (surge and/or infragravity waves) to be specified at the boundary while allowing any waves propagating perpendicularly towards the boundary to be absorbed (i.e., passed through the boundary with a minimum of reflection. It is therefore only useful for 1D (flume like) simulations.

With option front = abs2d (default value) the formulation by [vDS97] is activated which in turn is based on [VSO81] and is based on the ‘Method of Characteristics’. This boundary condition allows for obliquely-incident and obliquely-reflected waves to pass through the boundary. It is possible to account for situations with boundary-perpendicular and boundary-parallel currents. In order to differentiate between the particle velocities, the keyword epsi must be set. This parameter control a simple Kalman-update filter which controls which part of the particle velocity is assumed to be part of the current and which part is wave-related. By default XBeach computes the value for epsi automatically using offshore boundary conditions (keyword: epsi = -1).

There are three other possibilities implemented besides the absorbing-generating boundary conditions:

1. No flux wall (keyword: front = wall). This boundary condition type is a simple no flux boundary condition.

2. Water level specification (keyword: front = wlevel). This boundary sets the water level at a prescribed value. This can be constant or time-varying. With this option the outgoing long waves are not absorbed.

3. Boundary condition for the non-hydrostatic option (keyword: : front = nonh_1d). This boundary condition is required for non-hydrostatic simulations.

4. Radiation boundary condition (keyword: front = waveflume). This boundary uses a continuity relation at the front boundary. This means that no net water can come into the model domain. The wave flume boundary condition is especially useful in lab experiments with a large set-up (e.g. coral reefs).

### Lateral boundaries¶

Lateral boundaries are the boundaries perpendicular to the coastline. Usually these are artificial, because the model domain is limited but the physical coast will continue. At these boundaries (keywords: left & right) we need to prescribe information about the area beyond the numerical model domain in such a way that the boundary condition does not influence the results in an adverse way. One way to do this is to prescribe a so-called ‘no-gradient’ or Neumann boundaries (XBeach default), which state that there is locally no change in surface elevation and velocity, but there are also other possibilities implemented into XBeach. This method is recommended and is therefore the default value for XBeach. Each lateral boundary is a separate condition, so it is possible to mix different type of lateral boundary per side.

Neumann boundary conditions are activated where the longshore water level gradient is prescribed. The alongshore gradient is prescribed by the difference in specified water levels at the offshore corner points, divided by the alongshore length of the domain. This type of Neumann boundary condition has been shown to work quite well with (quasi-) stationary situations, where the coast can be assumed to be uniform alongshore outside the model domain. So far we have found that also in case of obliquely incident wave groups this kind of boundary conditions appears to give reasonable results when a shadow zone is taken into account. This means that regions where the boundary conditions are not fully enforced the results are not taken into account. Neumann boundaries can be individually defined (keyword: left = neumann).

There are three other possibilities implemented besides the absorbing-generating boundary conditions:

1. Simple no-flux boundary conditions can also be applied (keyword: left = wall). Wall boundary conditions will result in a zero velocity at the lateral boundary.

2. Velocity at the boundary will be calculated from NLSWE, but only include the advective terms (keywords: left = no_advec). The effect is that only terms that decrease the velocity will be taken into account. The result is an intermediate form between a full Neumann boundary and a wall boundary.

3. Velocity at the boundary will simply be copied from the adjacent cell in the model domain (keyword: left = neumann_v).

### Tide and surge¶

XBeach can take in up to four time-vary tidal signals to be applied to the four boundaries (offshore-right, offshore-left, backshore-left, backshore-right). A time-varying water level signal is read into XBeach by reading the specified file in zs0file. The input signal will be interpolated to the local time step of the simulation; therefore the signals only need to be long enough and temporally-fine enough to resolve the water level phenomenon of interest (i.e. tide variations, surge event).

There are now four options for handling the tidal and/or surge contribution to the boundaries:

1. Uniform water level (keyword: tideloc = 0)

2. One time-varying water level signal (keyword: tideloc = 1)

3. Two time-varying water level signals, which requires point of application indication. (keyword: tideloc = 2)

4. Four time-varying water level signals (keyword: tideloc = 4)

For the option with a uniform water level the value specified in the params.txt is applied in the complete model domain (keyword: zs0). For the option with one time-varying water level signal the specified water level is applied (keyword: zs0file = <name_of_your_time_series_file>) to the offshore boundary and a fixed value is applied at the backshore boundary (keyword: zs0). For the option with two time-varying water level signals two water level signals are read from the zs0file. Note: one tidal record is applied to both sea corners and one tidal record to both land corners. This means there is no alongshore variation. An alongshore variation can be applied when applying four time-varying water level signals.

### River and point discharge¶

The effect of a river outflow or other discharges can be simulated with XBeach. Multiple discharge locations can be designated. At a discharge location the discharge orifice is defined as well as the discharge time series in . The discharge orifice always constitutes an uninterrupted series of full grid abreast cell borders. It is not possible to define a discharge over half a grid cell nor is it possible to define a single discharge through grid cell borders that are either not adjacent or are not abreast.

At each time step the model sets the discharge and velocities at the grid cell borders that constitute the discharge orifice, which can be computed given the size of the discharge orifice and discharge time series. The discharge is positive in positive x or y direction. An exception is made when discharges are defined at the domain border. In that case the discharge is positive towards the domain (influx).

When a discharge is defined with a zero size orifice the discharge is assumed to be in vertical direction where a positive discharge is into the domain (influx). In these cases the discharge is linked to the closest grid cell center and at each time step mass according to the discharge time series is added. No momentum is added in case of a vertical discharge.

## Sediment transport¶

The boundary conditions for sediment transport are Neumann boundaries everywhere, implying that the cross-boundary gradients in the advection-diffusion equation are set to zero, as well as the gradients of the bed load transports in that direction. Cross-shore profile changes due to cross-shore transport gradients are possible, allowing the boundary to smoothly follow the rest of the model. Still, it is good modeling practice to have the boundaries away from the area of interest.

# Input description¶

## General¶

Upon running the XBeach executable xbeach.exe, the file params.txt in the current working directory will be read. The params.txt file contains grid and bathymetry info, wave input, flow input, morphological input, etc. in the form of keyword/value pairs. Each keyword/value pair may contain an actual model parameter or refer to another file with additional information on the model setup. If a params.txt file cannot be found then XBeach will not run.

In the params.txt file there can be a single keyword/value pair per line. The keywords can be specified in any order. A keyword/value pair is separated by an equal sign (=). Each line containing an equal sign is interpreted as a keyword/value pair. Reversely, any lines without an equal sign are ignored and may be used for comments. Only a few keywords are required for the model to run, others have default values that are used in case the keyword is not mentioned in the params.txt file. The essential parameters for a simulation with a JONSWAP spectrum are listed below:

1. A . This can both in XBeach format (separate x and y files; keyword: xfile and yfile) or Delft3D (one single xy file; keyword: xyfile). On top of that the user needs to specify the width of each domain (keyword: nx and ny)

2. A file (keyword: depfile) that matches with the grid you specified at 1)

3. A (keyword: tstop) in seconds

4. A for short waves and rollers. The grid is determined by a minimum and maximum angle and width per bin (keywords: thetamin, thetamax and dtheta).

5. A (keyword: wbctype = jons). With a separate file containing the variables of the parametric (keyword: bcfile).

It is strongly recommended to specify as few parameters explicitly as possible and rely on the defaults for the other parameters. When running XBeach, a file called xbeach.log is created, which lists all the parameters set through the params.txt file but also all parameters not set, for which the defaults are used. When the user starts the model, it generates a file named XBlog.txt. In this file all the different keyword available are determined. When no keyword is defined the default value will be applied.

This chapter describes the possibilities of the params.txt file and any auxiliary information files that are called from the params.txt file. The tables in this chapter contain a description of the keywords, the default values, its units and recommended value ranges, while the formats for additional input files are described in the relevant sections. Keyword marked with an astrix (*) are essential for XBeach to run. Keywords marked with a plus (+) are considered advanced expert options and should not be used for regular applications of XBeach.

In this chapter, any references to keywords refer to keywords that can be used in the params.txt file. Also any references to time indications are in seconds unless stated otherwise. A typical params.txt file for a 1D XBeach model is:

params.txt

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% XBeach parameter settings input file                                %%%
%%%                                                                     %%%
%%% date: 01-Jan-2015 12:00                                             %%%
%%% function: xb_write_params                                           %%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%% Grid parameters %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

depfile = bed.dep
posdwn = 0
nx = 265
ny = 0
alfa = 0
vardx = 1
xfile = x.grd
yfile = y.grd
thetamin = -90
thetamax = 90
dtheta = 15
thetanaut = 0

%%% Model time %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

tstop = 3600

%%% Physical constants %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

rho = 1025

%%% Tide boundary conditions %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

tideloc = 2
zs0file = tide.txt

%%% Wave boundary condition parameters %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

wbctype = jons
bcfile = filelist.txt

%%% Output variables %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

outputformat = netcdf
tint = 3600
tstart = 0
nglobalvar = 3
zb
zs
H


## Physical processes¶

XBeach supports a variety of physical processes from generic, like waves and flow, to very specific, like ship motions and point discharge. Each process can be switched on or off. The commonly used processes are turned on by default. The table below lists the keywords used to switch on or off physical processes in XBeach.

Table 4 Overview of available keywords related to physical processes

parameter

description

default

range

units

1

0 - 1

avalanching

Turn on avalanching

1

0 - 1

bchwiz

Turn on beachwizard

0

0 - 1

cyclic

Turn on cyclic boundary conditions

0

0 - 1

flow

Turn on flow calculation

1

0 - 1

gwflow+

Turn on groundwater flow

0

0 - 1

lwave

Turn on short wave forcing on nlsw equations and boundary conditions

1

0 - 1

morphology

Turn on morphology

1

0 - 1

nonh+

Turn on non-hydrostatic pressure: 0 = nswe, 1 = nsw + non-hydrostatic pressure compensation stelling & zijlema, 2003

0

0 - 1

q3d

Turn on quasi-3d sediment transport

0

0 - 1

sedtrans

Turn on sediment transport

1

0 - 1

setbathy

Turn on timeseries of prescribed bathy input

0

0 - 1

ships+

Turn on ship waves

0

0 - 1

single_dir+

Turn on stationary model for refraction, surfbeat based on mean direction

0

0 - 1

snells+

Turn on snell’s law for wave refraction

0

0 - 1

swave

Turn on short waves

1

0 - 1

swrunup

Turn on short wave runup

0

0 - 1

vegetation+

Turn on interaction of waves and flow with vegetation

0

0 - 1

viscosity

Include viscosity in flow solver

1

0 - 1

wavemodel

Stationary (0), surfbeat (1) or non-hydrostatic (2)

surfbeat

stationary, surfbeat, nonh

wind

Include wind in flow solver

1

0 - 1

## Grid and bathymetry¶

XBeach spatial grid size is defined by the keywords nx and ny. Here nx are the number of grid points in the cross-shore direction and ny the number in the alongshore direction. The size of the computational grid will be nx +1 by ny +1 cells large. The initial bathymetry is provided using a separate file that is referred to by the depfile keyword, which has to have a size of [nx+1, ny+1]. This file contains an initial bed level for each grid cell where each line corresponds to a transect in x-direction (cross-shore). The values are positive down by default (so e.g. a value of ‘10’ is 10 meters depth), but this can be changed using the posdwn keyword.

Three main types of XBeach grids are supported: fast 1D, 1D and 2DH. Fast 1D grids have a single alongshore grid cell and thus a value ny = 0 and thus a single row (ny+1=1) in the depfile. The 1D grids have 3 alongshore grid cells and thus a value ny = 2 and three rows in the depfile. The 2DH grids have more than 3 alongshore grid cells, a value ny >2 and as many rows in the depfile. In general, the bathymetry file has the following space-separated format:

bed.dep

<z 1,1> <z 2,1> <z 3,1> ... <z nx,1> <z nx+1,1>
<z 1,2> <z 2,2> <z 3,2> ... <z nx,2> <z nx+1,2>
<z 1,3> <z 2,3> <z 3,3> ... <z nx,3> <z nx+1,3>

...

<z 1,ny> <z 2,ny> <z 3,ny> ... <z nx,ny> <z nx+1,ny>
<z 1,ny+1> <z 2,ny+1> <z 3,ny+1> ... <z nx,ny+1> <z nx+1,ny+1>


XBeach spatial grids can be equidistant or non-equidistant. In the former case the grid size is defined by the keywords dx and dy. In the latter case the keyword vardx should be set to 1 and x- and y-coordinates of the grid cells should be provided through the files referenced by the xfile and yfile keywords. These files take exactly the same format as the depfile file where all coordinates along the x-direction are in one row and each row represents a cell in y-direction. XBeach grids are defined in a coordinate system of choice and can be either rectangular or curvilinear grids as discussed in Domain and definitions.

Delft3D grids created with tools like RFGRID are also supported. To use Delft3D grids, choose gridform = delft3d and provide a grid file via the keyword xyfile. The format of Delft3D grids is not described here, but can be found in the Delft3D manual ([Del11]). Also forced updating of bathymetries is supported as described in Bed update.

Apart for the spatial grid, XBeach also uses a directional grid for short waves and rollers. The grid is determined by a minimum and maximum angle and a directional bin size using the keywords thetamin, thetamax and dtheta respectively. The thetamin and thetamax angles are either defined according to the Cartesian convention (angle w.r.t. the computational x-axis) or according to the nautical convention (angle w.r.t. deg. N, so from W is 270 deg. N). The convention is chosen using the keyword thetanaut (thetanaut = 0 for Cartesian and thetanaut = 1 for Nautical)

Examples of typical input for a non-equidistant, fast 1D XBeach model, together with the params.txt example at the start of this chapter, are:

depfile = bed.dep

-20.00 -20.00 -19.90 -19.80 -19.70 ... 14 14 15 15 15


xfile = x.grd

0.00 10.00 20.00 30.00 40.00 ... 1992.00 1994.00 1996.00 1998.00 2000.00


yfile = y.grd

0.00 0.00 0.00 0.00 0.00 0.00 0.00 ... 0.00 0.00 0.00 0.00 0.00 0.00 0.00


All keywords related to grid and bathymetry input are listed in the following table:

Table 5 Overview of available keywords related to grid parameters

parameter

description

default

range

units

alfa

Angle of x-axis from east

0.0

0.0 - 360.0

deg

depfile*

Name of the input bathymetry file

<file>

dtheta*

Directional resolution

10.0

0.1 - 180.0

deg

dtheta_s*

Directional resolution in case of stationary refraction

10.0

0.1 - 20.0

deg

dx*

Regular grid spacing in x-direction

-1.0

0.0 - 1000000000.0

m

dy*

Regular grid spacing in y-direction

-1.0

0.0 - 1000000000.0

m

gridform

Grid definition format

xbeach

xbeach, delft3d

nx*

Number of computational cell corners in x-direction

50

2 - 10000

ny*

Number of computational cell corners in y-direction

2

0 - 10000

nz

Number of computational cells in z-direction

1

1 - 100

posdwn

Bathymetry is specified positive down (1) or positive up (-1)

1.0

-1.0 - 1.0

thetamax*

Higher directional limit (angle w.r.t computational x-axis)

90.0

-360.0 - 360.0

deg

thetamin*

Lower directional limit (angle w.r.t computational x-axis)

-90.0

-360.0 - 360.0

deg

thetanaut

Switch to specify thetamin and thetamax in nautical convention rather than cartesian

0

0 - 1

vardx

Switch for variable grid spacing

0

0 - 1

xfile

Name of the file containing x-coordinates of the calculation grid

<file>

xori

X-coordinate of origin of axis

0.0

-1000000000.0 - 1000000000.0

m

xyfile*

Name of the file containing delft3d xy-coordinates of the calculation grid

<file>

yfile

Name of the file containing y-coordinates of the calculation grid

<file>

yori

Y-coordinate of origin of axis

0.0

-1000000000.0 - 1000000000.0

m

## Waves input¶

An XBeach model is generally forced by waves on its offshore boundary. These waves are described by the wave boundary conditions discussed in this section. The details of the wave motions within the model are described by the wave numerics in terms of the wave action balance (see Short wave action balance), wave dissipation model (see 0) and wave roller model (see Roller energy balance)

XBeach supports a variety of wave boundary condition types that are divided in two main groups: stationary and spectral boundary conditions. The wbctype keyword can be used to select one particular type of wave boundary conditions. Waves gives an overview of all types of wave boundary conditions available for XBeach. Fig. 9 can be used to help determine what type of wave boundary conditions is appropriate for your case. Each wave boundary condition type is explained in the following subsections. Note that most spectral wave boundary conditions can vary both in space and time using a FILELIST and/or LOCLIST construction as described in Temporally and/or spatially varying wave boundary conditions.

Table 6 Overview of available keywords related to wave boundary condition parameters

parameter

description

default

range

units

Hrms

Hrms wave height for instat = stat, bichrom, ts_1 or ts_2

1.0

0.0 - 10.0

m

Tlong

Wave group period for case instat = bichrom

80.0

20.0 - 300.0

s

Trep

Representative wave period for instat = stat, bichrom, ts_1 or ts_2

10.0

1.0 - 20.0

s

dir0

Mean wave direction for instat = stat, bichrom, ts_1 or ts_2 (nautical convention)

270.0

-360.0 - 360.0

deg

instat

Old wave boundary condition type

bichrom

stat, bichrom, ts_1, ts_2, jons, swan, vardens, reuse, ts_nonh, off, stat_table, jons_table

lateralwave

Switch for lateral boundary at left

neumann

neumann, wavecrest, cyclic

m

Power in cos^m directional distribution for instat = stat, bichrom, ts_1 or ts_2

10

2 - 128

taper

Spin-up time of wave boundary conditions, in morphological time

100.0

0.0 - 1000.0

s

wbctype

New wave boundary condition type

params

params, parametric, swan, vardens, off, jonstable, reuse, ts_1, ts_2, ts_nonh

Fig. 9 Decision tree for selecting the appropriate type of wave boundary conditions

### Spectral wave boundary conditions¶

Spectral wave boundary conditions are enabled using wbctype values jons, swan, vardens or jons_table. The conditions are defined in separate files referenced from the params.txt file using the bcfile keyword. A spectral wave boundary condition describes a spectrum shape that XBeach uses to generate a (random) wave time series. The length and resolution of the generated time series is determined by the keywords rt and dtbc respectively. XBeach will reuse the generated time series until the simulation is completed. The resolution of the time series should be enough to accurately represent the bound long wave, but need not be as small as the time step used in XBeach.

An overview of all keywords relevant for spectral wave boundary conditions is given in the table below. The necessary file formats for each type of spectral wave boundary condition is explained in the following subsections.

Table 7 Overview of available keywords related to wave-spectrum boundary condition parameters

parameter

description

default

range

units

Tm01switch+

Switch to enable tm01 rather than tm-10

0

0 - 1

bcfile

Name of spectrum file

<file>

correctHm0

Switch to enable hm0 correction

1

0 - 1

dtbc+

Timestep used to describe time series of wave energy and long wave flux at offshore boundary (not affected by morfac)

1.0

0.1 - 2.0

s

dthetaS_XB+

The (counter-clockwise) angle in the degrees needed to rotate from the x-axis in swan to the x-axis pointing east

0.0

-360.0 - 360.0

deg

fcutoff+

Low-freq cutoff frequency for instat = jons, swan or vardens boundary conditions

0.0

0.0 - 40.0

Hz

nonhspectrum+

Spectrum format for wave action balance of nonhydrostatic waves

0

0 - 1

nspectrumloc+

Number of input spectrum locations

1

1 - par%ny+1

nspr

Switch to enable long wave direction forced into centres of short wave bins

0

0 - 1

random+

Switch to enable random seed for instat = jons, swan or vardens boundary conditions

1

0 - 1

rt

Duration of wave spectrum at offshore boundary, in morphological time

min(3600.d0,par%tstop)

1200.0 - 7200.0

s

sprdthr+

Threshold ratio to maximum value of s above which spectrum densities are read in

0.08

0.0 - 1.0

trepfac+

Compute mean wave period over energy band: par%trepfac*maxval(sf) for instat jons, swan or vardens; converges to tm01 for trepfac = 0.0 and

0.01

0.0 - 1.0

wbcversion

Version of wave boundary conditions

3

1 - 3

#### JONSWAP wave spectra¶

JONSWAP spectrum input is enabled using wbctype = jons. A JONSWAP wave spectrum is parametrically defined in a file that is referenced using the bcfile keyword. This file contains a single parameter per line in arbitrary order. The parameters that can be defined are listed in Table 8. All variables are optional. If no value is given, the default value as specified in the table is used. It is advised not to specify the keyword dfj and allow XBeach to calculate the default value.

A typical JONSWAP definition file looks as follows:

jonswap.txt

Hm0 = 0.8
Tp = 8
mainang = 285.
gammajsp = 3.3
s = 10.
fnyq = 0.3


For the definitions see the table below.

It is possible to use an alternative file format for time-varying JONSWAP spectra. To enable this option use the wbctype value jons_table. In this case, each line in the spectrum definition file contains a parametric definition of a spectrum, like in a regular JONSWAP definition file, plus the duration for which that spectrum is used during the simulation. XBeach does not reuse time-varying spectrum files. Therefore the total duration of all spectra should at least match the duration of the simulation. The name of the file can be chosen freely, but the file format is fixed as follows and all parameters should be present in all lines:

jonswap.txt

<Hm0> <Tp> <mainang> <gammajsp> <s> <duration> <dtbc>


Note that we refer to the keywords used in a regular JONSWAP definition file in this example, with three differences: 1) the peak period rather than the peak frequency is defined 2) the duration is added (similar to rt in params.txt) 3) the time resolution is added (similar to dtbc in params.txt). The duration and boundary condition time step in this file overrules rt and dtbc in params.txt. This format is also used for time-varying stationary wave boundary conditions as described in Temporally and/or spatially varying wave boundary conditions. As an example, the JONSWAP spectrum definition file presented above would look as follows if the significant wave height should be increased with 0.2 m every hour:

jonswap.txt

0.8 8. 285. 3.3 10. 3600. 1
1.0 8. 285. 3.3 10. 3600. 1
1.2 8. 285. 3.3 10. 3600. 1


A more generic way of providing time-varying spectral wave boundary conditions is using a FILELIST construction as described in Temporally and/or spatially varying wave boundary conditions. This approach is compatible with all spectral wave boundary condition types as well as spatially varying boundary conditions as described in the same section.

The parameter s in the JONSWAP spectrum definition is related to the directional spreading (in deg.) through the following relation . Here is the directional spreading in radians and s the JONSWAP spreading parameter.

Fig. 10 Effect a variation in s for the direction spreading of wave energy

Table 8 Overview of available keywords in JONSWAP definition file

parameter

description

default

range

units

Hm0

Hm0 of the wave spectrum, significant wave height [m]

0.0

0.0 - 5.0

fp

Peak frequency of the wave spectrum [s-1]

0.08

0.06258 - 0.4

gammajsp

Peak enhancement factor in the JONSWAP expression [-]

3.3

1.0 - 5.0

s

Directional spreading coefficient, {cos}^{2s} law [-]

10.0

1.0 - 1000.0

mainang

Main wave angle (nautical convention) [{}^circ]

270.0

180.0 - 360.0

fnyq

Highest frequency used to create JONSWAP spectrum [s-1]

0.3

0.2 - 1.0

dfj

Step size frequency used to create JONSWAP spectrum [s-1]

fnyq/200

fnyq/1000 - fnyq/20

#### SWAN wave spectra¶

XBeach can read standard SWAN 2D variance density or energy density output files (+.sp2 files) as specified in the SWAN v40.51 manual. This option is enabled using wbctype = swan in params.txt and a reference to the spectrum file via the keyword bcfile. XBeach assumes the directional information in the SWAN file is according to the nautical convention. If the file uses the Cartesian convention for directions, the user must specify the angle in degrees to rotate the x-axis in SWAN to the x-axis in XBeach (by the Cartesian convention). This value is specified in params.txt using the keyword dthetaS_XB.

Note that time-varying and spatially varying SWAN spectra can be provided using the FILELIST and LOCLIST constructions as described in Temporally and/or spatially varying wave boundary conditions.

An example of a 2D SWAN spectrum is given below:

swan.txt

SWAN 1 Swan standard spectral file
$Data produced by SWAN version 40.51$ Project:’projname’ ; run number:’runnum’
LOCATIONS locations in x-y-space
1 number of locations
22222.22 0.00
RFREQ relative frequencies in Hz
23 number of frequencies
0.0545
0.0622
0.0710
0.0810
0.0924
0.1055
0.1204
0.1375
0.1569
0.1791
0.2045
0.2334
0.2664
0.3040
0.3470
0.3961
0.4522
0.5161
0.5891
0.6724
0.7675
0.8761
1.0000
CDIR spectral Cartesian directions in degr 12 number of directions
30.0000
60.0000
90.0000
120.0000
150.0000
180.0000
210.0000
240.0000
270.0000
300.0000
330.0000
360.0000
QUANT 1 number of quantities in table VaDens variance densities in m2/Hz/degr m2/Hz/degr unit
-0.9900E+02 exception value
FACTOR
0.675611E-06
51 242 574 956 1288 1482 1481 1286 957 579 244 51
129 610 1443 2402 3238 3725 3724 3234 2406 1454 613 128
273 1287 3054 5084 6846 7872 7869 6837 5091 3076 1295 271
665 3152 7463 12402 16712 19229 19221 16690 12419 7518 3172 662
1302 6159 14608 24275 32688 37618 37603 32644 24309 14716 6198 1296
2328 10989 26020 43341 58358 67109 67080 58281 43401 26213 11058 2317
3365 15922 37712 62733 84492 97150 97110 84380 62820 37991 16021 3349
3426 16230 38440 63939 86109 99010 98969 85995 64027 38724 16331 3410
2027 9612 22730 37790 50909 58529 58505 50841 37843 22898 9672 2018
672 3178 7538 12535 16892 19440 19432 16870 12552 7594 3198 669
101 479 1135 1890 2542 2924 2923 2539 1892 1144 482 101
2 11 26 43 57 66 66 57 43 26 11 2
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0


#### Variance density spectra¶

2D spectral information that is not in SWAN format can be provided using a formatted variance density spectrum file and wbctype = vardens. The spectrum file itself is again referenced using the keyword bcfile. The contents of the file must adhere to a specific format:

vardens.txt

<number of frequencies (n)>
<frequency 1>
<frequency 2>
<frequency 3>

...

<frequency n-1>
<frequency n>
<number of directions (m)>
<directions 1>
<directions 2>
<directions 3>

...

<directions m-1>
<directions m>
<variance density 1,1> <variance density 2,1> ... <variance density m,1>
<variance density 1,2> <variance density 2,2> ... <variance density m,2>

...

<variance density 1,n> <variance density 2,n> ... <variance density m,n>


Note that the directions must be defined according to the Cartesian convention and in the coordinate system used by XBeach. In this coordinate system corresponds to waves travelling in the direction of the x-axis, while corresponds to the direction of the y-axis. Also, the directions must be defined in increasing order. Time-varying and spatially varying variance density spectra can be provided using the FILELIST and LOCLIST constructions as described in Temporally and/or spatially varying wave boundary conditions.

An example of a formatted variance density file is given below:

vardens.txt

15
0.0418
0.0477
0.0545
0.0622
0.0710
0.0810
0.0924
0.1055
0.1204
0.1375
0.1569
0.1791
0.2045
0.2334
0.2664
13
-180.0000
-150.0000
-120.0000
-90.0000
-60.0000
-30.0000
0.0000
30.0000
60.0000
90.0000
120.0000
150.0000
180.0000
0 0 0 0 0 0 0 0 0 0 0 0
51 242 574 956 1288 1482 1481 1286 957 579 244 51
129 610 1443 2402 3238 3725 3724 3234 2406 1454 613 128
273 1287 3054 5084 6846 7872 7869 6837 5091 3076 1295 271
665 3152 7463 12402 16712 19229 19221 16690 12419 7518 3172 662
1302 6159 14608 24275 32688 37618 37603 32644 24309 14716 6198 1296
2328 10989 26020 43341 58358 67109 67080 58281 43401 26213 11058 2317
3365 15922 37712 62733 84492 97150 97110 84380 62820 37991 16021 3349
3426 16230 38440 63939 86109 99010 98969 85995 64027 38724 16331 3410
2027 9612 22730 37790 50909 58529 58505 50841 37843 22898 9672 2018
672 3178 7538 12535 16892 19440 19432 16870 12552 7594 3198 669
101 479 1135 1890 2542 2924 2923 2539 1892 1144 482 101
2 11 26 43 57 66 66 57 43 26 11 2
0 0 0 1 1 1 1 1 1 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0


#### Reduction of short-wave group variance to include the effects of directional spreading in a 1-dimensional model¶

Infragravity wave growth is affected by the directional spreading of the short-waves. A wave field with directional spreading result in a lower infragravity wave height than a wave field with no directional spreading. Since directional spreading can only be modelled in a 2-dimensional model, the infragravity wave is overestimated in a 1-dimensional model. Even when boundary conditions including directional spreading are applied in a 1-dimensional model, the internal forcing inside the domain result in a larger infragravity wave compared to a 2-dimensional model with directional spreading. Infragravity wave growth in the XBeach model is controlled by wave forcing terms in the non-linear shallow water equations solved in the XBeach flow module. As such, there is no simple source or sink infragravity energy balance term available to tune in a modified 1D approach. Instead, infragravity wave heights can either be modified by dissipating infragravity waves more strongly (i.e., through increased viscosity or bed roughness), or by reducing the mechanisms for infragravity wave growth. Of these two options, increased dissipation through higher viscosity or bed roughness has the drawback of slowing flow in general, leading to increased predictions of wave set-up at the coast. Therefore, a correction factor on the mechanisms of infragravity wave growth is implemented.

To include the effects of directional spreading in a 1-dimensional model, a reduction parameter in the short-wave group variance is implemented (keyword wbcevarreduce). In this way, time- and space-varying radiation stress gradients are reduced, leading to less energy transfer to the infragravity waves, and hence smaller, more realistic infragravity waves. If the mean wave height remains unchanged, the model will still accurately predict mean circulations and setup.

The boundary signal of the wave groups is now given by:

where is the computed short-wave energy time series at the boundary and represent the averaging operator over the entire time series.

### Non-spectral wave boundary conditions¶

Stationary wave boundary conditions are enabled using wbctype values stat, ts_1, ts_2, ts_nonh or stat_table. The conditions are generally defined within the params.txt file directly using the keywords described in the table below. In addition, in case of wbctype values ts_1 or ts_2 the file bc/gen.ezs should be present that describes the infragravity wave forcing generated outside of XBeach. For the wbctype ts_nonh also a separate file is needed. More information about these files in Non-spectral wave boundary conditions.

#### Stationary wave boundary conditions¶

Only in case of wbctype = stat_table the time-varying stationary wave boundary conditions are fully described in an external file referenced by the bcfile keyword. The bcfile keyword is part of the spectral wave boundary condition input and also the referenced file is designed for time-varying spectral input in the form of JONSWAP spectra (see Spectral wave boundary conditions). In stationary mode only the relevant data from this file is used and irrelevant data like gamma and dfj are discarded.

Table 9 Overview of available keywords related to wave boundary condition parameters

parameter

description

default

range

units

Hrms

Hrms wave height for instat = stat, bichrom, ts_1 or ts_2

1.0

0.0 - 10.0

m

Tlong

Wave group period for case instat = bichrom

80.0

20.0 - 300.0

s

Trep

Representative wave period for instat = stat, bichrom, ts_1 or ts_2

10.0

1.0 - 20.0

s

dir0

Mean wave direction for instat = stat, bichrom, ts_1 or ts_2 (nautical convention)

270.0

-360.0 - 360.0

deg

instat

Old wave boundary condition type

bichrom

stat, bichrom, ts_1, ts_2, jons, swan, vardens, reuse, ts_nonh, off, stat_table, jons_table

lateralwave

Switch for lateral boundary at left

neumann

neumann, wavecrest, cyclic

m

Power in cos^m directional distribution for instat = stat, bichrom, ts_1 or ts_2

10

2 - 128

taper

Spin-up time of wave boundary conditions, in morphological time

100.0

0.0 - 1000.0

s

wbctype

New wave boundary condition type

params

params, parametric, swan, vardens, off, jonstable, reuse, ts_1, ts_2, ts_nonh

#### Time series¶

The wave boundary condition types of ts_1 and ts_2 need a separate file containing short wave energy and free surface elevation (including long wave motions). The format of this file is as follows:

bc/gen.ezs

<time 1> <zs 1> <E 1>
<time 1> <zs 2> <E 2>
<time 2> <zs 3> <E 3>

...


The wave boundary condition type of ts_nonh also needs a separate file in order to run the simulation. This file, however, needs to contain free surface elevations and velocities (both in u and v).

Boun_u.bcf

<scalar/vector>
<number of variables>
<variables: t,U,Zs,W>


(132)

### Special types of wave boundary conditions¶

Two special types of wave boundary conditions are available that makes XBeach skip the generation of new wave time series. The first is wbctype = off which simply does not provide any wave forcing on the model and hence no wave action in the model.

The second is wbctype = reuse which makes XBeach reuse wave time series that were generated during a previous simulation. This can be a simulation using the same or a different model as long as the computational grids are identical. In order to reuse boundary conditions, all relevant files should be copied to the current working directory of the model (where the params.txt file is located). Relevant files are the ebcflist.bcf and qbcflist.bcf files and all files referenced therein. Generally, the referenced files have E_ and q_ prefixes. No further wave boundary condition data need be given in params.txt.

On top of that bichromatic waves are also supported. Currently the same input parameters as non-spectral waves (see Non-spectral wave boundary conditions) are required; however there are planes to elaborate the input parameters of the bichromatic wave in order to specify individual frequency.

### Temporally and/or spatially varying wave boundary conditions¶

Time-varying spectral wave boundary conditions can be defined by feeding in multiple spectrum definition files rather than a single definition file. In addition, the duration for which these spectra should occur needs to be defined.

To make use of this option, the user must specify a regular wbctype value for spectral wave boundary conditions (jons, swan or vardens), but instead of referencing a single spectrum definition file using the bcfile keyword, an extra file listing all spectrum definition files is now referenced.

The first word in this extra file must be the keyword FILELIST. In the following lines, each line contains the duration of this wave spectrum condition in seconds (similar to rt in params.txt), the required time step in this boundary condition file in seconds (similar to dtbc in params.txt) and the name of the spectral definition file used to generate these boundary conditions. The duration and boundary condition time step in this file overrules rt and dtbc in params.txt. XBeach does not reuse time-varying spectrum files. Therefore the total duration of all spectra should at least match the duration of the simulation.

A typical input file contains the following:

filelist.txt

FILELIST
1800 0.2 jonswap1.inp
1800 0.2 jonswap1.inp
1350 0.2 jonswap2.inp
1500 0.2 jonswap3.inp
1200 0.2 jonswap2.inp
3600 0.2 jonswap4.inp


Similar to time-varying spectral wave boundary conditions, also spatially varying wave boundary conditions can be defined using a similar construction. In order to apply spatially varying spectra on the offshore boundary, the user must specify set the keywords wbcversion = 3 and nspectrumloc = <ns> in params.txt where <ns> is the number of locations in which a spectrum is defined. By default the number of defined spectra is one.

Similar to time-varying spectral wave boundary conditions, its spatially varying sibling uses an extra file listing all relevant spectrum definition files. The first word in this extra file must be the keyword LOCLIST. This line should be followed by one line per spectrum definition location containing the world x-coordinate and world y-coordinate of the location that the input spectrum should apply, and the name of the file containing spectral wave information.

A typical input file for a run with three JONSWAP spectra contains the following:

loclist.txt

LOCLIST
0. 0. jonswap1.inp
0. 100. jonswap2.inp
0. 200. jonswap3.inp


Note that it is not possible to use a mix of JONSWAP, SWAN and variance density files in either a FILELIST or a LOCLIST construction. It is also not possible to vary dthetaS_XB between files in case of non-nautical SWAN spectra. However, it is possible to combine FILELIST and LOCLIST files by referencing FILELIST files from the LOCLIST file. In this case all FILELIST files should adhere to the same time discretization, so the duration and time step values should be constant over al FILELIST files as well as the number of wave spectra definitions.

The user is reminded that along the offshore boundary of the model, the wave energy, rather than the wave height, is interpolated linearly between input spectra without consideration of the physical aspects of the intermediate bathymetry. In cases with large gradients in wave energy, direction or period, the user should specify sufficient wave spectra for the model to accurately represent changes in offshore wave conditions.

## Flow, tide and surge input¶

An XBeach model needs flow boundary conditions on all boundaries of the model domain. Moreover, on each boundary tidal elevations and/ or surges may be imposed. The flow boundary conditions and time-varying tide or surge input are discussed in this section. The details on how the flow is computed within the model are described in the sections on bed friction and viscosity parameters (see Shallow water equations).

### Flow boundary conditions¶

Flow boundary conditions need to be specified on all sides of the domain. We will differentiate between the offshore, lateral and landward boundaries that are set using the keywords front, back and left / right, respectively. Table 10, Table 11 and Table 12 give an overview of the available flow boundary condition types for each of these boundaries.

The keyword freewave can be used to switch from bound to free long waves, which can be useful when time series of the free long wave incident on the offshore boundary need to be specified. The file bc/gen.ezs can be used to describe the free long waves at the offshore boundary as discussed in Waves.

Table 10 Overview of available offshore flow boundary condition types

front

description

abs1d

absorbing-generating (weakly-reflective) boundary in 1D

abs2d

absorbing-generating (weakly-reflective) boundary in 2D

wall

no flux wall

wlevel

water level specification (from file)

nonh_1d

boundary condition for non-hydrostatic option

waveflume

boundary condition for flume experiments based on a continuity relation

Table 11 Overview of available landward flow boundary condition types

back

description

wall

no flux wall

abs1d

absorbing-generating (weakly-reflective) boundary in 1D

abs2d

absorbing-generating (weakly-reflective) boundary in 2D

wlevel

water level specification (from file)

Table 12 Overview of available lateral flow boundary condition types

description

wall

no flux wall

neumann

Neumann boundary condition (constant water level gradient)

neumann_v

velocity is determined by the adjacent cell

Neumann boundary condition, but only the advective terms are taken into account. Intermediate form between wall and neumann

Table 13 Overview of available keywords related to flow boundary condition parameters

parameter

description

default

range

units

ARC+

Switch for active reflection compensation at seaward boundary

1

0 - 1

back

Switch for boundary at bay side

abs_2d

wall, abs_1d, abs_2d

epsi+

Ratio of mean current to time varying current through offshore boundary

-1.0

-1.0 - 0.2

freewave+

Switch for free wave propagation 0 = use cg (default); 1 = use sqrt(gh) in instat = ts_2

0

0 - 1

front

Switch for seaward flow boundary

abs_2d

abs_1d, abs_2d, wall, nonh_1d, waveflume

left

Switch for lateral boundary at ny+1

neumann

nc

Smoothing distance for estimating umean (defined as nr of cells)

par%ny+1

1 - par%ny+1

order+

Switch for order of wave steering,first order wave steering (short wave energy only), second oder wave steering (bound long wave corresponding to short wave forcing is added)

2.0

1.0 - 2.0

right

Switch for lateral boundary at 0

neumann

tidetype+

Switch for offfshore boundary, velocity boundary or instant water level boundary

velocity

instant, velocity, hybrid

### Time-varying tide/surge¶

Time-varying tidal (or surge) signals can be applied all four boundaries in a number of ways.

The number of tidal signals is determined by the keyword tideloc that can take the values 0, 1, 2 or 4. Specifying three tidal signals is not an option. Setting tideloc = 0 disables the time-varying tide/surge option. In this case a constant and uniform water level is used specified by the keyword zs0. With tideloc = 1 the specified tidal record is specified on all four corners of the domain and interpolated along the boundaries.

Using tideloc = 2, two tidal signals are specified and there are two options available: 1) the first signal is imposed on the offshore boundary and the second on the landward boundary or 2) the first signal is imposed on the left lateral boundary and the second on the right lateral boundary. The choice between the two options is made using the keyword paulrevere where a value 0 indicates the first option and a value 1 indicates the second option. Also in the case of two tidal signals the signals are spatially interpolated along the boundaries.

Using tideloc = 4, four tide/surge signals are to be specified on each corner of the model domain and spatially interpolated along the boundaries. The first signal is imposed to the left offshore boundary seen from sea (x=1,y=1) and the others according to a clockwise rotation. Therefore the columns in the zs0file must follow the order of: (x=1,y=1), (x=1,y=N), (x=N,y=N), (x=N,y=1).

The length of the tidal signals is determined by the keyword tidelen. This is the number of water levels specified in the file referenced with the zs0file keyword. The tidal signal will be interpolated to the local time step of the XBeach simulation; therefore the resolution of the signals only needs to be enough to resolve the water level phenomenon of interest (i.e. tide variations, surge event). The tidal signals are not re-used, therefore the signal should be at least as long as the simulation time.

The zs0file file must adhere to the following format where the last three columns are optional depending on the value of tideloc and tlen represents the value of tidelen:

tide.txt

<time 1> <zs 1,1> [<zs 2,1> [<zs 3,1> <zs 4,1>]]
<time 2> <zs 1,2> [<zs 2,2> [<zs 3,2> <zs 4,2>]]
<time 3> <zs 1,3> [<zs 2,3> [<zs 3,3> <zs 4,3>]]

...

<time tlen> <zs 1,tlen> [<zs 2,tlen> [<zs 3,tlen> <zs 4,tlen>]]


In case of a single tidal signal, the signal is imposed on both offshore corners of the domain, while a constant water level defined by the keyword zs0 is imposed on the landward corners.

The water level variations can be imposed in different ways. These different options can be selected with the keyword tidetype. When the tidetype is set to velocity, the water level variations are forced with a time-varying velocity at the boundary. With the tidetype instant option the water level variations are not forced at the boundary, but internally generated. In all the wet cells the water level is adjusted to match the forced water level signal. Note that this option can also be applied in combination with tideloc = 2 or 4. The tidetype hybrid is a combination of both options. The water level variations are both forced partly at the boundary and partly internally. This option first adjusts the water level inside the model domain and correct for the water level signal at the boundary with a slowly varying velocity. The advantage of this hybrid option is that higher morfac parameters can be applied since the water level is directly adjusted in the domain. Furthermore, less artificial (VLF) waves are generated at the boundary.

Table 14 Overview of available keywords related to tide boundary conditions

parameter

description

default

range

units

paulrevere

Specifies tide on sea and land or two sea points if tideloc = 2

land

land, sea

tideloc

Number of corner points on which a tide time series is specified

0

0 - 4

zs0file

Name of tide boundary condition series

<file>

## Water level (dam break)¶

Water levels can be imposed on the model boundaries as explained in Time-varying tide/surge after which the shallow water equations force the water body in the model domain. Specific applications may require the initialization of the entire water body in the model domain at the start of the simulation. For example, an initial significant gradient in the water level that ‘collapses’ at the start of the simulation may simulate a dam break. The initialization of the water level in the model domain is governed by the keywords listed in the table below.

The keyword zsinitfile references an external file describing the initial water levels in the entire model domain. The file should have the same format as the bathymetry input files described in Grid and bathymetry.

Table 15 Overview of available keywords related to initial conditions

parameter

description

default

range

units

hotstartflow+

Switch for hotstart flow conditions with pressure gradient balanced by wind and bed stress

0

0 - 1

zs0

Inital water level

0.0

-5.0 - 5.0

m

zsinitfile

Name of inital water level file

<file>

## Wind input¶

Spatially-uniform winds can parametrically defined using the keywords windv and windth that represent the wind velocity and direction (nautical convention) respectively. Time-varying winds can be defined in an external file referenced by the windfile keyword. The file should adhere to the format indicated below. The total length of the time series is automatically determined and should be at least as long as the simulation time.

wind.txt

<time 1> <windv 1> <windth 1>
<time 2> <windv 2> <windth 2>
<time 3> <windv 3> <windth 3>

...


The table below gives an overview of all keywords related to the wind:

Table 16 Overview of available keywords related to wind parameters

parameter

description

default

range

units

Cd+

Wind drag coefficient

0.002

0.0001 - 0.01

rhoa+

Air density

1.25

1.0 - 2.0

kgm^-3

windfile

Name of file with non-stationary wind data

<file>

windth

Nautical wind direction, in case of stationary wind

270.0

-360.0 - 360.0

deg

windv

Wind velocity, in case of stationary wind

0.0

0.0 - 200.0

ms^-1

## Hotstart (beta)¶

In XBeach it is possible to start a simulation based on a hotstart file from a previous simulation. In this way it is for instance not needed to simulate the time required for the waves to travel to the coast (spin-up time), but the model can directly continue based on the output from a previous simulation. Furthermore, when the option to write hotstart files during a simulation is enabled (keyword writehotstart), it is possible to continue a finished simulation.

To write a hotstart file during a simulation, the keyword writehotstart can be used. With the keyword tinth the output interval (in seconds) can be specified with respect to t=0. When tinth is not specified, the hotstart is written at the end of the simulation.

To start an XBeach model based on a hotstart file, the keyword hotstart must be set to 1. The hotstartfileno keyword can be used to select the hotstart file number to initialize the simulation. For example, when 6 hotstart files are generated in a previous simulation, hotstartfileno can be set to 1 to 6.

This functionality is a beta feature and not fully tested.

## Rainfall (beta)¶

To include rainfall in the simulation the keyword rainfall can be set to 1. It is possible to specify a constant and spatially-uniform rainfallrate with the keyword rainfallrate (in mm/hr). Alternatively, by refering keyword rainfallratefile to a file, a spatially and/or temporally varying rainfall can be applied. The number of rainfall moments in the file is specified with the keyword nrainfallrate. This user-input file with rainfall rates is given by the same format as the setbathyfile (see Section Bed update).

## Sediment input¶

The sediment input determines the (initial) composition of the bed and the detail in which processes related to sediment sorting are resolved. This is different from how the sediment transport processes are handled in the model itself and that are described in Sediment transport and Bottom updating

The simplest situation is an XBeach simulation with uniform sediment. In this case it is sufficient to specify the uniform grain size using the keyword D50 indicating the median grain size. The effects of a specific sediment distribution can be parametrically defined by additionally specifying values for D15 and D90 and optionally the bed composition can be fine-tuned by specifying the porosity and sediment density using the keywords por and rhos respectively. In this case no sorting of sediment will be simulated.

If the effect of different sediment fractions, sorting and armoring are of importance, multiple sediment fractions can be defined. The number of sediment fraction is determined by the keyword ngd. For each sediment fraction a value for D50, and optionally D15 and D90, should be defined separated by a space. Moreover, when using multiple sediment fractions, multiple bed layers are needed as well. The number of bed layers can be defined using the keyword nd.

Three types of bed layers are distinguished: 1) the top layer 2) the variable or ‘breathing’ layer and 3) the bottom layers. At least one of each type of bed layer is needed, which makes that at least three bed layers are required (see Bed composition). Each bed layer has a thickness. Choosing bed layer thicknesses that are in balance with the expected erosion and deposition during the simulation should keep the numerical mixing to a minimum. A bed layer thickness that is too large will result in relatively uniform behavior, while a bed layer thickness that is too small will result in a lot of shifting and thus numerical mixing. The bed layer thicknesses are determined by the three keywords dzg1, dzg2 and dzg3 for the top, variable and bottom layers respectively.

Apart from the discretization of the grain size distribution and the vertical structure of the bed, the initial bed composition needs to be defined. The bed composition is defined using external files that are not explicitly referenced from params.txt, but are assumed to be located in the working directory of the model (next to params.txt). There is one file for each sediment fraction specified by ngd. The file corresponding to the first sediment fraction is named gdist1.inp, the second gdist2.inp, et cetera.

The bed composition files hold information on how much sediment of a specific fraction is in each grid cell and bed layer at the start of the simulation. The values are a volumetric fraction that implies that they should add up to unity over all fractions. For example, if a specific grid cell is filled with the first sediment fraction only, the value corresponding to this grid cell will be one in the gdist1.inp file and zero in all others. Alternatively, if we defined five sediment fractions and a specific grid cell is filled equally with all fractions, the value corresponding to this grid cell will be 1/5 = 0.2 in all files. The gidst< N >.inp files are formatted comparable to the bathymetry files (see Grid and bathymetry), but now holds values over the three dimensions x (nx+1), y (ny+1) and the bed layers (nd). The file format is as follows:

gdist1.inp

<p 1,1,1> <p 1,2,1> <p 1,3,1> ... <p 1,nx,1> <p 1,nx+1,1>
<p 1,1,2> <p 1,2,2> <p 1,3,2> ... <p 1,nx,2> <p 1,nx+1,2>
<p 1,1,3> <p 1,2,3> <p 1,3,3> ... <p 1,nx,3> <p 1,nx+1,3>

...

<p 1,1,ny> <p 1,2,ny> <p 1,3,ny> ... <p 1,nx,ny> <p 1,nx+1,ny>
<p 1,1,ny+1> <p 1,2,ny+1> <p 1,3,ny+1> ... <p 1,nx,ny+1> <p 1,nx+1,ny+1>

...

<p 2,1,1> <p 2,2,1> <p 2,3,1> ... <p 2,nx,1> <p 2,nx+1,1>
<p 2,1,2> <p 2,2,2> <p 2,3,2> ... <p 2,nx,2> <p 2,nx+1,2>
<p 2,1,3> <p 2,2,3> <p 2,3,3> ... <p 2,nx,3> <p 2,nx+1,3>

...

<p 2,1,ny> <p 2,2,ny> <p 2,3,ny> ... <p 2,nx,ny> <p 2,nx+1,ny>
<p 2,1,ny+1> <p 2,2,ny+1> <p 2,3,ny+1> ... <p 2,nx,ny+1> <p 2,nx+1,ny+1>

...

<p nd,1,1> <p nd,2,1> <p nd,3,1> ... <p nd,nx,1> <p nd,nx+1,1>
<p nd,1,2> <p nd,2,2> <p nd,3,2> ... <p nd,nx,2> <p nd,nx+1,2>
<p nd,1,3> <p nd,2,3> <p nd,3,3> ... <p nd,nx,3> <p nd,nx+1,3>

...

<p nd,1,ny> <p nd,2,ny> <p nd,3,ny> ... <p nd,nx,ny> <p nd,nx+1,ny>
<p nd,1,ny+1> <p nd,2,ny+1> ... <p nd,nx,ny+1> <p nd,nx+1,ny+1>


The table below gives an overview of all keywords related to working with multiple sediment fractions and bed layers:

Table 17 Overview of available keywords related to bed composition parameters

parameter

description

default

range

units

dzg1+

Thickness of top sediment class layers

par%dzg1

0.01 - 1.0

m

dzg2+

Nominal thickness of variable sediment class layer

par%dzg1

0.01 - 1.0

m

dzg3+

Thickness of bottom sediment class layers

par%dzg1

0.01 - 1.0

m

nd+

Number of computational layers in the bed

3

3 - 1000

ngd

Number of sediment classes

1

1 - 20

por

Porosity

0.4

0.3 - 0.5

rhos

Solid sediment density (no pores)

2650.0

2400.0 - 2800.0

kgm^-3

ws

Average fall velocity (is computed in morphevolution)

0.02d0

m/s

## Avalanching¶

Avalanching can be disabled with the keyword avalanching. The critical slope for both dry and wet cells is given by the keyword wetslp and dryslp respectively.

## Vegetation input¶

Short wave dissipation, long wave dissipation and flow interaction due to vegetation is supported. The user can define multiple vegetation species. The number of vegetation species is set by the keyword nveg. Furthermore, two files should be created and specified in the params.txt-file: a vegetation characteristics file (keyword: veggiefile) and a vegetation location file (keyword: veggiemapfile).

The veggiefile is a text file listing the names of the vegetation characteristics files that should be created for every individual vegetation species that should be accounted for. These property files contain the vegetation parameters nsec, ah, Cd, bv and N that represent the number of vertical sections, height of vegetation section relative to the bed , the drag coefficient, stem diameter and vegetation density per vegetation section, respectively. An example of a set of files describing two different vegetation species is given below.

veggiefile.txt

seagrass.txt
mangrove.txt


seagrass.txt

ah = 0.2
Cd = 1.0
bv = 0.02
N = 1200


mangrove.txt

nsec = 3
ah = 0.5 0.8 1.3
Cd = 2.0 1.0 2.0
bv = 0.05 0.15 0.1
N = 1000 50 500


The nsec keyword in the species property file allows the user to define multiple height segments of the species with different properties. The height per vegetation section is defined relative to the bed level. For all properties, the values are given from bottom to top. A definition sketch is given in Fig. 11.

Fig. 11 Definition sketch of vegetation specification in XBeach (example for mangrove type vegetation schematized in three vertical sections).

Finally, the veggiemapfile indicates in what grid cell which vegetation species can be found. The format of this file is similar to the bathymetry files described in Grid and bathymetry, but the values are integers referring to a species where 1 refers to the first listed species, 2 to the second, et cetera. A zero indicates no vegetation at that particular location. The use of non-integer values in this file will result in an error.

In summary, the following files should be created when the effect of vegetation is modeled:

1. 1 x Veggiemapfile: file similar to bathymetry file containing 0, 1 etc. (up to nveg)

2. 1 x Veggiefile: list of file names of vegetation property files per species

3. nveg x vegetation property file(s): describing vegetation properties per species

Below the relevant keywords in the params.txt are given. In addition, the keyword vegetation should be set to 1.

Table 18 Overview of available keywords related to vegetation parameters

parameter

description

default

range

units

nveg

Number of vegetation species

-123

vegcanflo

Include incanopy flow [1] or not [0]

0

0 - 1

veggiefile

Name of veggie species list file

veggiemapfile

Name of veggie species map file

vegnonlin

Include non-linear wave effect [1] or not [0]

0

0 - 1

veguntow

Include undertow in phase-averaged vegetati

1

0 - 1

## Porous in-canopy model input¶

The porous in-canopy model is aplied when the keyword porcanflow is set and the the physical process vegetation is included. A spatial varying canopy property can be used within the in-canopy model. This input is according to the vegetation input. Thus, the different coral types are described in the veggiefile and the location in the veggiemapfile. It is not possible to have different vertical sections in the canopy. Only the first vertical section is applied in the in-canopy model (nsec=1). The property file describes the canopy parameters ah, Cd, bv and N that represent the canopy height, drag coefficient, friction coefficient and the porosity (in percentage). The inertia coefficient is set by the keyword Cm and the permeability is set by the keyword Kp. An example of a property file is shown below for a coral,

coral.txt

nsec = 1
ah = 0.2
Cd = 15
bv = 0.1
N = 85


## Discharge input¶

Discharge of water at the model boundaries or directly in the model domain is defined along specific grid sections. The keywords ndischarge and ntdischarge define the number of discharge sections and the length of the discharge time series respectively. The disch_loc_file keyword references a file that defines the discharge sections. Each line in this file corresponds to a grid section and each line contains four numbers being the start and end coordinates of the section. The file is formatted as follows, where ndisch refers to the keyword ndischarge:

disch_loc.txt

<x_start 1> <y_start 1> <x_end 1> <y_end 1>
<x_start 2> <y_start 2> <x_end 2> <y_end 2>
<x_start 3> <y_start 3> <x_end 3> <y_end 3>

...

<x_start ndisch> <y_start ndisch> <x_end ndisch> <y_end ndisch >


The world coordinates specified in this file must be chosen such that they are close to the desired grid cell borders, since the grid cell borders are eventually used as discharge section. Discharge sections can be located along grid cell borders that are either oriented cross-shore or alongshore, but not a combination of the two. In a regular grid this implies that either the start or end x-coordinates are equal, or the start and end y-coordinates are equal. Alternatively, both are equal. In this case a vertical discharge from above is assumed, rather than a horizontal discharge. Vertical discharges only add mass and no momentum to the water body.

The keyword disch_timeseries_file references a file defining the time series imposed on the discharge locations. The file lists the timings in the first column and a discharge value in for each discharge section as follows, where ntdisch refers to the keyword ntdischarge:

disch_timeseries.txt

<t 1> <Q 1,1> <Q 2,1> ... <Q ndisch,1>
<t 2> <Q 1,2> <Q 2,2> ... <Q ndisch,2>
<t 3> <Q 1,3> <Q 2,3> ... <Q ndisch,3>

...

<t ntdisch> <Q 1,ntdisch> <Q 2,ntdisch> ... <Q ndisch,ntdisch >


Discharges defined at the domain borders are positive in direction towards the domain (influx). Discharges defined in the domain itself are positive in direction of the positive x or y direction. Vertical discharges are positive into the domain (influx).

Fig. 12 Possible discharge orifices. A discharge orifice is defined as line in between two points (red). The resulting discharge orifice constitutes out of full abreast grid cells (green). The discharge direction is in positive grid direction (s or n), except at the domain border where the discharge is an influx in the domain (green arrows).

The table below gives an overview of all keywords related to discharges:

Table 19 Overview of available keywords related to flow discharge boundary conditions

parameter

description

default

range

units

disch_loc_file+

Name of discharge locations file

<file>

disch_timeseries_file+

Name of discharge timeseries file

<file>

ndischarge+

Number of discharge locations

par%ndischarge

0 - 100

ntdischarge+

Length of discharge time series

par%ntdischarge

0 - 100

## Drifters input¶

Drifters can be deployed during the model simulation by specifying the number of drifters using the keyword ndrifter and the location, start and end time of the drifter deployment in a separate file referenced by the drifterfile keyword. The file format is as follows:

drifter.txt

<x 1> <y 1> <t_start 1> <t_end 1>
<x 2> <y 2> <t_start 2> <t_end 2>
<x 3> <y 3> <t_start 3> <t_end 3>

...

<x ndrifter> <y ndrifter> <t_start ndrifter> <t_end ndrifter>


The table below gives an overview of all keywords related to drifters:

Table 20 Overview of available keywords related to drifters parameters

parameter

description

default

range

units

drifterfile

Name of drifter data file

<file>

ndrifter

Number of drifers

par%ndrifter

0 - 50

## Ship-induced wave motions¶

Ship waves can be simulated by defining the ships’ geometries and trajectories in a collection of files. The user can define multiple ships. The number of ships is set by the keyword nship. In the file referenced by the keyword shipfile each ship is given a name. The properties of each ship are summarized in another textfile with the name of the ship (shipname.txt). This properties file defines the parameters for the discretization of the ships geometry. The ship grid is determined by the keywords dx, dy, nx, and ny, and the ship geometry itself is given in a separate file, referenced bythe keyword shipgeom. This file contains the ship draft per ship grid point, and should have a size of nx + 1 by ny + 1. The center of gravity of the ship is also defined in the ship properties file using the keywords xCG, yCG and zCG. The ships trajectory is defined in a file referenced from the ship properties file by the keyword shiptrack. Each row in this file contains a time, x- and y-coordinate indicating the ships position as function of time.

To avoid numerical problems, the full ship track should be within the model domain (i.e. a vessel cannot sail through the model boundary). Furthermore, it is advised to start the ship track with a very low velocity and gradually increase the sailing speed. When not taking into account such spin up period, the impact of the ship on the water level can be too abrupt, resulting in unrealistic wave patterns. In addition, it is advised to maintain a relatively deep edge of a few grid cells at both model boundaries (i.e. front and back side).

Another way to avoid numerical issues at the initialization of a ship simulation is to use the ‘flying’ option, which can be specified in the ship file (flying = 1). In case the option flying is enabled, also a z-coordinate is defined in the shiptrack-file indicating the vertical position of the ship. In this way, the vessel can ‘land’ on the water with its correct sailing speed, thereby avoiding unwanted disturbance to the water level. Also, the ship can ‘fly out’f the model domain before reaching the back boundary. By using this method the spin-up time can be reduced considerably and both inflow and outflow boundaries are unaffected by the ship

The two keywords compute_force and compute_motion enable the computation of forces on the ship and the ships motions due to wave forcing respectively; the latter has not been implemented yet. Forces on a ship in motion may be unreliable due to near-field effects; forces on a ship at rest are much more reliable. An example of ship definition files is:

shipfile.txt

containership.txt
oiltanker.txt


containership.txt

dx = 10
dy = 10
nx = 30
ny = 10
shipgeom = container_geom.dep
xCG = 120
yCG = 50
zCG = 30
shiptrack = container_track.txt
flying = 1
compute_force = 1
compute_motion = 1


pannamax_geom.txt

<z 0,0> <z 1,0> <z 2,0> <z 3,0> ... <z nx,0> <z nx+1,0>
<z 0,1> <z 1,1> <z 2,1> <z 3,1> ... <z nx,1> <z nx+1,1>

...

<z 0,ny> <z 1,ny> <z 2,ny> <z 3,ny> ... <z nx,ny> <z nx+1,ny>
<z 0,ny+1> <z 1,ny+1> <z 2,ny+1> <z 3,ny+1> ... <z nx,ny+1> <z nx+1,ny+1>


pannamax_track.txt

<t 1> <x 1> <y 1> <z 1>
<t 2> <x 2> <y 2> <z 2>
<t 3> <x 3> <y 3> <z 3>

...


oiltanker.txt

dx = 2
dy = 2
nx = 20
ny = 4
shipgeom = tanker_geom.dep
xCG = 20
yCG = 40
zCG = 1.5
shiptrack = tanker_track.txt
flying = 0


tanker_track.txt

<t 1> <x 1> <y 1>
<t 2> <x 2> <y 2>
<t 3> <x 3> <y 3>

...

Table 21 Overview of available keywords related to ship parameters

parameter

description

default

range

units

nship+

Number of ships

-123

shipfile

Name of ship data file

<file>

## Output selection¶

Output selection determines what data computed by XBeach is written to a file in terms of location and time and in what format. The output types, output times and output formats supported by XBeach are explained in more detail in the following subsections. The table below gives an overview of all keywords related to model output:

Table 22 Overview of available keywords related to output variables

parameter

description

default

range

units

ncfilename+

Xbeach netcdf output file name

<file>

nglobalvar

Number of global output variables (as specified by user)

-1

-1 - 20

nmeanvar

Number of mean, min, max, var output variables

0

0 - 15

npoints

Number of output point locations

0

0 - 50

npointvar

Number of point output variables

0

0 - 50

nrugauge

Number of output runup gauge locations

0

0 - 50

nrugdepth+

Number of depths to compute runup in runup gauge

1

1 - 10

outputformat+

Output file format

fortran

fortran, netcdf, debug

outputprecision

Switch between single and double precision output in netcdf

double

single, double

timings+

Switch enable progress output to screen

1

0 - 1

tintc+

Interval time of cross section output

-123

s

tintg

Interval time of global output

1.0

0.01 - par%tstop-par%tstart

s

tintm

Interval time of mean, var, max, min output

par%tstop-par%tstart

1.0 - par%tstop-par%tstart

s

tintp

Interval time of point and runup gauge output

1.0

0.01 - par%tstop-par%tstart

s

tsglobal+

Name of file containing timings of global output

tsmean+

Name of file containing timings of mean, max, min and var output

tspoints+

Name of file containing timings of point output

tstart

Start time of output, in morphological time

0.0

0.0 - par%tstop

s

### Output types¶

XBeach supports four different types of output: 1) instantaneous spatial output 2) time-averaged spatial output 3) fixed point output or 4) run-up gauge output. In principle any variable in XBeach can be outputted as long as it is part of the spaceparams structure defined in variables.f90 in the XBeach source code. An overview of all currently supported parameters in this file is presented in Table 23.

The amount of output variables used for each type is determined by the keywords nglobalvar, nmeanvar, npoints and nrugauge. Each of these keywords takes a number indicating the number of parameters or locations that should be written to file. If any of the keywords is set to zero, the output type is effectively disabled. If nglovalvar is set to -1 then a standard set of output variables is used, being H, zs, zs0, zb, hh, u, v, ue, ve, urms, Fc, Fy, ccg, ceqsg, ceqbg, Susg, Svsg, E, R, D and DR. If nglobalvar is not set it defaults to -1. The lines in the params.txt file immediately following these keywords determine what parameters or locations are used, as will be explained in more detail in the following subsections.

Table 23 Overview of available keywords related to *

parameter

description

default

range

units

As

Asymmetry of short waves

BR

Maximum wave surface slope used in roller dissipation formulation

Cdrag

Vegetation drag coefficient

D

Dissipation

W/m2

D15

D15 grain diameters for all sediment classses

m

D50

D50 grain diameters for all sediment classses

m

D50top

Friction coefficient flow

D90

D90 grain diameters for all sediment classses

m

D90top

Friction coefficient flow

DR

Roller energy dissipation

W/m2

Dc

Diffusion coefficient

m2/s

Df

Dissipation rate due to bed friction

W/m2

Dp

Dissipation rate in the swash due to transformation of kinetic wave energy to potential wave energy

W/m2

Dveg

Dissipation due to short wave attenuation by vegetation

W/m2

E

Wave energy

Nm/m2

Fvegu

X-forcing due to long wave attenuation by vegetation

N/m2

Fvegv

Y-forcing due to long wave attenuation by vegetation

N/m2

Fx

Wave force, x-component

N/m2

Fy

Wave force, y-component

N/m2

H

Hrms wave height based on instantaneous wave energy

m

Hrunup

Short wave height used in runup formulation

m

L1

Wave length (used in dispersion relation)

m

Qb

Fraction breaking waves

R

Roller energy

Nm/m2

Sk

Skewness of short waves

Subg

Bed sediment transport for each sediment class (excluding pores), x-component

m2/s

Susg

Suspended sediment transport for each sediment class (excluding pores), x-component

m2/s

Sutot

Sediment transport integrated over bed load and suspended and for all sediment grains, x-component

m2/s

Svbg

Bed sediment transport for each sediment class (excluding pores), y-component

m2/s

Svsg

Suspended sediment transport for each sediment class (excluding pores), y-component

m2/s

Svtot

Sediment transport integrated over bed load and suspended and for all sediment grains, y-component

m2/s

Sxx

N/m

Sxy

N/m

Syy

N/m

Tbore

Wave period interval associated with breaking induced turbulence

s

Tsg

Sediment response time for each sediment class

s

alfau

Grid orientation at u-point

alfav

Grid orientation at v-point

alfaz

Grid orientation at z-point

bedfriccoef

Dimensional/dimensionless input bed friction coefficient; depends on value of parameter bedfriction

bi

Incoming bound long wave

m

breaking

Indicator whether cell has breaking nonh waves

bwalpha

Beachwizard weighting factor

c

Wave celerity

m/s

ca

Reference concentration

m3/m3

ccg

Depth-averaged suspended concentration for each sediment fraction

m3/m3

cctot

Sediment concentration integrated over bed load and suspended and for all sediment grains

m3/m3

ccz

Concentration profile

m3/m3

ceqbg

Depth-averaged bed equilibrium concentration for each sediment class

m3/m3

ceqsg

Depth-averaged suspended equilibrium concentration for each sediment class

m3/m3

cf

Friction coefficient flow

cfu

Friction coefficient flow in u-points

cfv

Friction coefficient flow in v-points

cg

Group velocity

m/s

cgx

Group velocity, x-component

m/s

cgx_s

Group velocity, x-component

m/s

cgy

Group velocity, y-component

m/s

cgy_s

Group velocity, y-component

m/s

cobs

Beachwizard observed wave celerity

m/s

costh

Cos of wave angles relative to grid direction

costh_s

Cos of wave angles relative to grid direction

ctheta

Wave celerity theta-direction (refraction)

ctheta_s

Wave celerity theta-direction (refraction)

cx

Wave celerity, x-component

m/s

cy

Wave celerity, y-component

m/s

dU

U-velocity difference between two vertical layers (reduced 2-layer non-hydrostatic model)

m2/s2

dUi

Velocity difference at boundary due to (short) waves

m/s

dV

V-velocity difference between two vertical layers (reduced 2-layer non-hydrostatic model)

m2/s2

dassim

Beachwizard depth change

m

dcbdx

kg/m3/m

dcbdy

kg/m3/m

dcmdo

Beachwizard computed minus observed dissipation

W/m2

dcsdx

kg/m3/m

dcsdy

kg/m3/m

depo_ex

Explicit bed deposition rate per fraction

m/s

depo_im

Implicit bed deposition rate per fraction

m/s

dinfil

Infiltration layer depth used in quasi-vertical flow model for groundwater

m

dnc

Grid distance in n-direction, centered around c-point

m

dnu

Grid distance in n-direction, centered around u-point

m

dnv

Grid distance in n-direction, centered around v-point

m

dnz

Grid distance in n-direction, centered around z-point (=eta-point)

m

dobs

Beachwizard observed dissipation

W/m2

dsc

Grid distance in s-direction, centered around c-point

m

dsdnui

Inverse of grid cell surface, centered around u-point

1/m2

dsdnvi

Inverse of grid cell surface, centered around v-point

1/m2

dsdnzi

Inverse of grid cell surface, centered around z-point

1/m2

dsu

Grid distance in s-direction, centered around u-point

m

dsv

Grid distance in s-direction, centered around v-point

m

dsz

Grid distance in s-direction, centered around z-point (=eta-point)

m

dzav

Total bed level change due to avalanching

m

dzbdt

Rate of change bed level

m/s

dzbdx

dzbdy

dzbed

No description

dzbnow

Bed level change in current time step

m

dzs0dn

Alongshore water level gradient due to tide alone

dzsdt

Rate of change water level

m/s

dzsdx

m/s

dzsdy

m/s

ee

Directionally distributed wave energy

ee_s

Directionally distributed wave energy

ero

Bed erosion rate per fraction

m/s

fw

Wave friction coefficient

gw0back

Boundary condition back boundary for groundwater head

m

gwbottom

Level of the bottom of the aquifer

m

gwcurv

Curvature coefficient of groundwater head function

m

Groundwater head at bottom (differs from gwlevel)

m

gwheight

Vertical size of aquifer through which groundwater can flow

m

gwlevel

m

gwqx

Groundwater discharge in x-direction

m/s

gwqy

Groundwater discharge in y-direction

m/s

gwu

Groundwater flow in x-direction

m/s

gwv

Groundwater flow in y-direction

m/s

gww

Groundwater flow in z-direction (interaction between surface and ground water)

m/s

hh

Water depth

m

hhw

Water depth used in all wave computations, includes h*par%delta

m

hhwcins

Water depth used in wave instationary computation in case of wci

m

hhws

Water depth used in wave stationary computation (and single_dir wave directions)

m

hold

Water depth previous time step

m

hu

Water depth in u-points

m

hum

Water depth in u-points

m

hv

Water depth in v-points

m

hvm

Water depth in v-points

m

idrift

Drifter x-coordinate in grid space

infil

Rate of exchange of water between surface and groundwater (positive from sea to groundwater)

m/s

istruct

Location of revetments toe

iwl

Location of water line (including long wave runup)

jdrift

Drifter y-coordinate in grid space

k

Wave number

kb

Near bed turbulence intensity due to depth induces breaking

m2/s2

kturb

Depth averaged turbulence intensity due to long wave breaking

m2/s2

maxzs

Maximum elevation in simulation

m

minzs

Minimum elevation in simulation

m

n

Ratio group velocity/wave celerity

nd

Number of bed layers (can be different for each computational cell)

ndist

Cum. distance from right boundary along n-direction

m

nuh

Horizontal viscosity coefficient

m2/s

nutz

Turbulence viscosity

pbbed

No description

pdisch

Discharge locations

ph

m

pntdisch

Point discharge locations (no momentum)

pres

Normalized dynamic pressure

m2/s2

qdisch

Discharges

m2/s

qx

Discharge in u-points, x-component

m2/s

qy

Discharge in u-points, y-component

m2/s

refA

Reference level

m

rolthick

Long wave roller thickness

m

rr

Directionally distributed roller energy

runup

Short wave runup height

m

sdist

Cum. distance from offshore boundary along s-direction

m

sedcal

Equilibrium sediment concentartion factor for each sediment class

sedero

Cum. sedimentation/erosion

m

setbathy

Prescribed bed levels

m

shipFx

Force on ship in x-direction

N

shipFy

Force on ship in y-direction

N

shipFz

Force on ship in z-direction

N

shipMx

Moment on ship around x-axis

Nm

shipMy

Moment on ship around y-axis

Nm

shipMz

Moment on ship around z-axis

Nm

shipchi

Turning angle arround y-axis

deg

shipphi

Turning angle arround x-axis

deg

shippsi

Turning angle arround z-axis

deg

shipxCG

X-coordinate of ship center of gravity

m

shipyCG

Y-coordinate of ship center of gravity

m

shipzCG

Z-coordinate of ship center of gravity

m

shobs

Beachwizard observed shoreline

m

sig2prior

Beachwizard prior std squared

m2

sigm

Mean frequency

sigt

Relative frequency

sigz

Vertical distribution of sigma layers q3d

sinth

Sin of wave angles relative to grid direction

sinth_s

Sin of wave angles relative to grid direction

strucslope

Slope of structure

structdepth

Depth of structure in relation to instantaneous bed level

m

taubx

Bed shear stress, x-component

N/m2

Additional bed shear stress due to boundary layer effects, x-component

N/m2

tauby

Bed shear stress, y-component

N/m2

Additional bed shear stress due to boundary layer effects, y-component

N/m2

tdisch

Discharge time series

tdriftb

Drifter release time

s

tdrifte

Drifter retrieval time

s

thet

Wave angles

thet_s

Wave angles

theta

Wave angles directional distribution w.r.t. comp. x-axis

theta_s

Wave angles directional distribution w.r.t. comp. x-axis

thetamean

Mean wave angle

tideinpt

Input time of input tidal signal

s

tideinpz

Input tidal signal

m

tsetbathy

Points in time of prescibed bed levels

s

u

Glm velocity in cell centre, x-component

m/s

ua

Time averaged flow velocity due to wave assymetry

m/s

ucrcal

Calibration factor for u critical for each sediment class

ududx

m2/s2

udvdx

m2/s2

ue

Eulerian velocity in cell centre, x-component

m/s

ue_sed

Advection velocity sediment in cell centre, x-component

m/s

ueu

Eulerian velocity in u-points, x-component

m/s

ui

Incident bound wave velocity in, x-component

m/s

umean

Longterm mean velocity at bnds in u-points, x-component

m/s

umwci

Velocity (time-averaged) for wci, x-component

m/s

ur

Reflected velocity at bnds in u-points

m/s

urepb

Representative flow velocity for sediment advection and diffusion, x-component

m/s

ureps

Representative flow velocity for sediment advection and diffusion, x-component

m/s

urms

Orbital velocity

m/s

usd

Return flow due to roller after breaker delay

m/s

ust

Stokes drift

m/s

ustr

Return flow due to roller

m/s

ustz

Stokes velocity (q3d)

uu

Glm velocity in u-points, x-component

m/s

uv

Glm velocity in v-points, x-component

m/s

uwcins

U-velocity used in wave stationary computation in case of wci

m/s

uwf

Stokes drift, x-component

m/s

uws

U-velocity used in wave stationary computation (and single_dir wave directions)

m/s

uz

Velocity (q3d) ksi-comp

v

Glm velocity in cell centre, y-component

m/s

vdudy

m2/s2

vdvdy

m2/s2

ve

Eulerian velocity in cell centre, y-component

m/s

ve_sed

Advection velocity sediment in cell centre, y-component

m/s

vegtype

Vegetation type index

vev

Eulerian velocity in u-points, y-component

m/s

vi

Incident bound wave velocity in, y-component

m/s

viscu

Viscosity

m2/s2

viscv

Viscosity

m2/s2

vmag

Velocity magnitude in cell centre

m/s

vmageu

Eulerian velocity magnitude u-points

m/s

vmagev

Eulerian velocity magnitude v-points

m/s

vmagu

Glm velocity magnitude u-points

m/s

vmagv

Glm velocity magnitude v-points

m/s

vmean

Longterm mean velocity at bnds in u-points, y-component

m/s

vmwci

Velocity (time-averaged) for wci, y-component

m/s

vrepb

Representative flow velocity for sediment advection and diffusion, y-component

m/s

vreps

Representative flow velocity for sediment advection and diffusion, y-component

m/s

vu

Glm velocity in u-points, y-component

m/s

vv

Glm velocity in v-points, y-component

m/s

vwcins

V-velocity used in wave stationary computation in case of wci

m/s

vwf

Stokes drift, y-component

m/s

vws

V-velocity used in wave stationary computation (and single_dir wave directions)

m/s

vz

Velocity (q3d) eta-comp

wb

Vertical velocity at the bottom

m/s

wete

wetu

wetv

wetz

wi

Vertical velocity at boundary due to (short) waves

m/s

winddirts

Input wind direction

deg_nautical

windinpt

Input time of input wind signal

s

windnv

Wind velocity in n direction in v point at current time step

m/s

windsu

Wind velocity in s direction in u point at current time step

m/s

windvelts

Input wind velocity

m/s

windxts

Time series of input wind velocity (not s direction), x-component

m/s

windyts

Time series of input wind velocity (not n direction), y-component

m/s

wm

Mean abs frequency

ws

Vertical velocity at the free surface

m/s

wscrit

Critial vertical velocity at the free surface for breaking

m/s

x

X-coord. original cmp. grid

m

xHrunup

Location at which short wave height for runup is taken

m

xu

X-coord. comp. grid u-points

m

xv

X-coord. comp. grid v-points

m

xyzs01

Global xy coordinates of corner (x=1,y=1)

xyzs02

Global xy coordinates of corner (x=1,y=n)

xyzs03

Global xy coordinates of corner (x=n,y=n)

xyzs04

Global xy coordinates of corner (x=n,y=1)

xz

X-coord. comp. grid (positive shoreward, perp. to coastline)

m

y

Y-coord. original comp. grid

m

yu

Y-coord. comp. grid u-points

m

yv

Y-coord. comp. grid v-points

m

yz

Y-coord. comp. grid

m

z0bed

No description

zb

Bed level

m

zb0

Initial bed level

m

zbobs

Beachwizard observed depth

m

zi

Surface elevation at boundary due to (short) waves

m

zs

Water level

m

zs0

Water level due to tide alone

m

zs0fac

Relative weight of offshore boundary and bay boundary for each grid point is stored in zs0fac

zs1

Water level minus tide

m

zswci

Waterlevel (time-averaged) for wci

m

#### Instantaneous spatial output¶

Instantaneous spatial output describes the instantaneous state of variables across the entire model domain at various points in time. To make use of this option the user must specify the number of output variables required using the nglobalvar keyword in params.txt, immediately followed by the names of the requested variables on a separate line each. The output of three instantaneous grids can look as follows:

params.txt

nglobalvar = 3
zs
zb
H


#### Time-averaged spatial output¶

Time-averaged spatial output describes the time-averaged state of variables across the entire model domain at various points in time. The user can define the averaging period in params.txt. To make use of this option the user must specify the number of output variables required using the nmeanvar keyword in params.txt, immediately followed by the names of the requested variables on a separate line each. The output of two time-averaged grids may look as follows:

params.txt

nmeanvar = 2
u
v


#### Fixed point output¶

Fixed point output allows the user to select one or more locations for which a time series of data is stored. This output describes a time-series of one or more variables at one point in the model domain. To make use of this option, the user must specify the number of output locations using the npoints keyword in params.txt, immediately followed by one line per output location describing the location coordinates given as the x-coordinate and y-coordinate and in world coordinates. XBeach will link the output location to the nearest computational point.

The user can specify the number and selection of output variables for all points (and run-up gauges, discussed in the following section) using the npointvar keyword in params.txt to specify the number of output variables, immediately followed by the names of the requested variables on a separate line each.

Fixed point output significantly reduces the amount of data written to file in each time step and is therefore particularly suitable for high temporal resolution output.

An example with two output locations is given below. The first point is located on the offshore boundary (x = 0.0) and somewhere in the middle of the model domain in y-direction (y = 800.0). The second point is located on the lateral boundary (y = 1600.0) and somewhere in the middle of the domain in x-direction (x = 2000.0). Both locations have four output variables: H, zs, zb and D.

params.txt

npoints = 2
0. 800.
2000. 1600.
npointvar = 4
H
zs
zb
D


#### Run-up gauge output¶

Run-up gauge output describes a time-series of a number of variables at the (moving) waterline. In this case XBeach scans in an x-directional transect defined by the user for the location of the waterline. Output information is recorded for this moving point. This is particularly useful to keep track of run-up levels in cross-shore transects.

The definition of run-up gauges is similar to the definition of fixed point output. The user needs to specify the number of run-up gauges using the nrugauge keyword in params.txt, immediately followed by one line per run-up gauge location describing the coordinates of the initial location of the run-up gauge. XBeach will subsequently link the initial run-up gauge location to the nearest computational cross-shore transect rather than just the nearest computational point.

Run-up gauges share their selection of output variables with regular point output. However, in the case of run-up gauges, XBeach will automatically also include the variables xw, yw and zs to the point output variables, if these variables were not specified using the npointvar keyword in params.txt. Note that the user should refer to the pointvars.idx output file to check order of output variables for points and run-up gauges.

An example of a run-up gauge input is given below. The run-up gauge is initially located on the offshore boundary (x = 0.0) and somewhere in the middle of the model domain in y-direction (y = 800.0). The run-up gauge will display standard output variables (xw, yw and zs, as well as any output variables specified by the npointvar keyword).

params.txt

nrugauge = 1
0. 800.


### Output times¶

The user may determine the output times for regular spatial output variables, time averaged spatial variables and point location variables individually. Run-up gauge output and fixed point output are given at the same moments in time. For all three types of output the user may choose to either state a fixed interval time at which output is given or supply an external file containing times at which output should be given or a combination of both.

#### Output at fixed intervals¶

The user should define a point in time after the start of the simulation at which the first output is generated for fixed interval output. The user can do this by using the tstart keyword in params.txt. All output that is being generated at fixed intervals uses tstart as their base. The interval for instantaneous spatial output is given by the tintg keyword. The keywords for the interval of time-averaged spatial output and point output are tintm and tintp respectively, where tintp is used both for fixed point and run-up gauge output. Note that tintg, tintm and tintp supersede the older tint parameter that is valid for all types of output. The default value of tintg is one second. If tintp or tintm is not stated, but output is declared (npoints, nrugauge or nmeanvar is stated larger than zero), XBeach assumes the same output interval as tintg. An example of the definition of fixed intervals is given below.

params.txt

tstart = 100.
tintg = 100.
tintp = 2.
tintm = 3600.


In the case of instantaneous spatial output and point output, the first output is given at tstart. In the case of time-averaged spatial variables, the first output is given at tstart+tintm. This output represents the average condition over the interval between tstart and tstart+tintm.

#### Output times defined by external file¶

The user is given the option to have output at a set of points in time that are not separated by regular intervals. In this case the user must supply an additional file for each output type. The user specifies the name of the output time series file for instantaneous spatial output using the tsglobal keyword. The keywords for time series files for time-averaged spatial output and point output are tsmean and tspoint respectively, where tspoint is again used for both fixed point and run-up gauge output. All time series files must contain on the first line the number of output times followed by every output time on a new line. An example of such irregular output time definition is given below.

params.txt

tsglobal= time_series1.txt
tspoints = time_series2.txt
tsmean= time_series3.txt


time_series1.txt

18
0.05
0.15
0.2
0.8
12.0
12.5
19.124
30.
60.
90.
120.
150.
160.
170.
177.
178.
179.
180.


In the case of instantaneous spatial output and point output, the first output is given at the first stated point in time. In the case of time-averaged spatial variables, the first output is given at the second stated point in time. This output represents the average condition over the interval between first and second stated point in time. Subsequent averaging is done over every interval.

#### Combinations of fixed internal and external files¶

The user is allowed to define certain types of output using fixed intervals and others using external files. The use of an external file supersedes the use of fixed intervals. Note that tstart will only apply to output of fixed interval type. An example of mixing fixed and varying output time intervals is given below.

param.txt

tstart = 100.
tintg = 100.
tspoints = time_series2.txt
tintm = 3600.


### Output format¶

XBeach supports two types of output: 1) Fortran binary and 2) netCDF. The output format used is determined by the keyword outputformat. The use of netCDF output is more convenient since all output (and input) is stored in a single, easy accessible file. Also the netCDF file format is compatible with many programming languages (e.g. Matlab, Python) as well as many visualization tools (e.g. QuickPlot, Morphan). It should be noted that the support for output types in netCDF could be limited for recent functionalities of the XBeach model.

#### Fortran binary¶

Output files in Fortran binary format are bare matrix dumps of XBeach’ computational matrices. At each output time, one such matrix block is added to the output file. These files can generally be read by binary read functions, like fread in Matlab and the struct package in Python.

Output files written in Fortran binary format are given the name < variable >.dat, for example zs.dat, for instantaneous spatial output. The only exception is that files containing information about the wave height of the short waves are called hrms.dat instead of H.dat to maintain backward compatibility. Time-averaged spatial output is stored similarly, but the file names have a suffix indicating the type of averaging < variable >_mean.dat. For time-averaged spatial output also the variance, minimum and maximum values are stored using the suffixes _var, _min and _max respectively.

All data corresponding to fixed point locations will be stored in files called point< NNN >.dat. < NNN > represents a number between 001 and 999 corresponding to the order in which the points are declared in params.txt. The data files are plain text and contain one row for each output time step. The first position on each row is the time at which the output is given. The subsequent positions in the row are the instantaneous values of the variables at the given point. The order of the variables is equal to the order in which they are defined for that point in params.txt. Data corresponding to run-up gauge locations are stored in the same format as fixed point output, but the files are named rugau< NNN >.dat.

An extra file called dims.dat is always written at the start of the simulation in Fortran binary output mode. This file contains the dimensions of the XBeach model. It simply states the following dimensions in order: nt (number of output time steps), nx (number of grid cells in x-direction), ny (number of grid cells in y-direction), ngd (number of sediment fractions), nd (number of bed layers), ntp (number of point output time steps), ntm (number of time-averaged output time steps). Subsequently, the irregular time series are stored, if applicable: tsglobal (irregular output times), tspoints (irregular point output times) and tsmean (irregular time-averaged output times). Similarly, a file xy.dat is written containing the x- and y- coordinates of the full computational grid.

#### netCDF¶

All data in netCDF output is stored in a single output file. By default this file is named xboutput.nc, but this name can be chosen freely using the keyword ncfilename. The netCDF file holds all output data, dimensions and input data in a single file. It should be noted that netCDF files can hold a multiple time axes. The temporal unit can be specified in the params.txt file using the keyword tunits. This unit does not affect calculations and is only used for output. An example of the layout of the netcdf file is given below:

xboutput.nc (structure only, no real contents)

netcdf xboutput {
dimensions:
x = 565 ;
y = 101 ;
wave_angle = 9 ;
bed_layers = 3 ;
sediment_classes = 1 ;
inout = 2 ;
globaltime = 2 ;
tidetime = 435 ;
tidecorners = 2 ;
windtime = 2 ;
variables:
double x(x) ;
x:units = 'm' ;
x:long_name = 'local x coordinate' ;
double y(y) ;
y:units ='m' ;
y:long_name = 'local y coordinate';
double globaltime(globaltime) ;
globaltime:units = 's' ;
double H(globaltime, y, x) ;
H:units = 'm' ;
H:long_name = 'wave height' ;
double zs(globaltime, y, x) ;
zs:units = 'm' ;
zs:long_name = 'water level' ;
double zb(globaltime, y, x) ;
zb:units = 'm' ;
zb:long_name = 'bed level' ;
double ue(globaltime, y, x) ;
ue:units = 'm/s' ;
}


## Time parameters¶

In all XBeach simulations the hydrodynamic simulation starts at time 0. Model output can be postponed until the time specified by the keyword tstart. The simulation stops at the time specified by tstop. The time step used in the hydrodynamic simulation is determined based on a given maximum Courant number using the keyword CFL. The table below gives an overview of all keywords related to time management:

Table 24 Overview of available keywords related to model time

parameter

description

default

range

units

CFL

Maximum courant-friedrichs-lewy number

0.7

0.1 - 0.9

defuse

Turn on timestep explosion prevention mechanism

1

0 - 1

dtset

Fixed timestep, overrides use of cfl

0.0

0.001 - 100.0

maxdtfac

Maximum increase/decrease in time stp in explosion prevention mechanism

500.0

100.0 - 1000.0

tstop*

Stop time of simulation, in morphological time

2000.0

1.0 - 1000000.0

s

tunits+

Time units in udunits format (seconds since 1970-01-01 00:00:00.00 +1:00)

s

# Appendices¶

## Hands on exercises (based on basic XBeach of the Delft Software Days 2014)¶

The hands-on exercises can be downloaded via subversion. Subversion is a well-known version management system that allows you to always have the most recent source code at hand. It also allows developers to commit changes to the source code, without interfering with other developers. In order to use Subversion, you will need a Subversion client. A well-known client for Windows is Tortoise. If you have registered, you can download the source code via the following URL: https://svn.oss.deltares.nl/repos/xbeach/Courses/DSD2014/. For the tools like Quickplot and Quickin the Delft3D environment is needed.

### Dune erosion at Delfland, Netherlands (1D)¶

The first case we will run is a relative simple 1D case. It concerns a profile along the Dutch coast and the hydraulic boundary conditions are based on the 1953 storm surge that caused substantial flooding in the Netherlands.

You can work on the following assignments:

1. Go to the folder ‘Examples\DelflandStorm’and double click the file ‘run_model.bat’. The simulation will start. The model will run for a few minutes, but in the meantime you can already work on question 2 to 5.

2. Open params.txt in which you specify the model input files and settings. Check the number of grid-points in x-direction (keyword: nx) and y-direction (keyword: ny). Check the filenames in which you specify the wave conditions (keyword: bcfile) and the storm surge level (SSL) (keyword: zs0file).

3. Do the wave conditions change during the simulation? What is/are the wave height(s) and wave period(s) applied in the simulation?

4. Does the storm surge level change during the simulation? What is the maximum surge height in the simulation. Surge height is defined with respect to the mean sea level (MSL)?

5. What is the simulation time (keyword: tstop)? Do we apply a morphological acceleration factor (keyword: morfac)? What variables are stored as output and with what time interval? How much hydrodynamic time is simulated?

6. Probably the simulation has finished. When you start the model, it generates a file named XBlog.txt. Open this file and check what is stored in the file. What was the total simulation time?

7. To check out the simulation results we make use of the Quickplot tool (A brief tutorial is attached to this document). You can start Quickplot via the Delft3D environment we installed (Start Programs Deltares Delft3D Delft3D). In the Delft 3D menu choose Utilities Quickplot. Choose Files of type ‘NetCDF files and GRIB files’ and open ‘xboutput.nc’ in the simulation folder.

8. Use the Quickplot tutorial and try to make an animation in which you plot short wave height (H), water level (including long wave variations, zs) and bed level (zb) as function of time.

9. Plot the offshore water level as function of time. Also open the file ‘tide.tek’ (Tekal data files format), which contains the imposed surge level. Did the model correctly simulate the imposed surge level?

10. Copy all model files to a new folder named ‘superfast’. Edit params.txt and set ny=0 (instead of ny=2), and run the model. What is the simulation time compare to the original simulation?

11. Compare simulation results for the ‘superfast’ and ‘default’ simulation. Are these the same? What option will you use in the future?

### Nourishment scenarios near Kijkduin, Holland (1D)¶

This case concerns the exploration of a nourishment strategy near Kijkduin along the Holland coast in the Netherlands. At this location a mega nourishment of 21 named the Sand Engine was constructed. In this case we will explore to what extent nourishments can reduce the (dune and beach) erosion during a storm event.

You can work on the following assignments:

1. Go to the folder ‘Examples\Nourishment case’ and double click on the file ‘runall.bat’ This batch file will run three simulations sequentially in which the profile configuration varies and corresponds with the undisturbed profile (folder reference), a shoreface nourishment (folder shoreface) and a beach nourishment (folder beach) respectively. Each model will run for a few minutes. While running you can already answer question 2 to 6.

2. For the reference case open the params.txt in which you specify model input files and settings. Check the number of grid-points in x-direction (keyword: nx) and y-direction (keyword: ny). How many directional wave bins are defined and what is their width (keywords: thetamin, thetamax, dtheta).

3. Do the wave conditions change during the simulation? What is/are the wave height(s) and wave period(s) applied in the simulation?

4. Does the storm surge level change during the simulation? What is the maximum surge height in the simulation. Surge height is defined with respect to the mean sea level (MSL)?

5. What is the simulation time (keyword: tstop)? Do we apply a morphological acceleration factor (keyword: morfac)? What variables are stored as output and with what time interval? How much hydrodynamic time is simulated?

6. Probably the simulation has finished. When you start the model, it generates a file named XBlog.txt. Open this file and check what is stored in the file. What was the total simulation time?

7. Inspect the initial bathymetries of each simulation with QUICKPLOT. Choose Files of type ‘NetCDF files and GRIB files’ and open ‘xboutput.nc’ in the simulation folder).

1. At what cross-shore position were the shoreface nourishment and beach nourishment placed?

2. What is the (average) thickness of the nourishments?

3. Is the volume of the nourishments comparable?

4. Plot the reference profile with markers; does the grid resolution vary in cross-shore direction?

8. Use the Quickplot tutorial and try to make an animation in which you plot short wave height (H), water level (including long wave variations, zs) and bed level (zb) as function of time.

9. Plot the offshore water level as function of time. Also open the file ‘tide.tek’ (Tekal data files format), which contains the imposed surge level. Did the model correctly simulate the imposed surge level?

10. Inspect the final bathymetries of each simulation.

1. What is the dune face retreat in the three simulations you have carried out?

2. Where does the eroded sediment form the dunes deposit?

3. What nourishment type is most effective in reducing the impact of a storm and do you have an explanation for this?

11. In the folder ‘banquette’ you find a final simulation in which a special beach nourishment type is evaluated named a banquette. This beach nourishment has a highly elevated flat area that connects to the dune foot on which beach restaurants can be build.

1. Run the model and compare in Quickplot the banquette design with the beach nourishment design we have evaluated before. Do you expect more or less erosion?

2. Check your hypothesis by comparing the final profile of the banquette simulation to the other simulations.

3. What would be your approach to further reduce beach and dune erosion?

### Overwash at Santa Rosa Island , USA (2DH)¶

This case concerns overwash at Santa Rosa island in the Gulf of Mexico during hurricane Ivan in 2004.

You can work on the following assignments.

1. For the reference case open the params.txt in which you specify model input files and settings. Check the number of grid-points in x-direction (keyword: nx) and y-direction (keyword: ny). How many directional wave bins are defined and what is their width (keywords: thetamin, thetamax, dtheta).

2. In this simulation the grid is specified in Delft3D format. Open Quickin in the Delft 3D menu (Grid Quickin) and use the brief tutorial to read in the grid and bathymetry. Does the grid resolution vary in cross-shore direction? And in longshore direction? What are the minimum dx and dy? Why can the grid be coarse offshore?

3. How many wave conditions do we apply in this simulation? What is the offshore mean wave direction? Does the surge level change in the simulation?

4. What is the simulation time (hydrodynamic and morphologic)?

5. Inspect the model results and make an animation of the short wave height (H) and the water levels (including long wave, zs). Describe what is happening.

6. For the water levels set the color limits manual between -0.5 and 3.5.

7. Make an animation of cumulative sedimentation/erosion. Describe what is happening.

8. For the sedimentation/erosion set the color limits manual between -3 and 3

9. Look at the mean flow field. Plot the flow field in colored vectors. Where are the flow velocities highest and what is the direction of the flow (cross-shore or longshore)? Is there (also) a longshore current present and what is its intensity?

If you have time left feel free to:

1. Narrow or broaden the imposed spectrum by changing the parameter directional spreading (s) in’jonswap.inp’ (you could for example set s = 100 and s = 2 respectively). Make animations of the instantaneous short wave height to see what is happening to the size of the wave groups.

2. Design a nourishment in Quickin to reduce the impact of the storm on Santa Rosa Island. Change the depth file in params.txt to make a simulation with the updated bathymetry.

### Yanchep perched beach and natural breakwater (2DH)¶

This case is an example of a beach 60km north of Perth most commonly known as Yanchep lagoon. Many beaches in WA like Yanchep are fronted by shallow reef and here we are investigating the effects of the reef on the morphodynamics.

You can work on the following assignments:

1. Go to the folder’Examples\YanchepBeach’ and double click the file’run_model.bat’. The simulation will start (and will run about 15 minutes).

2. Meanwhile, inspect the bathymetry file and the structure file (using Quickin). What is the depth in the lagoon? Is the reef enclosing the lagoon below or above the model initial water level? What is the wave height at the boundary condition?

3. Use Quickplot and try to make an animation in which you plot short wave height (H), water level (including long wave variations) (zs) and Eulerian velocities (ue and ve) as function of time. What happens in the lagoon?

4. Use Quickplot and try to make an animation of cumulative sedimentation/erosion. What happens in the lagoon?

5. How is the lagoon affected by the mean water level? Increase or decrease the mean water level condition (‘tide.txt’), run the model again (maybe for a shorter time by reducing keyword: tstop). How are the circulation and sediment transport affected?

6. What would happen if the lagoon was open at the southern end? Open the structure file (keyword: ne_layer = reef.dep) with the Quickin tool and modify it to allow the southern end of the lagoon to be eroded. Modify the param.txt file to use this new structure file and run the model. Alternatively, remove the reef from the bathymetry and rerun the model without the structure file, by setting the keyword struct = 0.

If you still have time;

1. Reefs are very rough what happens in the model when the friction is increased? Reduce the Chezy roughness and increase the value of . Rerun the model what do you observe?

2. Is wave/current interaction (keyword: wci = 1) switched on? Rerun the model with the wave/current switch on/off. Compare the output with model you ran previously. How much effect do you see on the morphology?

In General the main input parameters and files required by XBeach to start a simulation are explained. It explained how the user can switch on and off specific processes and how the user can define the model initial and boundary conditions. XBeach offers, however, many more parameters to fine-tune the simulation of different processes. These parameters are listed in the following subsections grouped by process. Most parameters are not relevant for the average XBeach user. Parameters marked with a plus (+) are considered advanced options that are recommended to stay untouched unless you know what you are doing.

### Long and short wave boundary conditions¶

The parameters listed in the table below relate to boundary conditions for short waves (wave action balance model) and long waves (infragravity waves).

Table 25 Overview of available keywords related to wind parameters

parameter

description

default

range

units

nmax+

Maximum ratio of cg/c for computing long wave boundary conditions

0.8

0.5 - 1.0

wbcevarreduce

Reduction factor of short-wave group variance at the boundary

1

0-1

bclwonly

Switch to run boundary conditions with long waves only

0

0 - 1

swkhmin

Minimum kh value to include in wave action balance, lower included in nlswe

-0.01

-0.01 - 0.35

wbcRemoveStokes

Switch to remove long wave Stokes drift component at the offshore boundary

1

0-1

wbcScaleEnergy

Switch to correct random time series of wave height to exactly match input Hm0

0

0-1

Adjust alongshore wave length to fit inside domain with cyclic boundary conditions

0

0-1

### Wave numerics¶

The parameters listed in the table below involve the numerical aspects of the wave action balance that solves the wave propagation in the model. The keyword scheme can be used to set the numerical scheme. To overcome the undesired effects of steepening of wave groups we implemented a correction to the second-order upwind scheme according to ([BW76]), which implies a small additional diffusion term which is a function of time step and group velocity. By default Warming and Beam (1976) is used.

Table 26 Overview of available keywords related to wave numerics parameters

parameter

description

default

range

units

maxerror+

Maximum wave height error in wave stationary iteration

0.0005

1e-05 - 0.001

m

maxiter+

Maximum number of iterations in wave stationary

500

2 - 1000

scheme+

Numerical scheme for wave propagation

warmbeam

upwind_1, lax_wendroff, upwind_2, warmbeam

wavint

Interval between wave module calls (only in stationary wave mode)

60.0

1.0 - 3600.0

s

### Wave dissipation¶

The parameters listed in the table below involve the wave dissipation process. For instationary model runs use either break = roelvink1, roelvink2 or roelvink_daly. Note that the standard value gamma = 0.55 and n = 10 was calibrated for option break = roelvink1. For break = roelvink2 the wave dissipation is proportional to instead of ; this affects the calibration. For stationary runs the break = baldock option is suitable. The break = roelvink_daly option is a model in which waves start and stop breaking. Reducing gammax will reduce wave heights in very shallow water, probably 2 is a reasonable value.

Table 27 Overview of available keywords related to wave breaking parameters

parameter

description

default

range

units

alpha+

Wave dissipation coefficient in roelvink formulation

1.0

0.5 - 2.0

break

Type of breaker formulation

roelvink2

roelvink1, baldock, roelvink2, roelvink_daly, janssen

breakerdelay+

Switch to enable breaker delay model

1.0

0.0 - 3.0

delta+

Fraction of wave height to add to water depth

0.0

0.0 - 1.0

facrun

Calibration coefficient for short wave runup

1.0

0.0 - 2.0

facsd

Fraction of the local wave length to use for shoaling delay depth

1.0

0.0 - 2.0

fwcutoff

Depth greater than which the bed friction factor is not applied

1000.0

0.0 - 1000.0

gamma

Breaker parameter in baldock or roelvink formulation

0.55

0.4 - 0.9

gamma2

End of breaking parameter in roelvink daly formulation

0.3

0.0 - 0.5

gammax+

Maximum ratio wave height to water depth

2.0

0.4 - 5.0

n+

Power in roelvink dissipation model

10.0

5.0 - 20.0

shoaldelay

Switch to enable shoaling delay

0

0 - 1

wavfriccoef

Wave friction coefficient

-123

wavfricfile

Wave friction file

<file>

### Rollers¶

The parameters listed in the table below involve the wave roller model. Using the roller model will give a shoreward shift in wave-induced setup, return flow and alongshore current. This shift becomes greater for lower beta values.

Table 28 Overview of available keywords related to roller parameters

parameter

description

default

range

units

beta+

Breaker slope coefficient in roller model

0.1

0.05 - 0.3

rfb+

Switch to feed back maximum wave surface slope in roller energy balance, otherwise rfb = par%beta

0

0 - 1

roller+

Switch to enable roller model

1

0 - 1

### Wave-current interaction¶

The parameters listed in the table below involve the process of wave-current interaction. With the switch wci one can turn off or on the wave-current interaction, the wave current interaction will result in a feedback of currents on the wave propagation. On top of that, hwci limits the computation of wave-current interaction in very shallow water where the procedure may not converge.

Table 29 Overview of available keywords related to wave-current interaction parameters

parameter

description

default

range

units

cats+

Current averaging time scale for wci, in terms of mean wave periods

4.0

1.0 - 50.0

Trep

hwci+

Minimum depth until which wave-current interaction is used

0.1

0.001 - 1.0

m

hwcimax+

Maximum depth until which wave-current interaction is used

100.0

0.01 - 100.0

m

wci

Turns on wave-current interaction

0

0 - 1

### Bed friction and viscosity¶

The parameters listed in the table below involve the settings for bed friction and viscosity influencing the flow in XBeach. The bed friction is influenced by the dimensionless friction coefficient cf or other formulation like the dimensional ChÃ©zy or Manning. The bed friction formulation applied needs to be determined with the keyword bedfriction. It is possible both to define one value (keyword: bedfriccoef) or to apply, spatially varying values for the bed friction. A spatial varying friction can be provided through an external file referenced via the keyword bedfricfile. The file has the same format as the bathymetry file explained in Grid and bathymetry.

The horizontal viscosity is composed of an overall background viscosity nuh and a viscosity depending on the roller dissipation tuned by nuhfac. In the alongshore direction the viscosity may be multiplied by a factor nuhv to account for additional advective mixing. It is also possible to use a user-defined value for the horizontal viscosity (keyword smag = 0)

Table 30 Overview of available keywords related to flow parameters

parameter

description

default

range

units

bedfriccoef

Bed friction coefficient

0.01

3.5e-05 - 0.9

bedfricfile

Bed friction file (only valid with values of c)

<file>

bedfriction

Bed friction formulation

chezy

chezy, cf, white-colebrook, manning, white-colebrook-grainsize

friction_acceleration

Turn on or off the effect of acceleration on bed roughness (morrison)

none

none, mccall, nielsen

friction_infiltration

Turn on or off the effect of infiltration on bed roughness (conley and inman)

0

0 - 1

friction_turbulence

Turn on or off the effect of turbulence on bed roughness (reniers van thiel)

0

0 - 1

gamma_turb

Calibration factor for turbulence contribution to bed roughness

1.0

0.0 - 2.0

nuh

Horizontal background viscosity

0.1

0.0 - 1.0

m^2s^-1

nuhfac+

Viscosity switch for roller induced turbulent horizontal viscosity

1.0

0.0 - 1.0

nuhv

Longshore viscosity enhancement factor, following svendsen (?)

1.0

1.0 - 20.0

smag+

Switch for smagorinsky subgrid model for viscocity

1

0 - 1

### Flow numerics¶

The parameters listed in the table below involve the numerical aspects of the shallow water equations that solve the water motions in the model. Especially in very shallow water some processes need to be limited to avoid unrealistic behavior. For example hmin prevents very strong return flows or high concentrations and the eps determines whether points are dry or wet and can be taken quite small.

To prevent that the numerical limiter hmin is affected by the scale of the simulation the hmin is defined as

(133)

when oldhmin is 0 (default). This means that hmin is equal to the water depth (h) when the wave height (H) is smaller than the water depth. When the wave height is larger than the water depth, the hmin is equal to the water depth plus an additional contribution related to the wave height times the (deltahmin). if oldhmin is set to 1, the old implementation of hmin is applied, in which the minimum water depth for the retun flow computation is set to the value of hmin.

Table 31 Overview of available keywords related to flow numerics parameters

parameter

description

default

range

units

eps

Threshold water depth above which cells are considered wet

0.005

0.001 - 0.1

m

eps_sd

Threshold velocity difference to determine conservation of energy head versus momentum

0.5

0.0 - 1.0

m/s

hmin

Threshold water depth above which stokes drift is included

0.2

0.001 - 1.0

m

oldhu

Switch to enable old hu calculation

0

0 - 1

secorder+

Use second order corrections to advection/non-linear terms based on maccormack scheme

0

0 - 1

umin

Threshold velocity for upwind velocity detection and for vmag2 in equilibrium sediment concentration

0.0

0.0 - 0.2

m/s

deltahmin

Dimensionless coefficent to determine the threshold water depth above which stokes drift is included

0.1

0.0 - 1.0

oldhmin

Switch to apply the old hmin parameter instead of the deltahmin

0

0 - 1

### Sediment transport¶

The parameters listed in the table below involve the process of sediment transport. The keywords facAs and facSk determine the effect of the wave form on the sediment transport, this is especially important in the nearshore. The facua is an alias setting in which both parameters can be varied at once. The wave form model itself is selected using the keyword waveform. Processes like short- and long-wave stirring and turbulence can be switched on or off using the keywords sws, lws and lwt. Several options for calibrating the sediment transport formulations are available as well as keywords to incorporate the bed slope effect.

Table 32 Overview of available keywords related to sediment transport parameters

parameter

description

default

range

units

BRfac+

Calibration factor surface slope

1.0

0.0 - 1.0

Tbfac+

Calibration factor for bore interval tbore: tbore = tbfac*tbore

1.0

0.0 - 1.0

Tsmin+

0.5

0.01 - 10.0

s

bdslpeffdir

Modify the direction of the sediment transport based on the bed slope

none

none, talmon

bdslpeffdirfac

Calibration factor in the modification of the direction

1.0

0.0 - 2.0

bdslpeffini

Modify the critical shields parameter based on the bed slope

none

none, total, bed

bdslpeffmag

Modify the magnitude of the sediment transport based on the bed slope, uses facsl

roelvink_total

none, roelvink_total, roelvink_bed, soulsby_total, soulsby_bed

bed+

Calibration factor for bed transports

1

0 - 1

bermslope

Swash zone slope for (semi-) reflective beaches

0.0

0.0 - 1.0

Dissipation parameter long wave breaking turbulence

1.0

0.0 - 10.0

bulk+

Switch to compute bulk transport rather than bed and suspended load separately

0

0 - 1

ci+

Mass coefficient in shields inertia term

1.0

0.5 - 1.5

cm

Mass coefficient in shields inertia term

1.5

0.0 - 3.0

dilatancy

Switch to reduce critical shields number due dilatancy

0

0 - 1

facAs+

Calibration factor time averaged flows due to wave asymmetry

0.1

0.0 - 1.0

facDc+

Option to control sediment diffusion coefficient

1.0

0.0 - 1.0

facSk+

Calibration factor time averaged flows due to wave skewness

0.1

0.0 - 1.0

facsl+

Factor bedslope effect

1.6

0.0 - 1.6

facua+

Calibration factor time averaged flows due to wave skewness and asymmetry

0.1

0.0 - 1.0

fallvelred

Switch to reduce fall velocity for high concentrations

0

0 - 1

form

Equilibrium sediment concentration formulation

vanthiel_vanrijn

soulsby_vanrijn, vanthiel_vanrijn, vanrijn1993

jetfac

Option to mimic turbulence production near revetments

0.0

0.0 - 1.0

lws+

Switch to enable long wave stirring

1

0 - 1

lwt+

Switch to enable long wave turbulence

0

0 - 1

phit+

Phase lag angle in nielsen transport equation

25.0

0.0 - 90.0

pormax

Max porosity used in the experession of van rhee

0.5

0.3 - 0.6

reposeangle

Angle of internal friction

30.0

0.0 - 45.0

deg

rheeA

A parameter in the van rhee expression

0.75

0.75 - 2.0

smax+

Maximum shields parameter for equilibrium sediment concentration acc. diane foster

-1.0

-1.0 - 3.0

sus+

Calibration factor for suspensions transports

1

0 - 1

sws+

Switch to enable short wave and roller stirring and undertow

1

0 - 1

tsfac+

Coefficient determining ts = tsfac * h/ws in sediment source term

0.1

0.01 - 1.0

turb+

Switch to include short wave turbulence

wave_averaged

none, wave_averaged, bore_averaged

Switch to activate turbulence advection model for short and or long wave turbulence

none

none, lagrangian, eulerian

waveform

Wave shape model

vanthiel

ruessink_vanrijn, vanthiel

z0+

Zero flow velocity level in soulsby and van rijn (1997) sediment concentration

0.006

0.0001 - 0.05

m

### Sediment transport numerics¶

The parameters listed in the table below involve the numerical aspects of sediment transport that are all considered advanced options. For example the maximum allowed sediment concentration can be varied with the keyword cmax. It is however not recommended varying these settings.

Table 33 Overview of available keywords related to sediment transport numerics parameters

parameter

description

default

range

units

cmax+

Maximum allowed sediment concentration

0.1

0.0 - 1.0

sourcesink+

Switch to enable source-sink terms to calculate bed level change rather than suspended transport gradients

0

0 - 1

thetanum+

Coefficient determining whether upwind (1) or central scheme (0.5) is used.

1.0

0.5 - 1.0

dtlimts+

Factor of the timestep to determine the numerical limiter of the adaptation time.

1.0

0 - 20.0

oldTsmin+

Switch to apply the tsmin parameter instead of the dtlimts..

0

0 - 1

### Quasi-3D sediment transport¶

The parameters listed in the table below involve the tuning of quasi-3D sediment transport, if enabled. The most important setting is the kmax in which the user specifies the number of layers used in the quasi 3D sediment model.

Table 34 Overview of available keywords related to q3d sediment transport parameters

parameter

description

default

range

units

deltar

Estimated ripple height

0.025

0.001 - 1.0

kmax

Number of sigma layers in quasi-3d model; kmax = 1 is without vertical structure of flow and suspensions

100

1 - 1000

rwave

2.0

0.1 - 10.0

sigfac

Dsig scales with log(sigfac)

1.3

0.0 - 10.0

vicmol

Molecular viscosity

1e-06

0.0 - 0.001

vonkar

Von karman constant

0.4

0.01 - 1.0

### Morphology¶

The parameters listed in the table below involve the morphological processes. The dryslp and wetslp keyword define the critical avalanching slope above and below water respectively. If the bed exceeds the relevant critical slope it collapses and slides downward (avalanching). To reduce the impact of these landslides the maximum bed level change due to avalanching is limited by the nTrepAvaltime parameter.

The keyword morfac enables the user to decouple the hydrodynamical and the morphological time. This is suitable for situations where the morphological process is much slower than the hydrodynamic process. The factor defined by the morfac keyword is applied to all morphological change. A morfac = 10 therefore results in 10 times more erosion and deposition in a given time step than usual. The simulation time is however then shortened with the same factor to obtain an approximate result more quickly. The user can prevent the simulation time to be adapted to the morfac value by setting morfacopt to zero. The keywords morstart and morstop let the user enable the morphological processes in XBeach only for a particular period during the (hydrodynamic) simulation. These options can be useful if a spin-up time is needed for the hydrodynamics.

The struct and ne_layer keywords enable the user to specify non-erodible structures in the model. To switch on non-erodible structures use struct = 1. The location of the structures is specified in an external file referenced by the ne_layer keyword. The file has the same format as the bathymetry file explained in Grid and bathymetry. The values of the file define the thickness of the erodible layer on top of the non-erodible layer. A ne_layer file with only zeros therefore defines a fully non-erodible bathymetry and a file with only tens means a erodible layer of 10 meters. Only at the grid cells where the value in the ne_layer file is larger than zero erosion can occur. Non-erodible layers are infinitely deep and thus no erosion underneath these layers can occur.

Table 35 Overview of available keywords related to morphology parameters

parameter

description

default

range

units

dryslp

Critical avalanching slope above water (dz/dx and dz/dy)

1.0

0.1 - 2.0

dzmax+

Maximum bed level change due to avalanching

0.05

0.0 - 1.0

m/s/m

hswitch+

Water depth at which is switched from wetslp to dryslp

0.1

0.01 - 1.0

m

0.0

-0.1 - 0.1

1/m

morfac

Morphological acceleration factor

1.0

0.0 - 1000.0

morfacopt+

Switch to adjusting output times for morfac

1

0 - 1

morstart

Start time morphology, in morphological time

0.0

0.0 - par%tstop

s

morstop

Stop time morphology, in morphological time

2000.0

0.0 - 10000000.0

s

ne_layer

Name of file containing thickness of the erodible layer

<file>

struct

Switch for enabling hard structures

0

0 - 1

wetslp

Critical avalanching slope under water (dz/dx and dz/dy)

0.3

0.1 - 1.0

### Bed update¶

The parameters listed in the table below involve the settings for the bed update process especially in the case multiple sediment fractions and bed layers are involved. The frac_dz, split and merge keywords determine the fraction of the variable bed layer thickness at which the layer is split or merged respectively with the surrounding bottom layers. The variable layer is chosen using the nd_var keyword.

Pre-defined bed evolution can be used with the keywords setbathy that is used to turn user-imposed bed level change on, nsetbathy that determines the number of imposed bed level conditions and setbathyfile that references a file that specifies the time series of imposed bed levels. If the setbathy option is used, XBeach will automatically interpolate the bed level at each computational time step from the imposed bed level time series.

The setbathyfile file must contain a time series (of length nsetbathy) of the bed level at every grid point in the XBeach model. The format of the setbathyfile file is such that each imposed bed level starts with the time at which the bed level should be applied (in seconds relative to the start of the simulation), followed on a new line by the bed level in each grid cell in an identical manner to the normal initial bathymetry file (e.g., one line per transect in the x-direction). The following imposed bed level condition starts on a new line with the time at which the condition is imposed and the bed levels at that time, etc. An example of a setbathyfile is given below.

setbathyfile.dep (generalized)

<t 0>
<z 1,1> <z 2,1> <z 3,1> ... <z nx,1> <z nx+1,1>
<z 1,2> <z 2,2> <z 3,2> ... <z nx,2> <z nx+1,2>
<z 1,3> <z 2,3> <z 3,3> ... <z nx,3> <z nx+1,3>

...

<z 1,ny> <z 2,ny> <z 3,ny> ... <z nx,ny> <z nx+1,ny>
<z 1,ny+1> <z 2,ny+1> <z 3,ny+1> ... <z nx,ny+1> <z nx+1,ny+1>
<t 1>
<z 1,1> <z 2,1> <z 3,1> ... <z nx,1> <z nx+1,1>
<z 1,2> <z 2,2> <z 3,2> ... <z nx,2> <z nx+1,2>
<z 1,3> <z 2,3> <z 3,3> ... <z nx,3> <z nx+1,3>

...

<z 1,ny> <z 2,ny> <z 3,ny> ... <z nx,ny> <z nx+1,ny>
<z 1,ny+1> <z 2,ny+1> <z 3,ny+1> ... <z nx,ny+1> <z nx+1,ny+1>

...

...

<t nsetbathy>
<z 1,1> <z 2,1> <z 3,1> ... <z nx,1> <z nx+1,1>
<z 1,2> <z 2,2> <z 3,2> ... <z nx,2> <z nx+1,2>
<z 1,3> <z 2,3> <z 3,3> ... <z nx,3> <z nx+1,3>

...

<z 1,ny> <z 2,ny> <z 3,ny> ... <z nx,ny> <z nx+1,ny>
<z 1,ny+1> <z 2,ny+1> <z 3,ny+1> ... <z nx,ny+1> <z nx+1,ny+1>


setbathyfile.dep (short 1D example, nx = 20, ny = 0, nsetbathy = 4)

0    -20 -18 -16 -14 -12 -10 -8 -6 -5 -4 -3   -2   -1    -0.5  0    0.5 1   2   3   4   5
1200 -20 -18 -16 -14 -12 -10 -8 -6 -5 -4 -3   -1.8 -0.75 -0.25 0    0.2 0.7 2   3   4   5
2400 -20 -18 -16 -14 -12 -10 -8 -6 -5 -4 -2.5 -1.6 -0.5  -0.3  0    0.1 0.6 1.5 3   4   5
3600 -20 -18 -16 -14 -12 -10 -8 -6 -5 -4 -2   -1.4 -0.3   0    0.05 0.1 0.6 1   2.2 3.5 5


Note that if the setbathy option is used, the initial bed level is derived from an interpolation of the setbathyfile file time series, not from the depfile file. It is strongly advised to turn of the computation of morphological updating (keyword: morphology = 0) if the setbathy option is used, as the computed morphological change will be overridden by the imposed morphological change.

Table 36 Overview of available keywords related to bed update numerics parameters

parameter

description

default

range

units

frac_dz+

Relative thickness to split time step for bed updating

0.7

0.5 - 0.98

merge+

Merge threshold for variable sediment layer (ratio to nominal thickness)

0.01

0.005 - 0.1

nd_var+

Index of layer with variable thickness

2

1 - par%nd

nsetbathy+

1

1 - 1000

setbathyfile+*

Name of prescribed bed update file

<file>

split+

Split threshold for variable sediment layer (ratio to nominal thickness)

1.01

1.005 - 1.1

### Groundwater flow¶

The parameters listed in the table below involve the process of groundwater flow. The vertical permeability coefficient in the vertical can be set differently than that of the horizontal using the keywords kz and kz respectively. The initial bed level of the aquifer is read from an external file referenced by the aquiferbotfile keyword and the initial groundwater head can be set to either a uniform value using the gw0 keyword or to spatially varying values using an external file referenced by the gw0file keyword. Both files have the same format as the bathymetry file explained in Grid and bathymetry.

Table 37 Overview of available keywords related to groundwater parameters

parameter

description

default

range

units

aquiferbot+

Level of uniform aquifer bottom

-10.0

-100.0 - 100.0

m

aquiferbotfile+

Name of the aquifer bottom file

<file>

dwetlayer+

Thickness of the top soil layer interacting more freely with the surface water

0.1

0.01 - 1.0

m

gw0+

Level initial groundwater level

0.0

-5.0 - 5.0

m

gw0file+

Name of initial groundwater level file

<file>

gwReturb+

Reynolds number for start of turbulent flow in case of gwscheme = turbulent

100.0

1.0 - 600.0

gwfastsolve

Reduce full 2d non-hydrostatic solution to quasi-explicit in longshore direction

0

0 - 1

Model to use for vertical groundwater head

parabolic

parabolic, exponential

gwhorinfil+

Switch to include horizontal infiltration from surface water to groundwater

0

0 - 1

gwnonh+

Switch to turn on or off non-hydrostatic pressure for groundwater

0

0 - 1

gwscheme+

Scheme for momentum equation

laminar

laminar, turbulent

kx+

Darcy-flow permeability coefficient in x-direction

0.0001

1e-05 - 0.1

ms^-1

ky+

Darcy-flow permeability coefficient in y-direction

0.0001

1e-05 - 0.1

ms^-1

kz+

Darcy-flow permeability coefficient in z-direction

0.0001

1e-05 - 0.1

ms^-1

### Non-hydrostatic correction¶

The parameters listed in the table below involve the settings for the non-hydrostatic option (keyword: wavemodel = nonh). These are all considered advanced options and it is thus recommended not to change these

Table 38 Overview of available keywords related to non-hydrostatic correction parameters

parameter

description

default

range

units

Topt+

Absolute period to optimize coefficient

10.0

1.0 - 20.0

s

breakviscfac+

Factor to increase viscosity during breaking

1.5

1.0 - 3.0

breakvisclen+

Ratio between local depth and length scale in extra breaking viscosity

1.0

0.75 - 3.0

dispc+

Coefficient in front of the vertical pressure gradient

-1.0

0.1 - 2.0

?

kdmin+

Minimum value of kd (pi/dx > min(kd))

0.0

0.0 - 0.05

maxbrsteep+

Maximum wave steepness criterium

0.4

0.3 - 0.8

nhbreaker+

Non-hydrostatic breaker model

2

0 - 2

nhlay+

Layer distribution in the nonhydrostatic model, default = 0.33

0.33

0.0 - 1.0

nonhq3d

Turn on or off the the reduced two-layer nonhydrostatic model, default = 0

0

0 - 1

reformsteep+

Wave steepness criterium to reform after breaking

0.25d0*par%maxbrsteep

0.0 - 0.95d0*par%maxbrsteep

secbrsteep+

Secondary maximum wave steepness criterium

0.5d0*par%maxbrsteep

0.0 - 0.95d0*par%maxbrsteep

solver+

Solver used to solve the linear system

tridiag

sip, tridiag

solver_acc+

Accuracy with respect to the right-hand side usedin the following termination criterion: ||b-ax || < acc*||b||

0.005

1e-05 - 0.1

solver_maxit+

Maximum number of iterations in the linear sip solver

30

1 - 1000

solver_urelax+

Underrelaxation parameter

0.92

0.5 - 0.99

### Physical constants¶

The parameters listed in the table below involve physical constants used by XBeach. The gravitational acceleration and density of water are universally used coefficient. The depthscale is a factor in order to set different cut-off values like eps and hswitch. A value of the depthscale lower than one means the cut-off values will increase.

Table 39 Overview of available keywords related to physical constants

parameter

description

default

range

units

depthscale+

Depthscale of (lab)test simulated, affects eps, hmin, hswitch and dzmax

1.0

1.0 - 200.0

g

Gravitational acceleration

9.81

9.7 - 9.9

ms^-2

rho

Density of water

1025.0

1000.0 - 1040.0

kgm^-3

### Coriolis force¶

The parameters listed in the table below involve the settings for incorporating the effect of Coriolis on the shallow water equations. The keywords are universally used coefficients.

Table 40 Overview of available keywords related to coriolis force parameters

parameter

description

default

range

units

lat+

Latitude at model location for computing coriolis

0.0

-90.0 - 90.0

deg

wearth+

Angular velocity of earth calculated as: 1/rotation_time (in hours)

1.d0/24.d0

0.0 - 1.0

hour^-1

### MPI¶

The parameters listed in the table below involve the settings for parallelization of XBeach. When running XBeach in parallel mode, the model domain is subdivided in sub models and each sub model is then computed on a separate core. This will increase the computational speed of the model. The sub models only exchange information over their boundaries when necessary. The MPI parameters determine how the model domain is subdivided. The keyword mpiboundary can be set to auto, x, y or man. In auto mode the model domain is subdivided such that the internal boundary is smallest. In x or y mode the model domain is subdivided in sub models extending to either the full alongshore or the full cross-shore extent of the model domain. In man mode the model domain is manually subdivided using the values specified with the mmpi and nmpi keywords. The number of sub models is not determined by XBeach itself, but by the MPI wrapper (e.g. MPICH2 or OpenMPI).

Table 41 Overview of available keywords related to mpi parameters

parameter

description

default

range

units

mmpi+

Number of domains in cross-shore direction when manually specifying mpi domains

2

1 - 100

mpiboundary+

Fix mpi boundaries along y-lines, x-lines, use manual defined domains or find shortest boundary automatically

auto

auto, x, y, man

nmpi+

Number of domains in alongshore direction when manually specifying mpi domains

4

1 - 100

### Output projection¶

The parameters listed in the table below involve the projection of the model output. These settings do not influence the model results in anyway. The rotate keyword can be used to rotate the model output with an angle specified by the keyword alfa. The projection string can hold a string specifying the coordinate reference system used and is stored in the netCDF output file as metadata.

Table 42 Overview of available keywords related to output projection

parameter

description

default

range

units

projection+

Projection string

remdryoutput

Remove dry output points from output data of zs etc.

1

0 - 1

rotate

Rotate output as postprocessing with given angle

1

0 - 1

## Numerical implementation¶

### Grid set-up¶

The new implementation utilizes a curvilinear, staggered grid where depths, water levels, wave action and sediment concentrations are given in the cell centers (denoted by subscript z) and velocities and sediment fluxes at the cell interfaces (denoted by subscript u or v). In Fig. 13 the z, u, v and c (corner) points with the same numbering are shown. The grid directions are named s and n; grid distances are denoted by and , with subscripts referring to the point where they are defined. A finite-volume approach is utilized where mass, momentum and wave action are strictly conserved. In the middle panel of Fig. 13, the control volume for the mass balance is shown with the corresponding grid distances around the u- and v-points. The right panel explains the numbering of the fluxes Q and the volume V.

Fig. 13 Location of staggered grid points (left panel); definition of grid distances (middle) and terms in volume balance (right)

### Wave action balance¶

#### Surfbeat solver¶

The time-varying wave action balance solved in XBeach is as follows:

(134)

Where is the wave energy or wave action, is the group velocity, the refraction speed in theta-space and refers to effects of wave breaking and bottom friction.

Again, the advection terms are the only ones affected by the curvilinear scheme so we will discuss their treatment in detail. The control volume is the same as for the mass balance. In equation (135) the procedure to compute the wave energy fluxes across the cell boundaries is outlined. All variables should also have an index referring to the directional grid, but for brevity these are omitted here.

The component of the group velocity normal to the cell boundary, at the cell boundary, is interpolated from the two adjacent cell center points. Depending on the direction of this component, the wave energy at the cell boundary is computed using linear extrapolation based on the two upwind points, taking into account their grid distances. This second order upwind discretization preserves the propagation of wave groups with little numerical diffusion.

(135)

The other three fluxes are computed in a similar way; for brevity we will not present all formulations.

The time integration is explicit and the same as in the original implementation. The advection in u- and v-direction is computed simply by adding the four fluxes and dividing by the cell area. This procedure guarantees conservation of wave energy.

The procedure for the roller energy balance is identical to that for the wave energy balance and will not be repeated here.

#### Stationary solver¶

In the stationary solver the wave energy and roller energy balances are solved line by line, from the seaward boundary landward. For each line the automatic timestep is computed and the quasi-time-dependent balance is solved until convergence or the maximum number of iterations is reached, after which the solver moves to the next line.

The iteration is controlled by the parameters maxiter and maxerror.

### Shallow water equations¶

#### Mass balance equation¶

The mass balance reads as follows:

(136)

This is discretized according to:

(137)

Here, is the area of the cell around the cell centre, is the surface elevation, is the u-velocity in the u-point, the water depth in the u-point and the v-velocity in the v-point. The indices refer to the grid number in u resp. v direction; the index refers to the time step.

#### Momentum balance equation¶

Second, we will outline the derivation of the u-momentum balance. The control volume is given in Fig. 14. It is centeredaround the u-point. We now consider the rate of change of the momentum in the local u-direction as follows:

(138)

where V is the cell volume, u the velocity in local grid direction, Q the fluxes, the density, g acceleration of gravity, the bed shear stress, wind shear stress and wave force in u-direction. We consider that the outgoing fluxes carry the velocity inside the cell, , and that is determined at each inflow boundary by interpolation, reconstructing the component in the same direction as .

The volume balance for the same volume reads:

(139)

By multiplying the volume balance by , subtracting it from the momentum balance and dividing the result by we arrive at the following equation:

(140)

where is the cell area and is the average depth of the cell around the u-point. The procedure for the second term (the others are straightforward) now boils down to integrating (only) the incoming fluxes over the interfaces and multiplying them with the difference between in the cell and the component of velocity in the same direction at the upwind cell.

Fig. 14 Control volume u-momentum balance and definition of fluxes

In the following three quations the procedure for computing the u-momentum balance is outlined. The discharges in the u-points are computed by multiplying the velocity in the u- or v-point by the water depth at that point. These discharges are then interpolated to the borders of the control volume around the u-point. The difference in grid orientation between the incoming cell and the u-point is computed and used to compute the component of the incoming velocity in the local u-direction, from the left and right side of the control volume.

(141)

The same is done for the top and bottom of the control volume, based on the discharges in v-direction:

(142)

Finally, the advective term in the momentum balance is given as:

(143)

#### Time integration scheme¶

The time integration of the mass and momentum balance equations is combined in an explicit leap-frog scheme, as depicted in Fig. 15. The velocities are updated using the momentum balance, the water levels are updated using the mass balance. The water level gradients influence the momentum balance and the velocities and derived discharges affect the mass balance. Because of the leap-frog scheme these influences are always computed at the half time step level, which makes the scheme second order accurate.

Fig. 15 Leap-frog time integration scheme

Using this straightforward finite volume approach, complicated transformations of the equations are avoided and the solution scheme remains transparent. It is also completely compatible with the original rectilinear implementation and is even slightly more efficient.

### Groundwater flow¶

In order to solve the equations in xx, the spatial and temporal domain of the groundwater system is split into the same spatial grid and time steps as the XBeach surface water model it is coupled to. At each time step in the numerical model, the depth average groundwater head is calculated in the center of the groundwater cells, and the fluxes (specific discharge, submarine exchange, infiltration and exfiltration) are calculated on the cell interfaces

At the start of the time step, every cell is evaluated whether the groundwater and surface water are connected:

(144)

In equation (144) is a numerical smoothing constant used to deal with numerical round off errors near the bed (equal to the parameter dwetlayer in the case of hydrostatic groundwater flow, and to the parameter eps in the case of non-hydrostatic groundwater flow), and and represent cross-shore and longshore coordinates in the numerical solution grid, respectively. Infiltration is calculated in cells where the groundwater and surface water are not connected and there exists surface water. As shown in equation (81) the infiltration rate is a function of the thickness of the wetting front, which is zero at the start of infiltration, and increases as a function of the infiltration rate. The equations for the infiltration rate and the thickness of the wetting front are approximated by first-order schemes, in which the wetting front is updated using a backward-Euler scheme, which ensures numerical stability:

(145)

In the pressure term is the surface water pressure at the bed, which in the case of non-hydrostatic surface water flow is high-pass filtered at , the superscript corresponds to the time step number and is the size of the time step. The infiltration rate in the coupled relationship can be solved through substitution:

(146)

At the end of infiltration, i.e. when the groundwater and surface water become connected or there is no surface water left, the wetting front thickness is reset to zero. If the infiltration rate exceeds the Reynolds number for the start of turbulence, the local hydraulic conductivity is updated using the local Reynolds number:

(147)

XBeach iterates until a minimum threshold difference between iterations is found for and . Infiltration in one time step is limited to the amount of surface water available in the cell and to the amount of water required to raise the groundwater level to the level of the bed:

(148)

If during infiltration the groundwater level reaches the bed level, the fraction of the time step required to do so is estimated (x) and the remaining fraction is used in the submarine exchange.

(149)

Exfiltration is calculated in cells where the groundwater and surface water are not connected and the groundwater level exceeds the bed level:

(150)

Horizontal infiltration and exfiltration (keyword: gwhorinfil = 1) is computed across the numerical vertical interface between the groundwater domain and the surface water domain in adjoining cells. The direction of exchange is determined by the head gradient, and the bed level slope direction:

(151)

After infiltration and exfiltration have been calculated, the groundwater level and surface water level are updated:

(152)

All updated cells are subsequently re-evaluated on whether the surface water and groundwater are connected or unconnected

The cell height at the center of the groundwater cells () is calculated from the groundwater level and the bottom of the aquifer in the center of the cell, whereas the cell heights at the horizontal cell interfaces are calculated using an upwind procedure:

(153)

In is the level of the bottom of the aquifer. As described in Sediment transport, the head applied on the top boundary of the groundwater domain () depends on whether the groundwater and surface water are connected or unconnected:

(154)

In the parameter is the relative numerical ‘connectedness’ of the groundwater and surface water head, determined by linear interpolation across the numerical smoothing constant .

In the case of hydrostatic groundwater flow, the groundwater head in each cell is set equal to the head applied on the top boundary of the groundwater domain () and the horizontal groundwater flux is computed from the groundwater head gradient:

(155)

In the superscripts and refer to the components of the variable in the cross-shore and longshore direction, respectively, and the subscripts and refer to variables approximated at the horizontal cell interfaces in the cross-shore and longshore direction, respectively.

In the case of non-hydrostatic groundwater flow, the horizontal specific discharge on each cell interface can be found through an approximation of the non-hydrostatic groundwater head gradient:

(156)

In the subscript refers to variables approximated at the cell centers. The hydraulic conductivity may be different at each cell interface and is therefore computed at every interface where every K is calculated separately.

Continuity in the groundwater cell is found following:

(157)

In the variable refers to the vertical groundwater discharge (e.g., submarine exchange if connected to the surface water, or groundwater level fluctuations if the groundwater is not connected to the surface water).

In the case of hydrostatic groundwater flow, the variable can be solved through the known variables and . However, in the case of non-hydrostatic groundwater flow, all variables in contain an unknown value for the groundwater pressure head, described in terms of a known head at the surface of the groundwater () and the unknown curvature of the vertical groundwater head function (). Since water is incompressible, the groundwater pressure must be solved for all cells simultaneously using matrix algebra:

(158)

In A is a matrix containing coefficients for the horizontal and vertical specific discharge, x is a vector containing the unknown groundwater head curvature, and b contains the known forcing terms. For a one dimensional cross-shore case, A is reduced to a tridiagonal matrix. The vector of known forcing consists of the numerical gradients in the contribution of the head applied on the top boundary of the groundwater domain to the horizontal specific discharge.

In the one dimensional case, the solution to the tridiagonal matrix A can be computed using the efficient Thomas algorithm ([Tho49]). In the two dimensional case, matrix A contains two additional diagonals that are not placed along the main diagonal, and vector b contains additional forcing terms from the alongshore contribution. The solution to the two dimensional case requires a more complex and less computationally efficient matrix solver. In this case the Strongly Implicit Procedure ([Sto68]) is used in a manner similar to [ZSS11]. The horizontal and vertical groundwater fluxes are calculated using the solution of x plus and .

Since in both hydrostatic and non-hydrostatic groundwater flow some local velocities may exceed the critical Reynolds number for the start of turbulence (), the turbulent hydraulic conductivity () is updated using the local Reynolds number. The solution to and the update of the turbulent hydraulic conductivity are iterated until a minimum threshold difference between iterations is found. Note that this approach is only used is the turbulent groundwater model is selected (keyword: gwscheme = turbulent).

The (iterated) solution for the specific vertical discharge is used to update the groundwater level and surface water level:

(159)

If the groundwater and surface water are connected, and the submarine exchange from the surface water to the groundwater estimated in is greater than the amount of surface water available in the cell, continuity is enforced by lowering the groundwater level to compensate for the lack of permeating water:

(160)

### Sediment transport¶

The advection-diffusion equation for suspended sediment is the basis for the sediment transport computations in XBeach. The partial differential equation to solve is:

(161)

Here is the depth-averaged concentration, the equilibrium concentration, a typical timescale proportional to water depth divided by fall velocity. As is often done to increase robustness, we treat the erosion term explicitly but take an implicit scheme for the sedimentation term:

(162)

This can be rewritten as:

(163)

The sediment transport gradient is discretized in a similar way as the mass balance:

(164)

The sediment transports in the u- points contain an advective term, a diffusive term and a bed slope term:

(165)

Here is a representative velocity for suspended transport, which contains contributions due to return flow, wave skewness and wave asymmetry; is a horizontal diffusion coefficient and a coefficient. In discretized form the expression for the suspended transport in the u-point is:

(166)

The concentrations in the u-points are computed with a -method, where means a fully upwind approximation, and a central scheme. In practice, we mostly use the upwind approximation for its robustness.

(167)

The erosion and deposition terms, which may also be used in the bed updating, are finally computed from:

(168)

The evaluation of the bedload transport takes place in the same way as in the previous versions of XBeach, except for the fact that the directions are taken in local grid direction, and will not be repeated here.

### Bottom updating schemes¶

Two alternative formulations are available for the bed updating: one where the bottom changes are computed based on the gradients of suspended and bed load transport, equation (169) , and one where the changes due to suspended transport are accounted for through the erosion and deposition terms, equation (170).

(169)

(170)

In both cases is the morphological factor used to accelerate morphological changes. In the first case, the sediment in the bottom is conserved in all cases, but changes in the amount of sediment in the water are not considered; one can also say that the sediment in suspension is added to the bottom sediment. In the second case, the storage of sediment in the water is accounted for, but will be distorted in cases of high . Since under most circumstances the real effect of the storage in the water phase is small we prefer the first formulation which guarantees mass conservation in the bottom. Both formulations are calculated using an explicit scheme:

(171)

(172)

#### Avalanching¶

XBeach implements avalanching as described in section Avalanching. It first calculates bed level change due to avalanching in the cross-shore dimension. It then calculates the slopes in alongshore direction and bottom change due to avalanching in this direction. To avoid disrupted sediment balance XBeach does not calculate bottom change due to avalanching at the boundary grid cells. Consequently XBeach cannot calculate avalanching at the boundary between two MPI domains.

#### Bed composition¶

The bed is discretized into layers with mass in which refers to the layer number and to the sediment class. The mass fraction per sediment class , layer thickness and bed level are defined by:

(173)

with porosity and sediment density . The level is the lowest point of the array of bed layers.

Due to bed load transport, sediment is exchanged between the top layer and the four horizontally neighboring top layers. Exchange with the water column and the top layer is due to erosion rate and deposition rate . A mixed Eulerian/Lagrangian framework is proposed. Within the set of layers, one layer is defined as the variable layer. This is the only layer that has a variable total mass. All other layers have a constant total mass, which implies for a constant porosity a constant thickness. Above the variable layer, the layers move with the bed level (Lagrangian): upwards in case of aggradation and downwards in case of degradation. This vertical movement gives an advective flux with advection velocity equal to the bed level change . The variable layer is the transition to the lower layers, which are passive. The number of layers below the variable layer has thus no influence on the computation time. Note that diffusive processes within the bed are not considered yet. These could lead to fluxes between the layers below the variable layer.

The mass balance for the top layer can now be defined by:

(174)

in which is the bed-load transport (e.g. Meyer-Peter-Muller), based on the sediment properties of the specific class. The dimensions of the grid cell are defined by and . The subscripts W, E, S and N refer to West, East, South and North indicating the four vertical faces of the bed cell. The horizontal faces are indicated with bot for the bottom of the cell and ceil for the ceiling of the cell. As the fraction p is not defined at the faces but in the cell centers, the upstream fraction is required. For the bed load fluxes, the velocity direction used. For the vertical advection term, the upstream value is based on the bed level variation: in case of aggradation the value in the top layer is used and in case of degradation the value of the second layer is used. If the top layer is the variable layer, there is no advective flux: otherwise .

The mass balance for the layers in between the top layer and the variable layer is:

(175)

and for the variable layer, it reads:

(176)

In order to avoid too thin a or too thick a variable layer, the variable layer is merged or split. If the thickness is smaller than the critical value , the variable layer is merged with the lower layer. To keep the same number of cells, a cell is added at the bottom of the array, implying that . Similarly, the variable is split into two layers if the critical value is exceeded. Then, the array is shifted upwards: .

As the bed level update is explicit, the timestep is limited. A conservative estimate can be made by assuming that no more mass can be eroded than available in the top layer:

(177)

The transport rate depends on the direction of the transport. The transport rates and erosion rates should be based on the formulation for the smallest fraction: . Note that the fraction p falls out. This time step restriction is less severe than the one for shallow water flow. Only in case of very top layers and/or the use of a morphological factor, this time step restriction might be relevant.

### Boundary conditions¶

At the start of the XBeach simulation, XBeach checks whether non-stationary varying wave boundary conditions are to be used. If this is the case, it next checks whether the wave spectrum of the wave boundary conditions is to change over time, or remain constant. If the wave spectrum is to remain constant, XBeach will only read from one input file to generate wave boundary conditions. If the wave spectrum is to vary in time, XBeach reads from multiple files.

Whether or not the wave spectrum of the boundary conditions changes over time, the XBeach module requires a record length during which the current wave spectral parameters are applied. For the duration of the record length, boundary conditions are calculated at every boundary condition file time step. These time steps are not required to be the same as the time steps in the XBeach main program; XBeach will interpolate where necessary. The boundary condition time steps should therefore only be small enough to accurately describe the incoming bound long waves. The statistical data for the generation of the wave boundary conditions is read from user-specified files. The XBeach module tapers the beginning and end of the boundary condition file. This is done to ensure smooth transitions from one boundary condition file to the next.

The combination of a large record length and a small time step lead to large demands on the system memory. If the memory requirement is too large XBeach will shut down. The user must choose to either enlarge the boundary condition time step, or to reduce the record length. In case of the latter, several boundary condition files can be generated and read sequentially. It is unwise however to reduce the record length too much, as then the transitions between the boundary condition files may affect the model results.

Every time the XBeach wave boundary condition module is run, it outputs data to the local directory. Metadata about the wave boundary conditions are stored in list files: ebcflist.bcf and qbcflist.bcf. The main XBeach program uses the list files to know how and when to read and generate boundary condition files. The actual incoming short-wave energy and long-wave mass flux data is stored in other files. These files have E_ and q_ prefixes. The main XBeach program uses these files for the actual forcing along the offshore edge.

#### Description second order waves¶

When the keyword order is set to 2, the second order bound waves are included at the boundary. With the keyword highcomp both the sub-harmonics and the super-harmonics are included and otherwise only the sub-harmonics are included. A boundary without these bound waves will generate spurious free waves at the frequency of the bound waves with an equal amplitude but oppsing phase. These bound waves are generated by a pair of primairy waves or by the self-interaction of a single primairy wave. Thus, when a spectrum is forced at the boundary, the wave interactions for every component within the spectrum are computed.

The radial frequency and wave number of these bound waves are given by,

System Message: WARNING/2 ($\omega_3 = \omega_1 \pm \omega_2$)

latex exited with error [stdout] This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) (preloaded format=latex) restricted \write18 enabled. entering extended mode (./math.tex LaTeX2e <2017-04-15> Babel <3.18> and hyphenation patterns for 84 language(s) loaded. (/usr/share/texlive/texmf-dist/tex/latex/base/article.cls Document Class: article 2014/09/29 v1.4h Standard LaTeX document class (/usr/share/texlive/texmf-dist/tex/latex/base/size12.clo)) (/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty (/usr/share/texlive/texmf-dist/tex/latex/base/utf8.def (/usr/share/texlive/texmf-dist/tex/latex/base/t1enc.dfu) (/usr/share/texlive/texmf-dist/tex/latex/base/ot1enc.dfu) (/usr/share/texlive/texmf-dist/tex/latex/base/omsenc.dfu))) (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty For additional information on amsmath, use the `?' option. (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty)) (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty) (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty)) (/usr/share/texlive/texmf-dist/tex/latex/amscls/amsthm.sty) (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amssymb.sty (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amsfonts.sty)) (/usr/share/texlive/texmf-dist/tex/latex/anyfontsize/anyfontsize.sty) (/usr/share/texlive/texmf-dist/tex/latex/tools/bm.sty) (./math.aux) (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/umsa.fd) (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/umsb.fd) ! Missing } inserted. <inserted text> } l.14 ...mega_3 = \omega_1 \pm \omega_2$\end{split} ! Missing$ inserted. <inserted text> $l.14 ...mega_3 = \omega_1 \pm \omega_2$\end{split} ! Missing { inserted. <inserted text> { l.14 ...mega_3 = \omega_1 \pm \omega_2$\end{split} ! Missing$ inserted. <inserted text> $l.14 ...mega_3 = \omega_1 \pm \omega_2$\end{split} ! Missing } inserted. <inserted text> } l.14 ...mega_3 = \omega_1 \pm \omega_2$\end{split} ! Missing$ inserted. <inserted text> $l.14 ...mega_3 = \omega_1 \pm \omega_2$\end{split} ! Missing { inserted. <inserted text> { l.14 ...mega_3 = \omega_1 \pm \omega_2$\end{split} ! Missing$ inserted. <inserted text> $l.14 ...mega_3 = \omega_1 \pm \omega_2$\end{split} [1] (./math.aux) ) (see the transcript file for additional information) Output written on math.dvi (1 page, 408 bytes). Transcript written on math.log.

(179)

Where is the difference in direction between the two primary waves (). Summation result in the super-harmonic and substraction result in the sub-harmonic. [Has62] derived a theory, based on a weakly non-linear wave theory, to determine the amplitude of these bound waves (). In [OGS92] this theory is used to derive an expression for the second order energy density of a given wave-spectrum. According to this theory the energy of the super-harmonics is given by,

(180)

and the energy of the sub-harmonics is given by,

(181)

Where is the energy density of the first primary wave, the energy density of the second primary wave and the energy of the generated bound wave. The interaction coefficient, , is given by,

(182)

The phase of the bound wave is given by the sign of the coefficient. The amplitude of the bound wave for every pair of primary waves can be found with,

(183)

Where is the resolution of the primary spectrum and the sign of the interaction coefficient. Note that the is different than the difference frequency . The direction of the bound wave can be derived from geometry relations and it is given by,

(184)

Combing all these wave properties the following wave can be constructed,

(185)

For every par of primary waves, the bound wave is included in the boundary signal. When there are primary components in the spectrum, sub-harmonics will be generated and super-harmonics will be generated. In the case of the reduced two layer model (nh+), the bound wave velocity will be divided over both layers.

Fig. 16 Second order wave interaction for a given spectrum. The grey lines represent the primary waves and the coloured lines show the bound waves. The arrows indicate the interaction between two waves. The dots show the self-interaction of the primary waves.

### Non-hydrostatic¶

#### Global continuity equation¶

As was outlined in the previous chapter the global continuity equation, which describes the relation between the free surface and the depth averaged discharge, is given by

(186)

A simple semi-discretisation of using central differences for the space derivative and using the Hansen scheme for the coupling between velocity and free surface results in

(187)

With , and the water depth is defined by a first order accurate upwind interpolation

(188)

The resulting scheme is only first order accurate by virtue of the upwind interpolations and mass conservative. When first order computations are considered accurate enough is set to . For higher order accuracy the first order prediction is corrected using a limited version of the McCormack scheme. The corrector step reads

(189)

With and is given for positive flow as

(190)

Here denotes the minmod limiter. Similar expression can be constructed for negative flow. The expression for and are obtained in a similar manner. Note that the total flux at the cell boundaries thus reads

(191)

The predictor-corrector set is second order accurate in regions where the solution is smooth, and reduces locally to first order accuracy near discontinuities. Furthermore, the method remains mass conservative. Note that other flux limiters can be used instead of the minmod limiter. However, as the minmod limiter performed adequately, this has not been investigated. (for an overview of flux limiters see [Hir07])

#### Local continuity equation¶

The depth averaged local continuity equation is given by

(192)

This equation is discretized using central differences

(193)

Missing grid variables are approximated with upwind interpolation. Because there is no separate time evolution equation for the pressure the local continuity equation will be used to setup a discrete set of poison type equations in which the pressures are the only unknown quantities.

#### Horizontal Momentum¶

To obtain a conservative discretisation of the momentum equation the approach from [SZ03] is followed. However, to improve the accuracy of the method the combined space-time discretisation of the advection is done using a variant of the [Mac69] is used. This scheme consists of a first order predictor step and a flux limited corrector step. The hydrostatic pressure is integrated using the midpoint rule and central differences, while the source terms and the turbulent stresses are integrated using an explicit Euler time integration. Formally the time integration is therefore first order accurate, but in regions where the turbulent stresses are negligible the scheme is of almost second order accuracy.

The depth averaged horizontal momentum equation for is given by

(194)

A first order accurate predictor step in time and space is then given as

(195)

Here Pr represents a discretisation of the dynamic pressure; T the effect of (turbulent) viscosity and S includes all other source terms. The discretisation of the (turbulent) viscous terms is given by central differences:

(196)

Here and are obtained from the surrounding points by simple linear interpolation.

Due to the incompressible flow assumption the dynamic pressure does not have a separate time evolution equation, but instead it satisfies an elliptical equation in space. As such its effect cannot be calculated explicitly using values at the previous time level. However to improve the accuracy of the predictor step the effect of the dynamic pressure is included explicitly. To do this first the unknown pressure is decomposed as:

(197)

where the difference in pressure is generally small. In the predictor step the effect of the pressure is included explicitly using. In the corrector step the full Poisson equation is then solved for . The pressure term in the predictor step is thus given as

(198)

Here represents the average pressure over the vertical which is approximated with, in which is the pressure at the bottom. Furthermore is given as.

Currently is formulated with the depth integrated momentum as the primitive variable, and not the depth averaged velocity. To reformulate in terms of we use the method by [SZ03]. First note that and are approximated as and . Now using is equivalent to:

(199)

(200)

Substituting into the full expressions (including those for ) become:

(201)

Where we again use a first order upwind interpolation for and. This is exactly the approximation used by [SZ03] and is fully momentum conservative.

The predictor step is first order accurate in both space and time due to the use of upwind approximations for and Euler explicit time integration for the advective terms, and first order time integration for the source/viscous terms. This level of accuracy is acceptable near shore, where strong non-linearity (wave breaking, flooding and drying) will force the use of small steps in space and time anyway. However, in the region where waves only slowly change (e.g. shoaling/refraction on mild slopes), the first order approximations suffer from significant numerical damping. To improve the accuracy of the numerical model in these regions a corrector step is implemented after the predictor step.

The corrector step is given by:

(202)

Or, when formulated in terms of the depth averaged velocity

(203)

The values of are obtained from slope limited expressions. For positive flow these read:

(204)

Where again denotes the minmod limiter. Similar expressions can be constructed for, and.

The predictor-corrector set is second order accurate in regions where the solution is smooth, and reduces to first order accuracy near sharp gradients in the solutions to avoid unwanted oscillations. Furthermore, the method remains momentum conservative.

#### Vertical momentum equations¶

The vertical momentum equation is discretized in a similar manner to the horizontal momentum equations using the McCormack scheme. In terms of the depth averaged vertical velocity the predictor step is:

(205)

The pressures are defined on the cell faces and therefore do not have to be interpolated. Furthermore, we can exactly set the dynamic pressure at the free surface to zero. The vertical velocities are defined on the cell faces and therefore the depth averaged velocity needs to be expressed in terms of the bottom and surface velocities. Using a simple central approximation gives

(206)

At the bottom the kinematic boundary condition is used for the vertical velocity:

(207)

Horizontal interpolation of and is done using first order upwind similar to . The turbulent stresses are again approximated using a central scheme as

(208)

Thus combining, and explicit expressions for and are obtained.

The predicted values are again corrected using a variant of the McCormack scheme and including the pressure difference implicitly gives the corrector step:

(209)

Where and are obtained using relations similar to . Note that similar to and again the kinematic boundary conditions is substituted for .

The discrete vertical momentum balance of and looks very different from the relations found in [ZS05], [ZS08] and [Smi08]. This is mainly due to the application of the McCormack scheme for the advection. The discretisation of the pressure term is numerically fully equivalent to either the Keller box scheme as used in [ZS05], [ZS08] or the Hermetian relation used in [Smi08].

Bibliography

Ahr00

J. Ahrens. A fall velocity equation. Journal of Waterway, Port, Coastal and Ocean engineering, 126(2):99:102, 2000.

AM78

D. G. Andrews and M. E. Mcintyre. An exact theory of nonlinear waves on a Lagrangian-mean flow. Journal of Fluid Mechanics, 89:609, 1978. doi:10.1017/S0022112078002773.

BHBvW98(1,2)

T.E. Baldock, P. Holmes, S. Bunker, and P. van Weert. Cross-shore hydrodynamics within an unsaturated surfzone. Coastal Engineering, 34:173–196, 1998.

Bat75

J. A. Battjes. Modelling of turbulence in the surfzone. Symposium on Modelling Techniques, San Francisco,, pages 1050–1061, 1975.

BW76

Richard M. Beam and R. F. Warming. An implicit finite-difference algorithm for hyperbolic systems in conservation-law form. Journal of Computational Physics, 22(1):87–110, 1976. doi:10.1016/0021-9991(76)90110-8.

Con94

D.L. Conley, D.C.; Inman. Ventilated oscillatory boundary layers. journal of fluid mechanics. Journal of Fluid Mechanics 273, 1994.

DKH84

R.A Dalrymple, J.T. Kirby, and P.A Hwang. Wave diffraction due to areas of energy dissipation. Journal of Waterway, Port, Coastal and Ocean Engineering, pages 67–79, 1984.

DRvD+10

Christopher Daly, J. A. Roelvink, A. R. van Dongeren, J. S. M. Van Thiel de Vries, and R. T. McCall. Short wave breaking effects on low frequency waves. Proceedings 32th International Conference on Coastal Engineering, pages 1–13, 2010.

DRvD+12

Christopher Daly, J. A. Roelvink, A. R. van Dongeren, J. S. M. van Thiel de Vries, and R. T. McCall. Validation of an advective-deterministic approach to short wave breaking in a surf-beat model. Coastal Engineering, 60:69–83, February 2012. URL: http://linkinghub.elsevier.com/retrieve/pii/S0378383911001517, doi:10.1016/j.coastaleng.2011.08.001.

Dar56

H. Darcy. Les fontaines publiques de la ville de dijon. Tech. Rep., Dalmont, Paris, 1856.

dJRB13

M. P. C. de Jong, J. A. Roelvink, and C. Breederveld. Numerical modelling of passing-ship effects in complex geometries and on shallow water. Pianc Smart Rivers 2013, 2013.

dRSvD+21

Menno P de Ridder, Pieter B Smit, Ap R van Dongeren, Robert T McCall, Kees Nederhoff, and Ad JHM Reniers. Efficient two-layer non-hydrostatic wave model with accurate dispersive behaviour. Coastal Engineering, 164:103808, 2021.

dV14(1,2)

P. L. M. de Vet. Modelling sediment transport and morphology during overwash and breaching events. Technical Report, Delft University of Technology, Delft, 2014.

Dei93

R. Deigaard. A note on the three-dimensional shear stress distribution in a surf zone. Coastal Engineering, 20:157–171, 1993. doi:10.1016/0378-3839(93)90059-H.

Del11

Deltares. Delft3D-FLOW: user manual. Technical Report, Version 3.15. Revision: 14499, 2011.

dA87

H den Adel. Heranalyse doorlatendheidsmetingen door middel van de forchheimer relatie. Technical Report M 1795/H 195, CO 272550/56, Grondmechanica Delft, Waterloopkundig Laboratorium. Dutch., 1987.

Fre92

R. Fredsøe, J.; Deigaard. Mechanics of Coastal Sediment Transport. Advanced Series on Ocean Engineering,. World Scientific, Singapore., 1992.

GV83

R. Galappatti and C. B. Vreugdenhill. A depth integrated model for suspended transport. Journal for Hydraulic Research, 23(4):359–377, 1983.

GT85

R. T. Guza and E. B. Thornton. Velocity moments in the nearshore. Coastal Engineering, 111(2):235–256, 1985.

Hal00

K. Halford. Simulation and interpretation of borehole flowmeter results under laminar and turbulent flow conditions. Proceedings of the Seventh International Symposium on Logging for Minerals and Geotechnical Applications, Golden, Colorado, The Minerals and Geotechnical Logging Society, pages 157–168, 2000.

Hal81

R.J. Hallermeier. Terminal settling velocity of commonly occurring sand grains. Sedimentology, 28:859–865, 1981.

Har05

A. W. Harbaugh. MODFLOW-2005 , The USGS Modular Ground-Water Model. U.S. Geological Survey Techniques and Methods, pages 253, 2005.

Has62

K Hasselmann. On the non-linear energy transfer in a gravity wave spectrum. Journal of Fluid Mechanics, 12((4)):481–500, 1962. doi:10.1017/S0022112062000373.

Hir07

C. Hirsch. Numerical computation of internal & external flows. New York, John Wiley & Sons., 2007.

HBH89(1,2,3)

L.H. Holthuijsen, N. Booij, and T.H.C. Herbers. A prediction model for stationary, short-crested waves in shallow water with ambient currents. Coastal Engineering, 13(1):23–54, May 1989. URL: http://linkinghub.elsevier.com/retrieve/pii/0378383989900318, doi:10.1016/0378-3839(89)90031-8.

JB07

T. T. Janssen and J. A. Battjes. A note on wave energy dissipation over steep beaches. Coastal Engineering, 54:711–716, 2007. doi:10.1016/j.coastaleng.2007.05.006.

KM75(1,2)

P. D. Komar and M. C. Miller. On the comparison between the threshold of sediment motion under waves under unidirectional currents with a discussion of the practical evaluation of the threshold. Journal of Sedimentary Research, pages 362–367, 1975.

LS76

D. C. L. Lam and R. B. Simpson. Centered differencing and the box scheme for diffusion convection problems. Journal of Computational Physics, 22:486–500, 1976.

LMHK07

K. H. Lee, Norimi Mizutani, Dong S. Hur, and Atsushi Kamiya. The effect of groundwater on topographic changes in a gravel beach. Ocean Engineering, 34:605–615, 2007. doi:10.1016/j.oceaneng.2005.10.026.

LB00

L. Li and D. A. Barry. Wave-induced beach groundwater flow. Advances in Water Resources, 23:325–337, 2000. doi:10.1016/S0309-1708(99)00032-9.

LHS62

M. S. Longuet-Higgins and R. W. Stewart. Radiation stress and mass transport in gravity waves, with application to ‘surf beats’. Journal of Fluid Mechanics, 13:481–504, 1962.

LHS64(1,2,3)

M. S. Longuet-Higgins and R. W. Stewart. Radiation stress in water waves: a physical discussion with applications. Deep-Sea Research, pages 529–562, 1964.

LHT74

M. S. Longuet-Higgins and J. S. Turner. An ‘entraining plume’ model of a spilling breaker. Journal of Fluid Mechanics, 63(01):1–20, 1974.

LFK+07

R. J. Lowe, James L. Falter, Jeffrey R. Koseff, Stephen G. Monismith, and Marlin J. Atkinson. Spectral wave flow attenuation within submerged canopies: Implications for wave energy dissipation. Journal of Geophysical Research, 112:1–14, 2007. doi:10.1029/2006JC003605.

Mac69

R.W. MacCormack. The effect of viscosity in hypervelocity impact cratering. AIAA Hyper velocity Impact Conference. Paper 69-354., 1969.

MMP+14(1,2,3)

R. T. McCall, Gerhard Masselink, T. G. Poate, J. a. Roelvink, L. P. Almeida, M. Davidson, and P. E. Russell. Modelling storm hydrodynamics on gravel beaches with XBeach-G. Coastal Engineering, 91:231–250, 2014. URL: http://dx.doi.org/10.1016/j.coastaleng.2014.06.007, doi:10.1016/j.coastaleng.2014.06.007.

ML04

F. J. Mendez and I. J. Losada. An empirical model to estimate the propagation of random breaking and nonbreaking waves over vegetation fields. Coastal Engineering, 51:103–118, 2004. doi:10.1016/j.coastaleng.2003.11.003.

NRS90(1,2,3,4)

R.B. Nairn, J. A. Roelvink, and H.N. Southgate. Transition zone width and implications for modeling surfzone hydrodynamics. Proceedings 22th International Conference on Coastal Engineering, pages 68–81, 1990. doi:10.9753/icce.v22.

NLB+15(1,2)

C. M. Nederhoff, Q. J. Lodder, Marien Boers, J. P. Den Bieman, and J. K. Miller. Modeling the effects of hard structures on dune erosion and overwash - a case study of the impact of Hurricane Sandy on the New Jersey coast. Proceedings Coastal Sediments, San Diego, CA, 2015.

OGS92

Michele Okihiro, R T Guza, and R J Seymour. Bound infragravity waves. Journal of Geophysical Research : Oceans, 97(7):11453–11469, 1992. doi:10.1029/92JC00270.

Phi77(1,2)

O.M. Phillips. The dynamics of the upper ocean. Cambridge University Press, pages 366, 1977.

RGE99

B. Raubenheimer, R. T. Guza, and Steve Elgar. Tidal water table fluctuations in a sandy ocean beach. Water Resources Research, 35(8):2313, 1999. doi:10.1029/1999WR900105.

RMTS07

A. J. H. M. Reniers, J. H. MacMahan, E. B. Thornton, and T. P. Stanton. Modeling of very low frequency motions during RIPEX. Journal of Geophysical Research, 112(February):1–14, 2007. doi:10.1029/2005JC003122.

RRT04

A. J. H. M. Reniers, J. A. Roelvink, and E. B. Thornton. Morphodynamic modeling of an embayed beach under wave group forcing. Journal of Geophysical Research, 109:1–22, 2004. doi:10.1029/2002JC001586.

RZ54

J. Richardson and W. Zaki. Sedimentation and fluidisation - Part i. Trans. Inst. Chem. Eng., 32(1):35–53, 1954.

RF81(1,2)

M. M. Rienecker and J. D. Fenton. A Fourier approximation method for steady water waves. Journal of Fluid Mechanics, 104:119, 1981. doi:10.1017/S0022112081002851.

Roe93(1,2,3)

J. A. Roelvink. Dissipation in random wave group incident on a beach. Coastal Engineering, 19:127–150, 1993.

Roe06

J. A. Roelvink. Coastal morphodynamic evolution techniques. Coastal Engineering, 53:277–287, 2006. doi:10.1016/j.coastaleng.2005.10.015.

RRvD+09

J. A. Roelvink, A. J. H. M Reniers, A. R. van Dongeren, J. S. M. van Thiel de Vries, R. T. McCall, and Jamie Lescinski. Modelling storm impacts on beaches, dunes and barrier islands. Coastal Engineering, 56(11-12):1133–1152, November 2009. URL: http://linkinghub.elsevier.com/retrieve/pii/S0378383909001252, doi:10.1016/j.coastaleng.2009.08.006.

RS89(1,2,3)

J. A. Roelvink and M. J. F. Stive. Bar-generating cross-shore flow mechanisms on a beach. Journal of Geophysical Research, 94:4785–4800, 1989.

Row87

P.N. Rowe. A convenient empirical equation for estimation of the richardson-zaki exponent. Chemical Engineering Science, 42(11):2795 – 2796, 1987.

RMF+01

B. G. Ruessink, J.R. Miles, F. Feddersen, R. T. Guza, and Steve Elgar. Modeling the alongshore current on barred beaches. Journal of Geophysical Research, 106(22):451–463, 2001.

RRvR12(1,2,3,4,5)

B. G. Ruessink, G. Ramaekers, and L. C. van Rijn. On the parameterization of the free-stream non-linear wave orbital motion in nearshore morphodynamic models. Coastal Engineering, 65:56–63, July 2012. URL: http://linkinghub.elsevier.com/retrieve/pii/S0378383912000488, doi:10.1016/j.coastaleng.2012.03.006.

SHvdWT11

M. Schroevers, B.J. Huisman, A. van der Wal, and J. Terwindt. Measuring ship induced waves and currents on a tidal flat in the Western Scheldt Estuary. Current, Waves and Turbulence Measurements (CWTM), 2011 IEEE/OES 10th, pages 123–129, 2011.

Shi36(1,2)

A. Shields. Anwendung der Aehnlichkeitsmechanik under der Turbulenzforschung auf die Geschiebebewegung. Preussischen Versuchsanstalt fur Wasserbau and Schiffbau, 26:524–526, 1936.

Sma63

J. Smagorinsky. General circulation experiments wiht the primitive equations I. The basic experiment. Monthly Weather Review, 91:99–164, 1963. doi:10.1126/science.27.693.594.

Smi08(1,2)

P. B. Smit. Non-hydrostatic modelling of large scale tsunamis. Technical Report, MSc thesis, Delft University of Technology, Delft, 2008.

SJHS14(1,2)

P. B. Smit, T. T. Janssen, L.H. Holthuijsen, and Jane Smith. Non-hydrostatic modeling of surf zone wave dynamics. Coastal Engineering, 83:36–48, 2014. URL: http://dx.doi.org/10.1016/j.coastaleng.2013.09.005, doi:10.1016/j.coastaleng.2013.09.005.

Sou97(1,2,3,4,5,6)

R.L. Soulsby. Dynamics of Marine Sands. Thomas Telford Publications, London, 1997. ISBN 07272584X.

Ste93

H J Steetzel. Cross-shore transport during storm surges. Technical Report, Thesis Delft University of Technology, 1993.

SZ03(1,2,3,4)

G. S. Stelling and Marcel Zijlema. An accurate and efficient finite-difference algorithm for non-hydrostatic free-surface flow with application to wave propagation. International Journal for Numerical Methods in Fluids, 43(1):1–23, 2003.

SDeVriend94(1,2,3)

M. J. F. Stive and H. J. De Vriend. Shear stresses and mean flow in shoaling and breaking waves. Proceedings 24th International Conference on Coastal Engineering, pages 594–608, 1994. doi:10.9753/icce.v24.

Sto68

H.L. Stone. Iterative Solution of Implicit Approximations of Multidimensional Partial Differential Equations. Journal on Numerical Analysis, 5(3):530–658, 1968.

SZB+12(1,2)

Tomohiro Suzuki, Marcel Zijlema, Bastiaan Burger, Martijn C. Meijer, and Siddharth Narayan. Wave dissipation by vegetation with layer schematization in SWAN. Coastal Engineering, 59(1):64–71, 2012. URL: http://dx.doi.org/10.1016/j.coastaleng.2011.07.006, doi:10.1016/j.coastaleng.2011.07.006.

Sve84(1,2,3)

I. A. Svendsen. Wave heights and set-up in a surf zone. Coastal Engineering, 8:303–329, 1984. doi:10.1016/0378-3839(84)90028-0.

TvMS95

A. M. Talmon, M. C. van Mierlo, and N. Struiksma. Laboratory measurements of the direction of sediment transport on transverse alluvial-bed slope. Journal of Hydraulic Research, 33(4):495–517, 1995.

Tho49

L. H. Thomas. Elliptic problems in linear difference equations over a network. Technical Report, Watson Sci. Comput. Lab., Columbia University, 1949.

vB47

L. van Bendegom. Enige beschouwingen over riviermorphologie en rivierverbetering. Technical Report, Ministerie van Verkeer en Waterstaat. Dutch., 1947.

vdZ14

J. van der Zwaag. Modelling sediment sorting near the large scale nourishment ’ The Sand Motor ’. Technical Report, Delft University of Technology, Delft, 2014.

vDS97

A. R. van Dongeren and I. A. Svendsen. An Absorbing-Generating Boundary condition for Shallow Water Models. J. of Waterways, Ports, Coastal and Ocean Engineering, vol. 123, no. 6, pp. 303-313. Journal of Waterways, Ports, Coastal and Ocean Engineering, 123(6):303–313, 1997.

vR10(1,2)

C van Rhee. Sediment entrainment at high flow velocity. Journal of Hydraulic Engineering, 136:572–582, 2010.

vR85

L. C. van Rijn. Sediment transport, part III: bed forms and alluvial roughness. Journal of Hydraulic Engineering, 110(12):1733–1754, 1985.

vR07(1,2,3)

L. C. van Rijn. Unified View of Sediment Transport by Currents and Waves: part I and II. Journal of Hydraulic Engineering, pages 649–667, 2007.

vRVanTdVriesM+15(1,2)

A.A. van Rooijen, J. S. M. Van Thiel de Vries, R. T. McCall, A. R. van Dongeren, J. A. Roelvink, and A. J. H. M. Reniers. Modeling of wave attenuation by vegetation with XBeach. E-proceedings of the 36th IAHR World Congress 28 June – 3 July, 2015, The Hague, The Netherlands., 2015.

VSO81

G.K. Verboom, G. S. Stelling, and M.J. Officer. Boundary conditions for the shallow water equations. Engineering applications of computational hydraulics, pages 230–262., 1981.

WRG00

D. J. R. Walstra, J. A. Roelvink, and J. Groeneweg. Calculation of wave-driven currents in a 3D mean flow model. In Proceedings 27th International Conference on Coastal Engineering, 1050–1063. 2000.

WvRVanOrmondt+07

D. J. R. Walstra, L. C. van Rijn, Maarten Van Ormondt, C. Briere, and A. M. Talmon. The Effects of Bed Slope and Wave Skewness on Sediment Transport and Morphology. In Coastal Sediments ’07, 137–150. 2007.

ZRVL13(1,2)

M. Zhou, J. A. Roelvink, H. J. Verheij, and H. Ligteringen. Study of Passing Ship Effects along a Bank by Delft3D-FLOW and XBeach. International Workshop on Nautical Traffic Models 2013, Delft, The Netherlands, July 5-7, 2013. Delft University of Technology, 2013.

ZRZvW14

M. Zhou, J. A. Roelvink, Z. Zou, and H. J. van Wijhe. Effects of Passing Ship With a Drift Angle on a Moored Ship. ASME 2014 33rd International Conference on Ocean, Offshore and Arctic Engineering, 2014.

ZS05(1,2)

M. Zijlema and G. S. Stelling. Further experiences with computing non-hydrostatic free-surface flows involving water waves. INTERNATIONAL JOURNAL FOR NUMERICAL METHODS IN FLUIDS, pages 169–197, 2005.

ZS08(1,2)

M. Zijlema and G. S. Stelling. Efficient computation of surf zone waves using the nonlinear shallow water equations with non-hydrostatic pressure. Coastal Engineering, 55(10):780–790, 2008.

ZSS11(1,2,3,4)

Marcel Zijlema, G. S. Stelling, and P. B. Smit. SWASH: An operational public domain code for simulating wave fields and rapidly varied flows in coastal waters. Coastal Engineering, 58(10):992–1012, 2011. URL: http://dx.doi.org/10.1016/j.coastaleng.2011.05.015, doi:10.1016/j.coastaleng.2011.05.015.

VanRijn84

L. C. Van Rijn. Sediment transport, part II: suspended load transport. Journal of Hydraulic Engineering, 110:1613–1641, 1984.

vanTdVries09(1,2,3,4,5,6,7)

J. S. M. van Thiel de Vries. Dune erosion during storm surges. PhD thesis, PhD thesis, Delft Unversity of Technology, Delft, 2009.

Footnotes

2

Currently, this formulation is only possible when the wave shape formulation of [vanTdVries09] is applied, see Wave shape.