xbeach simulation software · 2019. 3. 25. · importance pour la dfense et la scurit les travaux...

78
Defence Research and Development Canada Reference Document DRDC-RDDC-2018-D166 March 2019 CAN UNCLASSIFIED CAN UNCLASSIFIED XBeach Simulation Software Modelling Seafloor Activity for Change Detection Optimization Cody MacDonald Dalhousie University, Department of Environmental Engineering

Upload: others

Post on 13-Feb-2021

4 views

Category:

Documents


0 download

TRANSCRIPT

  • Defence Research and Development Canada Reference Document DRDC-RDDC-2018-D166 March 2019

    CAN UNCLASSIFIED

    CAN UNCLASSIFIED

    XBeach Simulation Software Modelling Seafloor Activity for Change Detection Optimization

    Cody MacDonald Dalhousie University, Department of Environmental Engineering

  • CAN UNCLASSIFIED

    Template in use: EO Publishing App for SR-RD-EC Eng 2018-12-19_v1.dotm

    © Her Majesty the Queen in Right of Canada (Department of National Defence), 2019 © Sa Majesté la Reine en droit du Canada (Ministère de la Défense nationale), 2019

    CAN UNCLASSIFIED

    IMPORTANT INFORMATIVE STATEMENTS

    This document was reviewed for Controlled Goods by Defence Research and Development Canada (DRDC) using the Schedule to the Defence Production Act.

    Disclaimer: Her Majesty the Queen in right of Canada, as represented by the Minister of National Defence ("Canada"), makes no representations or warranties, express or implied, of any kind whatsoever, and assumes no liability for the accuracy, reliability, completeness, currency or usefulness of any information, product, process or material included in this document. Nothing in this document should be interpreted as an endorsement for the specific use of any tool, technique or process examined in it. Any reliance on, or use of, any information, product, process or material included in this document is at the sole risk of the person so using it or relying on it. Canada does not assume any liability in respect of any damages or losses arising out of or in connection with the use of, or reliance on, any information, product, process or material included in this document.

    Endorsement statement: This publication has been published by the Editorial Office of Defence Research and Development Canada, an agency of the Department of National Defence of Canada. Inquiries can be sent to: [email protected].

    This work was performed in fulfillment of the requirements for a Coop Work Term with the Department of Environmental Engineering, Dalhousie University, under the supervision of Dr. Anna Crawford, DRDC – Atlantic Research Centre.

  • DRDC-RDDC-2018-D166 i

    Abstract

    In order to provide efficient Mine Countermeasures (MCM) with change detection, an appropriate interval between sonar surveys must be determined. Inadequate time intervals between resurvey can result in false alarms in the change detection process, or additional and unnecessary cost of performing routine surveys too frequently. In the event of an object identification alarm, an investigation must be performed thus prompting the effort in creating a cost effective and accurate method of determining the time scale of the seabed changes likely to cause false alarms. This Reference Document examines the use of open source software named XBeach for measuring seafloor activity. This includes tabulated information related to the MATrix LABoratory (MATLAB) toolbox and the methods of performing simulations using the XBeach software. The XBeach visualization simulations provide engaging imagery of sediment transport plotted over a world coordinate system. It was determined that the morphological simulations could provide insight into the seabed activity associated with the modeled locations.

    The opportunity exists to optimize routine survey scheduling and reduce false alarms associated with change detection through the aid of XBeach. XBeach software is a cost free solution that can reduce costs associated with performing routine survey assignments. Ultimately, the information acquired from XBeach should be integrated into survey planning tools for repeat seabed surveys in tactically significant areas where change detection is the method of choice for seabed object identification.

    Significance to Defence and Security

    The work reported here was performed as a Dalhousie University, Department of Environmental Engineering, Coop Work Term with the Mine Warfare (MW) group at DRDC – Atlantic Research Centre. It contributes to an ongoing MW research program which has the goal of developing a tactical decision aid for scheduling of survey operations to optimize the effectiveness of a change detection approach to Route Survey. The model that was investigated in this work, XBeach, was a candidate for providing accurate seabed sediment dynamics as one of the inputs to a larger model for prediction of seabed changeability due to natural influences. The results of the investigation indicate that while the XBeach model is very powerful and provides several useful sediment dynamics outputs, it would be difficult to implement for complicated domain areas such as Halifax Harbour, due to the absence of a straight-coast geometry, which the model requires. The MW research program will carry on with investigation of other options.

  • ii DRDC-RDDC-2018-D166

    Résumé

    Afin d’assurer l’efficacité de la lutte contre les mines avec détection de variation, on doit déterminer l’intervalle approprié entre les relevés sonar. Des intervalles de temps inadéquats entre les relevés peuvent entraîner de fausses alarmes dans le processus de détection de variation, ou des coûts supplémentaires inutiles pour effectuer des relevés de routine trop fréquents. Dans le cas d’une alarme d’identification d’objets, on doit procéder à une enquête, ce qui incite à élaborer une méthode rentable et précise pour déterminer l’échelle temporelle des variations du fond marin susceptibles de provoquer de fausses alarmes. Dans ce document de référence, on examine l’utilisation d’un logiciel ouvert appelé XBeach pour mesurer l’activité des fonds marins. Cela inclut l’information tabulée relative à la trousse d’outils MATLAB et aux méthodes d’exécution des simulations à l’aide du logiciel XBeach. Les simulations de visualisation XBeach fournissent des images fascinantes du transport des sédiments sur un système de coordonnées universelles. On a déterminé que les simulations morphologiques permettront d’avoir un aperçu de l’activité du fond marin associée aux emplacements modélisés.

    Grâce à XBeach, il est possible d’optimiser la planification des relevés de routine et de réduire les fausses alarmes attribuables à la détection de variation. Le logiciel XBeach est une solution gratuite qui permet de réduire les coûts associés à la prise de relevés de routine. Essentiellement, l’information obtenue grâce à XBeach devrait être intégrée aux outils de planification pour les relevés répétés des fonds marins dans les zones importantes sur le plan tactique, où la détection de variation est la méthode par excellence pour l’identification d’objets dans le fond marin.

    Importance pour la défense et la sécurité

    Les travaux dont il est question ici ont été effectués dans le cadre d’un stage de travail coopératif au Département de génie environnemental de l’Université Dalhousie, avec le Groupe de guerre des mines (GM) du Centre de recherches de l’Atlantique de RDDC. Il contribue à un programme de recherche en cours sur la GM dont l’objectif est d’élaborer un outil d’aide à la décision tactique pour la planification de la prise de relevés en vue d’optimiser l’efficacité d’une approche de détection de variation des fonds marins. Le modèle étudié dans le cadre de ces travaux, XBeach, était en lice pour fournir la dynamique précise des sédiments du fond marin comme l’un des intrants d’un modèle plus vaste de prévision de la variabilité du fond marin par des causes naturelles. Les résultats de l’étude indiquent que, même si le modèle XBeach est très puissant et fournit plusieurs résultats utiles sur la dynamique des sédiments, il serait difficile à mettre en œuvre dans des zones complexes comme le port d’Halifax, en raison de l’absence d’une géométrie côtière en ligne droite, ce que le modèle exige. Le programme de recherche sur la GM se poursuivra par l’étude d’autres options.

  • DRDC-RDDC-2018-D166 iii

    Table of contents

    Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i Significance to Defence and Security . . . . . . . . . . . . . . . . . . . . . . . . . i Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii Importance pour la défense et la sécurité . . . . . . . . . . . . . . . . . . . . . . . ii Table of contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii List of figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

    1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

    2 XBeach Modelling Binary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

    3.1 Using MATLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Generating The Model . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Generating The Bathymetry Input . . . . . . . . . . . . . . . . . . . . . . 7 3.4 Generating Tide and Wave Inputs . . . . . . . . . . . . . . . . . . . . . . 8 3.5 Additional Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6 Reading and Writing Files . . . . . . . . . . . . . . . . . . . . . . . . 10 3.7 Visualization Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 11

    4 Simulation and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1 Simulation Locations . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2 Herring Cove Model Domain . . . . . . . . . . . . . . . . . . . . . . . 17 4.3 Wave and Tides Inputs . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.4 Sediment Transport Results . . . . . . . . . . . . . . . . . . . . . . . 21

    5 Conclusions and Recommendations . . . . . . . . . . . . . . . . . . . . . . . 26 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Annex A Input Parameters in PARAMS.TXT (Roelvink et al., 2010) . . . . . . . . . . . 29 Annex B Output Variables for Specifying NGLOBALVAR (Roelvink, 2010) . . . . . . . . 48 Annex C Equations (Roelvink, 2010) . . . . . . . . . . . . . . . . . . . . . . . 54 Annex D MATLAB Functions (Hoonhout, 2010) . . . . . . . . . . . . . . . . . . . 56 Annex E Additional Example Scripts and Text Files (Roelvink, 2010) . . . . . . . . . . . 61

  • iv DRDC-RDDC-2018-D166

    List of figures

    Figure 1: Two sonar images, image (A) referring to historical data and image (B) referring to recent data. The red circle encloses a recently placed object; image processing recognizes the change in pixels and provokes a change detection alarm. . . . . . . . 1

    Figure 2: XBeach coordinate system (A) and staggered grid (B). The coordinate system is defined relative to world coordinates (xw, yw) through the origin (xori, yori,) and counter-clockwise orientation (alfa) defined with respect to the xw-axis (Daly, 2009). . 4

    Figure 3: Simulation modules within XBeach. The arrows on the image represent the outputs and connectivity between the modules and italics show module outputs. Boundary conditions are only used on the first cycle of calculations (Daly, 2009). . . . . . . . 5

    Figure 4: MATLAB model generating script. This script represents the method for assigning values to the variables contained within the function. This will store the XBeach structure in the variable “xbm”. . . . . . . . . . . . . . . . . . . . . . . . 8

    Figure 5: Sediment concentration plots created using the “xb_plot_sedtrans” function contained in the MATLAB toolbox. This represents concentration, turbulence and sediment transport due to morphology and hydrodynamic conditions. The x-axis represents horizontal distance across the model domain transformed to world coordinates, metres in a UTM projection. . . . . . . . . . . . . . . . . . . . . . . . . . . 12

    Figure 6: Hydrodynamic plots created using the “xb_plot_hydro” function contained in the MATLAB toolbox. This represents the wave height of both high and low frequency waves and the flow velocities. The x-axis represents horizontal distance across the model domain, similar to the previous Figure. . . . . . . . . . . . . . . . . 13

    Figure 7: Bedford Basin chart and survey lines represented using Global Mapper, a geographic information system software package. The bounding box for the XBeach domain is shown by the tilted rectangle. . . . . . . . . . . . . . . . . . . . . . . . 15

    Figure 8: Ives Knoll chart, survey lines and XBeach domain box The yellow box shows the area covered by an inset chart not included. . . . . . . . . . . . . . . . . . . . 15

    Figure 9: Herring Cove chart, survey lines and XBeach domain box. . . . . . . . . . . . 16

    Figure 10: Herring Cove bathymetry plotted by uploading bathymetric data points into Global Mapper (v15.1). Bathymetric data was provided by Canadian Hydrographic Services. Colour-scaled depths range from 37 m (blue) to the shoreline (0 m, red). The shoal in the center of the image is 5 m depth at the shallowest. . . . . . . . . . . . . . 18

    Figure 11: Herring Cove bathymetry decimated and rotated to model coordinates, plotted using MATLAB XBeach display tools. . . . . . . . . . . . . . . . . . . . . . 18

    Figure 12: Surficial geology of Herring Cove, where label“1” is “Acoustic Basement” (bedrock), “6” is Gravel and “7”is Sable Island Sand and Gravel (Fader and Miller, 2008, Figure 21). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

    Figure 13: Depth of the top of the non-erodible layer in the Herring Cove model domain, created using XBeach and MATLAB. . . . . . . . . . . . . . . . . . . . . . . . 20

  • DRDC-RDDC-2018-D166 v

    Figure 14: Wave velocity simulation created by using the JONSWAP boundary conditions of 11-metre wave height, 4-second peak period and mean wave direction of 245°. Image(A) referring to X-Velocity and image (B) referring to Y-velocity create a patterntowards the top right. . . . . . . . . . . . . . . . . . . . . . . . . . . 21

    Figure 15: Wave velocity simulation created by using the JONSWAP boundary conditions of 11-metre wave height, 4-second peak period and mean wave direction of 315°. Image(A) referring to X-Velocity and image (B) referring to Y-velocity create a patterntowards the bottom right. . . . . . . . . . . . . . . . . . . . . . . . . . 21

    Figure 16: Sediment transport integrated over bed load in the X-direction (Sutot). . . . . . . 22

    Figure 17: Sediment transport integrated over bed load in the Y-direction (Svtot). . . . . . . 23

    Figure 18: Sediment concentration integrated over bed load in the X-direction (cctot). . . . . 23

    Figure 19: Cumulative sedimentation and erosion (sedero). . . . . . . . . . . . . . . . 24

    Figure 20: Rate of change of bed level (dzbdt). This is the output of most importance due to its ability to represent the overall change in the bathymetry per unit time. . . . . . . 25

    Figure E.1: An example of a formatted variance density file created when using the wave boundary condition type Vardens. This file can be created by using the MATLAB toolbox or created manually outside of MATLAB. This is the same format used when “instat = 6” is defined. . . . . . . . . . . . . . . . . . . . . . . . . . . 61

    Figure E.2: An example of a formatted SWAN wave boundary file created when using the wave boundary condition type SWAN. This is the same format used when “instat = 5” is defined. . . . . . . . . . . . . . . . . . . . . . . . . . . 62

  • vi DRDC-RDDC-2018-D166

    List of tables

    Table 1: Table of values used to define wave boundaries with the variable “instat”; values of 4 and 6 are the only scenarios that can be produced using the MATLAB toolbox. . . 10

    Table 2: Table of coordinates of the start and end points of the survey lines at Herring Cove, Ives Knoll and Bedford Basin. Information was supplied by RCN RSO. . . . . . . 16

    Table A.1: Bed composition parameters used to specify details relating to hard layers and sediment classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

    Table A.2: Bed update numerics parameters used to alter the seabed updating computational process. These are advanced options and are not documented in the XBeach manual. 30

    Table A.3: Coriolis force parameters used to alter the Coriolis effect on the simulation. These are advanced options and are not documented in the XBeach manual. . . . . . . . . 30

    Table A.4: Discharge boundary condition parameters used to specify locations of discharge. These are advanced options and are not documented in the XBeach manual. . . . . . . . 30

    Table A.5: Drifters parameters used to perform a simulation of drifters. These are advanced options and are not required for most simulations. . . . . . . . . . . . . . . . 31

    Table A.6: Flow boundary condition parameters used for switching the method of flow computation at the boundary. . . . . . . . . . . . . . . . . . . . . . . . 31

    Table A.7: Flow numeric parameters used for placing limiters on methods for calculating flow. These are advanced options and are not required for most simulations. . . . . . . 33

    Table A.8: Flow parameters used for specifying the viscosity and friction factors of an XBeach simulation. These are advanced options and are not required for most simulations. . 33

    Table A.9: Grid parameters used to define the bathymetry and the orientation of the computational grid. The majority of these parameters must be defined to run an XBeach simulation. 34

    Table A.10: Groundwater flow parameters used for defining properties for the groundwater module. These are advanced options and are not required for most simulations. . . . 35

    Table A.11: Initial conditions parameters used to define a small quantity of values at the start of the simulation. These are advanced options and are not required for most simulations. . 36

    Table A.12: Model time parameters are used to define stop time of the simulation. This must be defined to execute the model. . . . . . . . . . . . . . . . . . . . . . . . 36

    Table A.13: Multiple Parallel Instances (MPI) parameters. This is an advanced option and is not documented in the XBeach manual. . . . . . . . . . . . . . . . . . . . . 36

    Table A.14: Morphology parameters used to specify the morphological updating and avalanching features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

    Table A.15: Non-hydrostatic parameters used for creating a non-hydrostatic simulation. These are advanced options with minimum documentation. . . . . . . . . . . . . . . . 38

    Table A.16: Physical process parameters are used as switches to activate the major modules of XBeach. The value of 1 will turn on the process and the value of 0 will exclude it.. . 38

  • DRDC-RDDC-2018-D166 vii

    Table A.17: Physical constraints used to change the density and gravitational acceleration used for the XBeach simulations. . . . . . . . . . . . . . . . . . . . . . . . . . 39

    Table A.18: Roller parameters are used to turn on the roller model for simulations. The XBeach manual says that rollers have been implemented as of June 21, 2010. . . . . . . . 39

    Table A.19: Sediment transport parameters used to change the sediment computation models and altering the calibration factors. The majority of these functions are advanced tools and are not required for most XBeach simulations. . . . . . . . . . . . . . . . . 40

    Table A.20: Sediment transport numerics parameters are advanced options and are not required for most simulations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

    Table A.21: Tide boundary conditions are used to define the tidal conditions that are being used in the simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

    Table A.22: Vegetation parameters are used to specify vegetation in the area of simulation however it has not yet been fully developed. . . . . . . . . . . . . . . . . . . . . . 42

    Table A.23: Waves boundary condition parameters used to define the wave spectrum. . . . . . 42

    Table A.24: Wave breaking parameters are used to specify the conditions and models associated with wave breaking and dissipation. . . . . . . . . . . . . . . . . . . . . 43

    Table A.25: Wave current interaction parameters used to specify the conditions and models associated with wave and current interaction. . . . . . . . . . . . . . . . . . 44

    Table A.26: Wave numerics parameters are advanced options and are not required for most simulations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

    Table A.27: Wave-spectrum boundary condition parameters are used to alter wave spectrum and are based on the “instat” value assigned. . . . . . . . . . . . . . . . . . . 44

    Table A.28: Wind parameters used to specify the wind conditions in the location of simulation. These are advanced options and are not required for most simulations. . . . . . . 45

    Table A.29: XBeach output variables used to alter the time step and the results obtained from the model. These must be specified depending on the outputs of interest. . . . . . . . 45

    Table A.30: Output projection parameters are advanced options with no documentation and are not required for most simulations. . . . . . . . . . . . . . . . . . . . . . . . 47

    Table B.1: XBeach output list containing variables to specify “nglobalvar”. . . . . . . . . . 48

    Table D.1: XBeach toolbox functions. This table includes functions that are no longer maintained and functions that have not yet been implemented (i.e., ship functions). . . . . . . 56

    Table D.2: XStruct toolbox functions. These functions originate from the XBeach toolbox however it was later determined that they were reasonably generic. Thus they were given their own namespace; however dependences may still exist. . . . . . . . . 60

  • viii DRDC-RDDC-2018-D166

    Acknowledgements

    I would like to express my great appreciation to my supervisor, Dr. Anna Crawford, for her valuable and constructive suggestions and valuable guidance during the planning and development of this project.

    I also wish to thank Wayne Renaud, staff of Canadian Hydrographic Service, for his help collecting the necessary bathymetry data for this project.

    I would also like to thank the staff of the following organizations for their help in offering me resources throughout this term:

    • Defence Research and Development Canada (DRDC) – Atlantic Research Centre.

    • Canadian Hydrographic Service.

    • Royal Canadian Navy Route Survey Office.

    • Dalhousie University, Department of Oceanography.

    Note from Dr. Crawford: The document has been edited for clarity, addressing some very helpful comments from an internal DRDC reviewer, and formatted with the DRDC document template. As a Reference Document, the report appears largely as written by Mr. MacDonald, fulfilling the work term requirements of his academic department.

  • DRDC-RDDC-2018-D166 1

    1 Introduction

    1.1 Background

    The process of seafloor change detection involves the comparison of high-resolution historical sidescan sonar imagery to recently collected sidescan sonar imagery with the intention of identifying newly placed objects. Historical sidescan sonar imagery refers to imagery that has been collected in the past, but not so long ago that there are minimal changes to the background seabed, with the exception of newly placed objects. This approach allows for the formation of a database containing historical objects and the ability to detect the appearance of recent objects. Ultimately, the goal of change detection is to identify potentially harmful objects such as mines or other improvised explosive devices. Thus, change detection can be a valuable tool for Mine Countermeasures (MCM) in the attempt to protect national security. Harbours and ports with high volumes of traffic typically contain large quantities of debris that can often resemble potential threats; change detection reduces repeat false alarms provoked by these objects. Change detection can be particularly effective in cluttered areas. In the seabed imagery, this is performed by identifying groups of pixels that are of significantly different composition than previous images using image processing and algorithms (Gendron et al., 2009). The differences in the pixel group represent new objects, motion of pre-existing objects or less satisfactory conditions such as sensor motion, noise or environmentally induced seafloor changes.

    Seabed survey for MCM is most commonly performed using sidescan sonar. Figure 1 shows examples of sidescan sonar imagery of seabed before (A) and after (B) placement of an object, circled in red. A sidescan sonar transmits and receives acoustic energy (pings) under water as it travels along a survey path to map out an area. The received echo signals are processed to produce imagery of the sea floor which can be further analysed using image processing and other techniques to detect objects (Sternlicht et al., 2009).

    Figure 1: Two sonar images, image (A) referring to historical data and image (B) referring to recent data. The red circle encloses a recently placed object; image processing recognizes the change in pixels

    and provokes a change detection alarm.

    Morphology is the study of changes in seabed elevation at a given location over a time frame as a result of sediment transport and erosion. The morphodynamics, which is the cycle induced by the interaction and motion of sediments, can have a significant impact on the effectiveness of change detection (Daly, 2009). Locations on the seafloor which experience strong levels of sediment transport have a potential of creating false alarms in the change detection process due to the rapid changes induced in the morphology and in the texture of the seafloor. The sonar survey will produce differences in imagery in

    A B

  • 2 DRDC-RDDC-2018-D166

    areas where there are high quantities of sediment deposition or transport gradient changes. The re-orientation of ripples on the seafloor can induce a sufficient imagery difference to render the change detection process of little value. Thus, the study and modelling of morphodynamics becomes a crucial concept in change detection. The driving force for morphological changes is generally waves and currents. Morphodynamic computational modelling has provided a method to help predict the behavior of natural systems. Using a morphodynamic model will provide insight into areas at risk to morphological change.

    1.2 Problem Statement

    Despite the fact that change detection is a technique employed by the Royal Canadian Navy (RCN) in dealing with clearance of home routes, there is no doctrine in place specifying the requirements for the time interval between resurveys of an area. The frequency at which side-scan sonar surveys should occur will strongly depend on the seabed activity. If sufficient amount of time elapses between repeat surveys in places where the seabed is subject to changes in morphology, the seabed imagery will deviate from the earlier survey causing false alarms in the change detection process. Thus, knowledge of the time scale of changes in the seabed due to environmental factors is required to accurately estimate the frequency of repeat surveys.

    1.3 Objectives

    The objective of this project is to investigate the suitability of a morphodynamic model, XBeach, for use in developing a method for estimating a time scale of seabed change in a designated location. Consideration is to be given for environmental factors that will be related to areas of high seafloor activity (seabed composition, topography, tidal and wave conditions). Ultimately, the model results would provide information to be integrated into survey planning tools for optimizing the schedule for repeat seabed surveys in areas that are relevant to defence and security where change detection is the used for seabed object identification. Sufficiently recent historical data will aid in mitigating any false alarms that would otherwise be caused by seabed change due to environmental factors. This should increase the effectiveness of change detection. This will also provide scientific background in the processes responsible for sediment transport and morphological change through use of the morphodynamic model XBeach.

    1.4 Outline

    The XBeach modelling program and structure will be briefly analyzed to determine the practicality of using the model for determining the potential of morphological changes. This will present the capabilities of the modelling program. This includes particular interest in modelling concepts for morphology, sediment transport and bed update. There will then be a description for the generation of the XBeach structure using the MATLAB toolbox and local conditions. The results will be reviewed in the final section including comments and recommendations concerning the practicality of using XBeach for planning of repeat sonar surveys for the purpose of change detection. Following the body of the report will be there is a set of appendices containing relevant information to the project and XBeach model (i.e., parameters, inputs, local conditions, etc.).

  • DRDC-RDDC-2018-D166 3

    2 XBeach Modelling Binary

    XBeach, representing eXtreme beach behaviour, is a two-dimensional numerical model used to assess the natural coastal response during time-varying storm and hurricane conditions. This includes computation for wave propagation, long waves and mean flow, sediment transport, morphological and bed update changes where the seabed is affected by wave and current action. The formulations are based on decades of hydrodynamic, morphodynamic and sediment transport modelling and research. The model has been shown to be effective in the analysis of swash dynamics, avalanching and 2D horizontal effects. The ability of the model to represent natural processes including avalanching, and offshore transport allows XBeach to be considered as a tool for analyzing the time scale of seabed change. The open-source model has been validated through various analytical, laboratory and case studies.

    The model contains a time-dependent wave action balance solver for wave refraction and variation of wave action in x, y, and time. This calculates the wave refraction and takes into account directional spreading. This also allows for the simulation of wave propagation and energy dissipation of the wave groups. The Generalized Lagrangean Mean (GLM) approach is implemented to determine the depth-averaged flow velocities. These velocities are then translated to Eulerian flows which allow for the inclusion of undertow effects, bed shear stresses and sediment transport (de Abreu, 2010). Eulerian flow simply refers to the point of reference in which the fluid motion is based on a specific location in space as time passes (i.e., standing on a riverbank and watching the water pass). XBeach is also able to include the impact of low frequency waves, commonly known as infragravity waves. The availability of bed shear stresses and sediment transport mechanics provide a unique possibility of obtaining more insight on the morphological behaviors of the seafloor.

    The XBeach model domain is defined on a rectilinear grid which is defined as either a grid relative to a known origin or as a grid in a metre-based coordinate system. This grid uses x and y coordinates, corresponding to an elevation or bathymetry, that have been specified in separate ASCII files. For the purposes of this project, only the bathymetry (underwater domain) is used. The x-axis is orientated approximately perpendicular to the shoreline and the y-axis is orientated approximately alongshore. The x and y grid size can be variable but must remain rectilinear. The axis orientation of the XBeach model can be seen in Figure 2. This applies a staggered grid where the bed levels, water levels, water depths and concentrations are defined in cell centers and sediment transport and velocities are defined at cell interfaces. The u-velocity defines velocity in the x direction and the v-velocity defines velocity in the y direction. Velocities at the u- and v-points are denoted by uu and vv respectively. The u-velocity at the v-grid point and v-velocity at the u-grid point are defined as uv and vu respectively and are obtained byinterpolation of surrounding grid points. Velocities u and v at the cell centers are obtained byinterpolation and are for output purpose only. This staggered grid can be seen in Figure 2 (Daly, 2009).XBeach has also included an option to use a “hard” or non-erodible layer which essentially provides anadditional armoured layer over the bathymetry during the computation process. Once XBeach reaches thedepth of the hard-layer it will not erode any further.

  • 4 DRDC-RDDC-2018-D166

    Figure 2: XBeach coordinate system (A) and staggered grid (B). The coordinate system is defined relative to world coordinates (xw, yw) through the origin (xori, yori,) and counter-clockwise orientation

    (alfa) defined with respect to the xw-axis (Daly, 2009).

    The XBeach modelling system uses four modelling modules to simulate near-shore processes. The two hydrodynamic modules consist of the short wave module and the flow module while the two morphodynamic modules consist of the morphology module and the sediment transport module. The modules each process boundary conditions and provide data outputs for analysis or for use in a companion module. For example, the wave and current outputs produced from the wave module are used in the sediment transport module. The morphology module includes analysis for bottom evolution, avalanching and bed level update (which are strongly influenced by the sediment transport module outputs). The module interactions can be seen in Figure 3 (Daly, 2009). The wave and flow boundary conditions are only used to produce the initial set of outputs. These initial and proceeding outputs then cycle through the modules to continue the computation process. The outputs can also be visualized to determine the results of the simulation once the stop time has been reached. The sediment transport and morphological bed updating components of the model are providing the outputs which are of interest to this project.

    A B

  • DRDC-RDDC-2018-D166 5

    Figure 3: Simulation modules within XBeach. The arrows on the image represent the outputs and connectivity between the modules and italics show module outputs. Boundary conditions are only used on

    the first cycle of calculations (Daly, 2009).

    To execute a XBeach simulation, the user creates a “.txt” file which declares all known variables and input files to be used within the simulation. This main txt file must be named “params.txt”, and it contains grid and bathymetry information, wave inputs, flow inputs, and morphological inputs. These inputs are inserted into the “params.txt” file using “keyword = value” combinations where the keyword is the variable name and the value specifies the method in which XBeach will interpret that value. See 0 for all “params.txt” inputs. Most of the variables have default values which will be used by the model unless another value is specified in the text file. Several variables declare the filename of other files, within the directory, that contain information such as tide time series and wave inputs. Once the XBeach executable is initialized the executable will read the “params.txt” file within the current directory and interpret the “keyword = value” combinations contained within the file. The executable will also begin to read any declared input filenames. The executable will immediately begin to produce output files based on the global variable outputs that were specifieed in “params.txt”. These output files are the results that are used for visualization and analysis of the simulation.

    A MATLAB toolbox has been built to set up and run XBeach models (Hoonhout, 2010). This toolbox facilitates the model set up process by using wave, tide, bathymetry and “params.txt” inputs to create the XBeach structure. The toolbox also comes equipped with the scripts required to read and write XBeach input files and read XBeach output files based on the XBeach structure created by the user. Ultimately, this means that MATLAB will generate the “params.txt” file and all files referred in it such as grid and wave definition files. The visualization and analysis scripts can then be used once the read and write scripts have been used to gather the data. This facilitates the process of plotting and analyzing the results generated by XBeach. This toolbox essentially allows the user to perform a full XBeach simulation using the computational and data display powers of MATLAB.

  • 6 DRDC-RDDC-2018-D166

    3 Methods

    The purpose of this section is to act as a guide for generating an XBeach model structure and simulation using the XBeach MATLAB toolbox. This includes creating input files, using functions and declaring variables. It is also important to note that the XBeach executable and netcdf.dll file be within the same directory as the file inputs and desired output location. MATLAB will overwrite any previous simulations in the current directory and therefore it is recommended to create individual directory folders containing the model executable for each simulation. In some cases, it is easier to alter a pre-existing simulation by editing the “params.txt” file rather than recreating the simulation from scratch. There are memory management issues regarding inputs, primarily bathymetry, and output files that should be addressed prior to commencing the simulations. Inputs need to be properly formatted for them to be correctly interpreted. If the set of output files is allowed to grow larger than about 5 GB, this becomes too large for MATLAB to display effectively. This can be avoided using shorter simulation durations or larger time steps.

    3.1 Using MATLAB

    MATLAB, representing MATrix LABoratory, is a multi-paradigm numerical computing program with a fourth generation language for matrix manipulation, algorithm implementation, symbolic analysis and program interfacing. The majority of the XBeach toolbox functions can be used with a fairly elementary understanding of the MATLAB program language. It is required that the XBeach toolbox be included in the MATLAB search path to ensure that all the XBeach functions are accessable. A description is included with all XBeach functions that can be obtained by using the MATLAB help command and the name of the function. Important XBeach functions will be included in Annex D.

    3.2 Generating The Model

    The XBeach structure is generated and stored in a variable by using the “xb_generate_model” function which calls and combines the results of several other functions. This “xb_generate_model” function contains the “xb_generate_bathy” function, the “xb_generate_tides” function, the “xb_generate_waves” function and the “xb_generate_settings” function. These inner functions are used to define the bathymetry (“bathy”), tide conditions (“tide”), wave conditions (“waves”), and general model settings (“settings”) respectively. This model generating function is used to facilitate the formation of an XBeach model structure by placing all of the model information into a single MATLAB variable. This variable can then be used to write the model directly to the disk using the writing commands, which are explained in Section 3.6. The “xb_generate_model” function is an essential function in successfully creating an XBeach model.

    However, it should be noted that the functions contained within the “xb_generate_model” command can be used individually and then combined using the “xb_join” command, though this is not the simplest method. All of the XBeach generate functions return a section of the XBeach structure containing information for the formation of the “params.txt” file. These different sections can be created and stored within individual variables. The different structures are then combined by using the “xb_join” function. This method is processed in the same manner as using the “xb_generate_model” function; however the user must manually combine all the pieces for the full XBeach structure. The process sends several

  • DRDC-RDDC-2018-D166 7

    variables to the function, which is built to adjust the parameters written to “params.txt” to match the structure created by the variables (i.e., assigning non erodible layer computation, sediment transport, or grid).

    A final method, though also not recommended, is using the original default model and then extending the model structure by using the “xb_set” function. This is performed by initiating the “xb_generate_model” function to create the “default” tutorial model. Each variable in the tutorial model, that should be otherwise defined, is then changed to the desired value by using the “xb_set” function. This method requires a deeper understanding of the XBeach executable interaction with the “params.txt” file. This is because the default tutorial structure may not write sufficient information to the “params.txt” file. For example, the default model excludes groundwater therefore setting groundwater variables with “xb_set” may produce incompatibilities within the “params.txt” file.

    3.3 Generating The Bathymetry Input

    The bathymetry section of the model is created by assigning values to variables within the “xb_generate_bathy” function. This is used to create a model bathymetry in one or two dimensions based on bathymetry data. This bathymetry can be inserted in the form of a grid relative to a known origin or as a grid in a metre-based coordinate system (i.e., UTM). This will effectively provide longitude (X values), latitude (Y values) and depth (Z values). The bathymetry function has a number of embedded variables that must be assigned in order to produce a unique simulation.

    The “x”, “y” and “z” variables define the x-coordinates, y-coordinates and z-coordinates of bathymetry. These values must be loaded into MATLAB and assigned their own variables. They can be easily loaded from a text file, Excel file or MATLAB file and then inserted into the “xb_generate_model” function. The method for assigning values to the variables in the function can be seen on the example script in Figure 4. Other important variables include “posdwn”, “optimize” and “world_coordinates”. “posdwn” is a Boolean flag that declares whether the z direction is positive upwards or positive downwards. This “posdwn” variable can be assigned “true” for positive up and “false” for positive down. The “optimize” value is another Boolean used to enable a process which optimizes the bathymetry grid. This will interpret the original input bathymetry and regrid and rotate to match the model domain resolution, check the boundaries, and check for holes and fill them if necessary. This can be turned on or off by assigning the value “true” or “false” respectively; the default value is defined as “true” for optimization enabled. Finally, the third Boolean is the “world_coordinates” variable which is used to enable a grid defined in world coordinates rather than XBeach model coordinates by assigning the values “true” or “false” respectively. There are several other advanced variables for gridding, cropping and rotating however these variables were not required for the purposes of this project. Ultimately, the result of this function is an XBeach input structure with three matrices of equal size containing a rectilinear grid in x, y and z coordinates.

  • 8 DRDC-RDDC-2018-D166

    Figure 4: MATLAB model generating script. This script represents the method for assigning values to the variables contained within the function. This will store the XBeach structure in the variable “xbm”.

    One final important variable is “ne” which is used to define a non-erodible grid layer. This variable specifies the thickness of the sand layer above the hard (rock) layer and is therefore essentially the sediment thickness. This variable must be the same size as the gridded bathymetry file. The thickness is relative to the initial bed level and a value of 0 would represent non-erodible material at the surface, i.e. no change in seabed elevation can occur. This allows you to insert zeroes on the location of structuresand larger values to represent areas of sand which are free to erode. For example, if a value of 0.5 isspecified then there will be 50 cm of sediment above the non-erodible structure at the specified locationof the bathymetry grid.

    3.4 Generating Tide and Wave Inputs

    The tide section of the XBeach model can be set up using two methods, both of which can be straight forward. The tide conditions for input can be represented by an equal tidal surge at all boundaries. This will create a uniform water level across the grid. Alternatively, tide can be specified using one, two or four time-varying nodes set at the boundaries of the domain, e.g. at the offshore and beach edges, to more accurately model more complicated tides.

    The first method of input is to manually create a tide file using Notepad or another similar software application. This file must follow a format where the first column is time and subsequent columns contain water level signals, one column for each tide node. The length of the simulation time must start (“tstart”) and stop (“tstop”) on a time interval. For example, if the tide data is hourly then the start and stop time can be 3600 and 18 000 seconds respectively but not 1200 and 4600 seconds. The tide data file name (e.g., “tide.txt”) is specified in the “params.txt” file and is placed in the model directory either manually or by using the MATLAB “copyfile” command. The number of tide nodes (“tideloc”) must also be defined using the settings function; “tidloc = 1” will define uniform tides. The XBeach executable can be initialized once the inputs have been written and the user created tide file has been copied into the directory.

    The second method is to use the XBeach MATLAB toolbox to define the time and water levels using the variables embedded in the “xb_generate_tide” function. There are three variables that can be used to specify tide conditions; “time”, “front” and “back”. The variable “time” is an array of start times of tide period in seconds, “front” is an array of water levels at the seaward model border and “back” is an array of water levels at the landward model border.

  • DRDC-RDDC-2018-D166 9

    The wave boundaries and conditions can be defined by assigning values to the variables contained within the “xb_generate_waves” function. MATLAB will compute the wave conditions using either Joint North Sea Wave Project (“JONSWAP”) or Variance Density (“Vardens”) wave spectra, depending on which variables have been assigned, and create a file containing the wave boundary conditions. The “bcfile” variable in the “params.txt” specifies the wave boundary condition file that contains the information for the spectral computations. The XBeach executable is able to compute wave boundary condition types other than JONSWAP and Vardens; however this must be done manually outside of the MATLAB toolbox.

    A JONSWAP spectrum is an empirically determined spectrum that defines a distribution of surface ocean wave energy with frequency. This is defined for XBeach by assigning the values for significant wave height (“Hm0”), peak wave period (“Tp”), and main wave direction (“mainang”). There are three remaining variables that are often left to default and these are peak-enhancement factor (“gammajsp”), power in cosinus wave spreading (“s”) and Nyquist frequency (“fnyq”). This provides MATLAB with the information to generate the waves and write to the “bcfile”. When waves are defined using the JONSWAP spectrum, this file is structured similarly to the “params.txt” file as the variables above (“Tp”, “Hm0”, etc.) are defined using “keyword = value” expressions.

    The Vardens method for specifying waves requires only an array of frequencies (“freqs”), an array of directions (“dir”), and a matrix matching the sizes of “dir” and “freqs” containing variance densities. This provides MATLAB with the information required to write a different “bcfile”. The first line is the number of frequencies (integer) followed by a column list of that number of frequency values (hertz). This is followed by the number of angles (integer) and that number of angle values in degrees. Lastly is the matrix of wave variance densities. The angles must be in the calculation coordinate system of XBeach and they must be in an increasing order. An example of a formatted variable density file can be seen in Figure E.1 in Annex E.

    Finally, there are a number of wave boundary condition types that can be manually set up outside of the MATLAB toolbox by specifying the “instat” variable. XBeach has embedded in it the Simulating WAves Nearshore (SWAN) model (The SWAN Team, 2006) and can read standard SWAN 2D variance density or energy density output files (.sp2 files). This is done by defining “instat = 5” and “bcfile = ” in the “params.txt” file. An example of the SWAN text file format can be seen in Figure E.2 in Annex E. XBeach can also use pre-existing boundary conditions files from a previous simulation by defining “instat = 7”. The user must copy the “.bcf” files from the previous simulation when reusing boundary conditions. The calculation grid should also remain the same between simulations when using this method. XBeach can also perform computations for a non-hydrostatic model and for no wave action by using “instat” values of 8 and 9 respectively. Finally, time-varying spectra and location varying spectra can also be used by creating several input data files and specifying the duration and world coordinates. To create a time varying spectra the first line of the “bcfile” must be “FILELIST” to specify time varying file input. The following lines must contain the duration of wave spectrum (seconds), the required time step in this boundary condition file (seconds) and the name of the input data file used to generate boundary conditions. The location varying spectra is created in a similar method. The first line of the “bcfile” must contain “LOCLIST”. The following lines must contain the world x-coordinate, the world y-coordinate and lastly the name of the file containing the spectral wave information. Table 1 contains all of the options and descriptions for defining the variable “instat”.

  • 10 DRDC-RDDC-2018-D166

    Table 1: Table of values used to define wave boundaries with the variable “instat”; values of 4 and 6 are the only scenarios that can be produced using the MATLAB toolbox.

    Instat Value Abbreviated Name Description

    0 stat Stationary wave boundary conditions (sea state) 1 bichrom Bichromatic (two wave component) waves 2 ts_1 First-order time series of waves (generated outside of XBeach) 3 ts_2 Second-order time series of waves (generated outside of XBeach) 4 jons Wave groups generated using a parametric (JONSWAP) spectrum 5 sawn Wave groups generated using a SAWN 2D output file 6 vardens Wave groups generated using a formatted file 7 reuse Reuse of wave conditions 8 nonh Boundary conditions for non-hydrostatic option 9 off No wave boundary condition

    40 stat_table A sequence of stationary conditions (sea state) 41 jons_table A sequence of time-varying wave groups

    3.5 Additional Settings

    The general settings section of the model is set up by assigning values to the variables within the “xb_generate_settings” function to define every other parameter that has not been defined previously. This function is used to declare additional features such as including and excluding physical processes, start and end time of simulations and sediment sizes by assigning name/value pairs to the parameters in the “params.txt” file.

    It should be noted that care must be taken to avoid declaring variables that have already been created or are used within other XBeach generating functions. This is to avoid creating incompatibilities within the “params.txt” file. For example, “zs0file” should not be declared with the settings function unless the “tide.txt” file has been manually created outside of the tide generating function. This is because the tide function will attempt to attach a value to “zs0file” as a result of using the function.

    3.6 Reading and Writing Files

    Reading and writing of input and output files is one of the most important uses of the MATLAB toolbox as a large portion of the files created through the simulation process are unable to be read without the aid of software. These functions significantly reduce the time required and the potential for errors if manually creating the required input text files. These functions will also allow previously created input and output data files to be easily loaded into MATLAB. The three major functions involved with the reading and writing process are “xb_run”, “xb_read” and “xb_write”.

  • DRDC-RDDC-2018-D166 11

    The “xb_write_input” function is used to write the XBeach structure into a parameter file (“params.txt”). The function will write all associated files that are necessary for executing an XBeach simulation from the structures created using the “xb_generate_model” function. This will allow for the XBeach executable to be initialized to begin producing outputs, assuming that the XBeach variables in the structure have been set up correctly.

    The “xb_run” function will also write the required files for the executable; however this can cause network issues if not performed properly. The default behaviour of the “xb_run” function is to write the XBeach structure to the disk, and then attempt to retrieve an updated XBeach executable file, and run it at the desired location. There will be errors if the function attempts to retrieve the updated executable file using a system with network security constraints, such as at DRDC – Atlantic Research Centre. For this reason, it is recommended that the function be used with assigned values for the variables “binary” and “path” within the “xb_run” function. This will command MATLAB to run the non-default XBeach executable/binary located at the specified path and skip the step that causes the function to download an updated XBeach executable file. This function can also be used to run an XBeach simulation remotely.

    Finally, the “xb_read” functions can be used to load all of the associated XBeach files into MATLAB, most importantly, the output files created by running the XBeach executable. Files are read using their specific file reading function (i.e., “xb_read_output”, “xb_read_input”, “xb_read_bathy”, etc.). The list of MATLAB functions included in Annex D can be used to determine the proper reading function for the required task. Reading the files will place the file structure into a MATLAB variable, this variable can then be used to visualize functions or altered using the computational abilities of MATLAB itself. It is recommended that the “xb_read_output” function be used with only a few data files at a time, especially if these data files are large due to memory management issues that can occur in MATLAB. Some of the reading functions require variables and path to be assigned in order to gather the data. For example, to gather the input data the following command must be used: “xb_read_input(“params.txt”)”. This tells the function to read the “params.txt” file and all files referred to within the “params.txt” file.

    3.7 Visualization Tools

    There are a number of tools available to the user for visualizing the outputs created by XBeach. These visualizations can be created by using the “xb_plot” and the “xb_view” functions. These functions can create many different styles of plots depending on the information provided. One form of plot display is a cross-shore profile view, with the model output also provided as a matrix variable with the x-axis in the first column and the data axis in the second column. For some types of output data, it is required to use the “xb_get” functions prior to using the “xb_plot” functions to gather the specific information based on the function, for example, the function “xb_get_morpho” should be used prior to using “xb_plot_morpho”. This will ensure that all the required information for the morphology plot is loaded into the variable used by the “xb_get_morpho” function. Plots that provide useful information for this project are the hydrodynamic and sediment transport plots; however there are a number of other plots that can be created. Examples of sediment transport and hydrodynamic plots can be seen in Figure 5 and Figure 6 respectively.

    The “xb_view” function is used to visualize the data stored in the variables that have been created using the “xb_read_output” function. The view function uses a graphical user interface created for displaying the data outputs created by XBeach. This graphical user interface has a number of useful built in tools, such as for visualizing multiple outputs at the same time and perspective views of the three-dimensional model domain. While the visualization tools are extremely useful in providing a convenient way of

  • 12 DRDC-RDDC-2018-D166

    reading and viewing the formatted model run output files, it has a very serious deficiency. It does not manage memory well within MATLAB so that for longer model runs with many outputs, loading the data from the output files can take extended periods of time (10’s of minutes) and once loaded, the graphics display on the more complicated plots can take additional time to render (10’s of minutes again).

    Figure 5: Sediment concentration plots created using the “xb_plot_sedtrans” function contained in the MATLAB toolbox. This represents concentration, turbulence and sediment transport due to morphology

    and hydrodynamic conditions. The x-axis represents horizontal distance across the model domain transformed to world coordinates, metres in a UTM projection.

  • DRDC-RDDC-2018-D166 13

    Figure 6: Hydrodynamic plots created using the “xb_plot_hydro” function contained in the MATLAB toolbox. This represents the wave height of both high and low frequency waves and the flow velocities.

    The x-axis represents horizontal distance across the model domain, similar to the previous Figure.

    4.48 4.485 4.49 4.495

    x 105

    -80

    -60

    -40

    -20

    0

    20wave heights and water levels

    heig

    ht [m

    ]

    distance [m]

    bathymetry (initial)bathymetry (final)wave height (HF)wave height (LF)wave heightsetup

    4.48 4.485 4.49 4.495

    x 105

    -0.6

    -0.4

    -0.2

    0

    0.2

    0.4flow velocities

    velo

    city

    [m/s

    ]

    distance [m]

    flow velocity (RMS,HF)flow velocity (RMS,LF)flow velocity (RMS)flow velocity (u,mean)flow velocity (v,mean)

  • 14 DRDC-RDDC-2018-D166

    4 Simulation and Results

    4.1 Simulation Locations

    This work was done in support of the Battlespace Characterization element of the Naval Mine Countermeasures project at DRDC – Atlantic Research Centre. As part of that project, work is underway on development of concepts for optimization of change detection analysis of seabed survey imagery. Three locations in Halifax Harbour have been chosen as test sites for monitoring which are intended to represent three cases: 1) little change to the seabed over time in Bedford Basin, 2) moderate change due to tide and weather driven currents, with vessel traffic, near Georges Island, and 3) moderate change due to being exposed to ocean waves during storm events, off Herring Cove. These locations are shown in Figure 7, Figure 8 and Figure 9 (the chart images were generated using Global Mapper v15.1). The sets of black parallel lines in each image show the route of sidescan sonar surveys; with endpoint coordinates listed in Table 2. These are surveys that are being carried out by the RCN Route Survey Office (RSO) during their training exercises.

    Herring Cove is the main location used in the XBeach testing due to the availability of data resources and the less complicated geography for creation of a suitable model domain. Environment Canada maintains wave buoys and tidal stations outside of Halifax Harbor in the vicinity of Herring Cove. There is another wave buoy operated by the Halifax Marine Research Institute as part of the SmartAtlantic Alliance, which provides meteorological and wave data, available online. This provides accurate data for wave boundary conditions and tidal time series simulations. Finally, the Herring Cove geography is favorable for successful XBeach simulations, including clearly defined coastlines, both erodible and non-erodible seafloor types and exposure to ocean elements (as opposed to Bedford Basin).

  • DRDC-RDDC-2018-D166 15

    Figure 7: Bedford Basin chart and survey lines represented using Global Mapper, a geographic information system software package. The bounding box for the XBeach domain is shown

    by the tilted rectangle.

    Figure 8: Ives Knoll chart, survey lines and XBeach domain box The yellow box shows the area covered by an inset chart not included.

  • 16 DRDC-RDDC-2018-D166

    Figure 9: Herring Cove chart, survey lines and XBeach domain box.

    Table 2: Table of coordinates of the start and end points of the survey lines at Herring Cove, Ives Knoll and Bedford Basin. Information was supplied by RCN RSO.

    End Points of Survey Lines Herring Cove Ives Knoll Bedford Basin

    LONGITUDE LATITUDE LONGITUDE LATITUDE LONGITUDE LATITUDE -63.52497807 44.56667318 -63.54314177 44.63333581 -63.61893721 44.68716022-63.52497807 44.55767988 -63.55416501 44.62884655 -63.61603085 44.6802543

    -63.5254816 44.56667318 -63.54339149 44.6336485 -63.61942047 44.68705671-63.52548152 44.55767988 -63.55441476 44.62915922 -63.61651406 44.6801508 -63.52718102 44.56667316 -63.5442343 44.63470383 -63.62105145 44.68670733-63.52718068 44.55767986 -63.55525771 44.63021446 -63.61814487 44.67980146-63.52938397 44.5666731 -63.54532687 44.63607183 -63.62316567 44.68625439-63.52938329 44.5576798 -63.55635045 44.63158236 -63.62025885 44.67934857-63.53158692 44.56667299 -63.5464195 44.63743982 -63.62527985 44.68580141-63.53158591 44.55767969 -63.55744325 44.63295025 -63.6223728 44.67889565-63.53378987 44.56667284 -63.54751217 44.6388078 -63.62153471 44.6866038 -63.53378852 44.55767954 -63.55853611 44.63431813 -63.61862807 44.67969794-63.53599283 44.56667265 -63.5486049 44.64017577 -63.62364891 44.68615086-63.53599113 44.55767935 -63.55962901 44.63568599 -63.62074204 44.67924505-63.53819578 44.56667242 -63.54448402 44.63501651 -63.62576308 44.68569787-63.53819374 44.55767912 -63.55550747 44.63052713 -63.62285598 44.67879212-63.52768455 44.56667315 -63.54557661 44.63638452-63.52768413 44.55767985 -63.55660023 44.63189502

  • DRDC-RDDC-2018-D166 17

    End Points of Survey Lines Herring Cove Ives Knoll Bedford Basin

    LONGITUDE LATITUDE LONGITUDE LATITUDE LONGITUDE LATITUDE -63.5298875 44.56667308 -63.54666925 44.6377525

    -63.52988675 44.55767978 -63.55769304 44.63326291-63.53209046 44.56667296 -63.54776193 44.63912048-63.53208936 44.55767966 -63.55878591 44.63463078-63.53429341 44.5666728 -63.54885467 44.64048845-63.53429197 44.5576795 -63.55987882 44.63599865-63.53649636 44.5666726 -63.53649458 44.5576793 -63.53869931 44.56667236

    -63.5386972 44.55767906

    Model domains were set up for all three areas, but it was found that the more complicated inner harbour geometries were not suitable for the model, for example, wave directions and shorelines were not well defined. The Ives Knoll location has a particularly ambiguous coastline. It can be seen in Figure 8 that there is a coastline on both sides of the survey location. XBeach simulations showed unrealistic results with erosion around Georges Island. XBeach has difficulty performing accurately in areas that contain ambiguous coastlines or that do not have typical wave direction conditions.

    4.2 Herring Cove Model Domain

    Bathymetric data for the Herring Cove model domain was provided by Canadian Hydrographic Services (CHS). The original bathymetry from CHS is shown in Figure 10 and a three-dimensional view of the XBeach regridded bathymetry is shown in Figure 11. The raw data set contained over 7 million data points at two metres spacing prior to decimating and was too large for the MATLAB toolbox to manipulate. The data set was decimated to reduce the file size by reducing the resolution to a point spacing of 20 metres, with 20 thousand points. XBeach requires that the coastline be placed on the right side of the grid and therefore the grid was also rotated during the resolution decimation. The XBeach “optimization” input option was turned off since the input bathymetry was already appropriately gridded and rotated. The bathymetry that forms the lower boundary of the model domain primarily affects the behaviour of the waves part of the model (SWAN). A detailed examination of the model requirements on resolution of the input bathymetry is outside the scope of this work—the practical limitation on memory within MATLAB was the main concern.

  • 18 DRDC-RDDC-2018-D166

    Figure 10: Herring Cove bathymetry plotted by uploading bathymetric data points into Global Mapper (v15.1). Bathymetric data was provided by Canadian Hydrographic Services. Colour-scaled depths range

    from 37 m (blue) to the shoreline (0 m, red). The shoal in the center of the image is 5 m depth at the shallowest.

    Figure 11: Herring Cove bathymetry decimated and rotated to model coordinates, plotted using MATLAB XBeach display tools.

  • DRDC-RDDC-2018-D166 19

    A non-erodible layer was included in the simulation. This non-erodible layer was created by designating all grid data points with a depth greater than 20 metres to have 25 metres of sediment, and shallower depths, 0 m of sediment. This sediment was set at a D50 value of 88 μm and a D90 value of 100 μm (50% of the sediment is finer than 88 μm diameter and 90% of the sediment is finer than 100 μm). This is intended to model the rocky (non-erodable) shoal surrounded by sand off Herring Cove. Figure 12 shows a portion of Figure 21 of the Surficial Geology of Halifax Harbour (Fader and Miller, 2008) that shows the shoal as a pink area labeled as “Acoustic Basement”, or bedrock. Figure 13 shows the depth of the top of the non-erodable layer, i.e. the bathymetry minus the thickness of the layer. The sediment analysis for the Herring Cove location, also from Fader and Miller (2008), showns three different types of sediment. There is Sable Island Sand and Gravel which contains well sorted medium and fine grained sand mixed with various shell types. The sand in the Herring cove area also contains a silt component. There is gravel which is well sorted and ranges from rounded to sub rounded. This occurs around the bedrock outcrops and generally has a size range from pebbles to boulders. Finally the Acoustic Basement is areas of exposed bedrock. The D50 and D90 values were estimated using the grain size scale where very fine sand is 62–125 μm and coarse silt is 31 to 62 μm (Fader and Miller, 2008).

    Figure 12: Surficial geology of Herring Cove, where label“1” is “Acoustic Basement” (bedrock), “6” is Gravel and “7”is Sable Island Sand and Gravel (Fader and Miller, 2008, Figure 21).

  • 20 DRDC-RDDC-2018-D166

    Figure 13: Depth of the top of the non-erodible layer in the Herring Cove model domain, created using XBeach and MATLAB.

    4.3 Wave and Tides Inputs

    The wave and tide inputs were created using data obtained from Environment Canada. The tide time series was input as one time-varying water level signal (uniform tide) by setting “tideloc = 1”. This adds an additional depth to the total water depth based on the tide time series. JONSWAP wave conditions were used by setting a wave height of four metres and a period of 11 seconds. This was used to simulate storm wave conditions. Several wave trials were performed to test the interpretation of the wave incidence direction value used by the model. An example of exaggerated wave conditions for 245° and 315° can be seen in Figure 14 and Figure 15. Changing the mean wave direction shows a change in the patterns created by the wave velocity. Both simulation snapshots were at a time of 200 seconds to ensure that the only varying condition would be the main wave direction. The velocities seen in the images are the Generalized Lagrangian Mean (GLM) X and Y velocities at the cell center. Similar results were obtained using the Eulerian mean X and Y velocity at cell centers (output variables ue and ve respectively) and Eulerian Mean velocity in X and Y direction (output variables ueu and vev respectively). This varying wave speed was used to ensure that the waves were moving towards the coastline. Results lead to the assumption that the wave grid is relative to the bathymetry grid, such that the wave system is an object contained within the grid system.

  • DRDC-RDDC-2018-D166 21

    Figure 14: Wave velocity simulation created by using the JONSWAP boundary conditions of 11-metre wave height, 4-second peak period and mean wave direction of 245°. Image (A) referring to X-Velocity

    and image (B) referring to Y-velocity create a pattern towards the top right.

    Figure 15: Wave velocity simulation created by using the JONSWAP boundary conditions of 11-metre wave height, 4-second peak period and mean wave direction of 315°. Image (A) referring to X-Velocity

    and image (B) referring to Y-velocity create a pattern towards the bottom right.

    4.4 Sediment Transport Results

    The sediment transport results and simulations were created by analyzing and cross-checking various sediment transport outputs. The first set of plots used were sediment transport integrated over bed load and suspended for all sediment grains in both X and Y directions, these can be seen in Figure 16 and Figure 17 respectively. Sediment concentration integrated over bed load and suspended and for all sediment grains can be seen in Figure 18. Cumulative sedimentation and erosion and rate of change of the bed level visualizations can be seen in Figure 19 and Figure 20 respectively. Analysis of these plots shows that the sediment transport, erosion, deposition and suspended sediment concentrations are all elevated in the same locations. It is important to note that it is not the magnitude that is of interest, it is the location where higher seafloor activity may exist. Cross-checking these results show that the same locations in the bathymetry appear over multiple graphs and therefore represent locations of elevated seafloor activity. The graph representing the rate of change of the bed level is of most interest for seafloor activity. The eastern coastline, the small shoal located in the center and the seaward boundary containing

  • 22 DRDC-RDDC-2018-D166

    deviated bathymetry all show elevated seafloor activity. These simulations do not include the non-erodible layer and therefore it is expected that the actual seafloor activity at the seaward boundary and the shoal would be less then simulated.

    Figure 16: Sediment transport integrated over bed load in the X-direction (Sutot).

  • DRDC-RDDC-2018-D166 23

    Figure 17: Sediment transport integrated over bed load in the Y-direction (Svtot).

    Figure 18: Sediment concentration integrated over bed load in the X-direction (cctot).

  • 24 DRDC-RDDC-2018-D166

    Figure 19: Cumulative sedimentation and erosion (sedero).

  • DRDC-RDDC-2018-D166 25

    Figure 20: Rate of change of bed level (dzbdt). This is the output of most importance due to its ability to represent the overall change in the bathymetry per unit time.

    Several of the graphs have small locations of high or low changes which are represented by the vibrant and sudden color changes. It is still undetermined whether these extreme color changes are practical or if they are simply representing errors in the data output. These same color changes can be observed at the seaward boundaries when performing wave speed analysis on jagged bathymetry sets. There is a possibility that this may be a result of the way simulations are performed at the model boundaries.

  • 26 DRDC-RDDC-2018-D166

    5 Conclusions and Recommendations

    Monitoring the seafloor activity is an important factor in ensuring the optimization of repeat sonar survey operations using change detection for seafloor object identification. The main objective of this project is to examine a method to determine locations that have elevated seafloor activity by using the XBeach software. Using this freely accessible software will also minimize costs by negating the requirement to purchase expensive modelling software. Using the XBeach simulation abilities provides engaging morphological graphs overlapping a coordinate system. The Herring Cove simulations were able to provide sediment transport and bed updating plots based on a reasonably accurate grid spacing of 20 metres. The large quantity of outputs produced by XBeach provides a vast archive of simulations to cross-check for quality control.

    It is recommended that the following actions be performed for optimal performance of the XBeach modelling software:

    • Cross-check XBeach morphological simulations with real sonar data.

    • Identify most accurate sediment properties for simulation locations.

    Identify sediment grain size and composition.

    Test multiple sediment fraction results if applicable.

    • Create an accurate non-erodible layer based on the geology of the location.

    • Perform analysis on multiple outputs for quality control.

    Create sediment transport simulations.

    Create seabed shear stress simulations.

    Analyze hydrodynamic results that provide insight on erosive conditions.

    • Ensure software is updated as XBeach is still actively developed.

    The XBeach model that was investigated in this work was a candidate for providing accurate seabed sediment dynamics as one of the inputs to a larger model for prediction of seabed changeability due to natural influences. The results of the investigation indicate that while the XBeach model is very powerful and provides several useful sediment dynamics outputs, it would be difficult to implement for complicated domain areas such as Halifax Harbour, due to the absence of a straight-coast geometry, which the model requires.

  • DRDC-RDDC-2018-D166 27

    References

    Daly, C. (2009). Low frequency waves in the shoaling and nearshore zone. Master’s Thesis, Civil Engineering, Delft University of Technology.

    de Abreu, C. F. (2010). Morphological behavior of a non-equilibrium coastal profile. Delft University of Technology.

    Fader, G. B., and Miller, R. O. (2008). Surficial geology, Halifax Harbour, Nova Scotia, Bulletin–Geological Survey of Canada, 590.

    Gendron, M., Lohrenz, M., and Dubberley, J. (2009). Automated change detection using synthetic aperture sonar imagery, In: IEEE Oceans 2009, Biloxi, MS, 1–4.

    Hoonhout, B. (2010). XBeach Matlab Toolbox, https://oss.deltares.nl/web/xbeach/tools (Access date: 13 Mars 2019).

    Roelvink, D., Reniers, A., Van Dongeren, A., Van Thiel de Vries, J, Lescinski, J., and McCall, R. (2010). XBeach model description and manual. Unesco-IHE Institute for Water Education, Deltares and Delft University of Tecnhology. Report June, 21, 2010.

    Roelvink, D., Reniers, A., van Dongeren, A. P., van Thiel de Vries, J., McCall, R., and Lescinski, J. (2009). Modelling storm impacts on beaches, dunes and barrier islands. Coastal Engineering, 56 (11), 1133–1152.

    Sternlicht, D. D., Harbaugh, J. K., and Nelson, M. A. (2009). Experiments in coherent change detection for synthetic aperture sonar, In: IEEE Oceans 2009, Biloxi, MS, 1–5.

    The SWAN Team (2006). SWAN user manual SWAN cycle III version 40.51. Delft University of Technology.

    https://oss.deltares.nl/web/xbeach/tools

  • 28 DRDC-RDDC-2018-D166

    Bibliography

    den Bieman, J. (2013). XBeach grid tutorial, https://oss.deltares.nl/web/xbeach/documentation (Access date : 13 March 2019).

    Booij, N., Ris, R.C., and Holthuijsen, L.H. (1999). A third-generation wave model for coastal regions. 1. Model description and validation, Journal of Geophysical Research, 104 (C4), 7649–7666.

    Inman, D. L., and Jenkins, S. A. (2002). Scour and burial of bottom mines: a primer for fleet use. Scripps Institution of Oceanography.

    McCall, R. T., Van Thiel de Vries, J. S. M., Plant, N. G., Van Dongeren, A. R., Roelvink, J. A., Thompson, D. M., and Reniers, A. J. H. M. (2010). Two-dimensional time dependent hurricane overwash and erosion modeling at Santa Rosa Island, Coastal Engineering, 57 (7), 668–683.

    Sasso, R. (2012). Video-based nearshore bathymetry estimation for Rip current forecasting on a macrotidal beach. Master’s Thesis, Civil Engineering, Delft University of Technology, Delft.

    Sugawara, D., Goto, K., and Jaffe, B. E. (2014). Numerical models of tsunami sediment transport—Current understanding and future directions, Marine Geology, 352, 295–320.

    Van Rooijen, A. A. (2011). Modelling sediment transport in the swash zone. Master’s Thesis, Civil Engineering, Delft University of Technology, Delft.

    https://oss.deltares.nl/web/xbeach/documentation

  • DRDC-RDDC-2018-D166 29

    Annex A Input Parameters in PARAMS.TXT (Roelvink et al., 2010)

    Table A.1: Bed composition parameters used to specify details relating to hard layers and sediment classes.

    Bed Composition Parameters Input Description Default Notes ngd Number of sediment

    classes 1 No units. This is used to assign up to

    20 different sediment classes. nd Number of computational

    layers in the bed 3 No units. Used to assign between 3 and

    1000 computational layers. por Porosity 0.4 No units. Used to assign a porosity value

    between 0.3 and 0.5.

    D50 Uniform D50 sediment diameter

    0.0002 Units are in metres. This is used to assign the value at which 50% of the sediment grains are finer than.

    D90 Uniform D90 sediment diameter

    0.0003 Units are in metres. This is used to assign the value at which 90% of the sediment grains are finer than.

    rhos Solid sediment density (no pores)

    2650 Units are kg/m3. This is used to place a density value assuming the sediment is non-porous. Recommended values are between 2400 and 2800.

    dzg1 Thickness of top sediment class layers

    0.1 Units are metres.

    dzg2 Nominal thickness of variable sediment class layers

    0.1 Units are metres.

    dzg3 Thickness of bottom sediment class layers

    0.1 Units are metres.

    sedcal Sediment transport calibration coefficient per grain type

    1 No units. This is an advanced option for altering the factor on sediment transport. Must be assigned a value between 0 and 2.

    ucrcal Critical velocity calibration coefficient per grain type

    1 No units. This is an advanced option for altering the factor on critical velocity for erosion. Must be assigned a value between 0 and 2.

    ne_layer Name of the file containing the depth of the non-erodible structure

    N/A This is the name of a secondary input file that has the same size and structure as the depth file. This file is generally named “nebed.dep”.

  • 30 DRDC-RDDC-2018-D166

    Table A.2: Bed update numerics parameters used to alter the seabed updating computational process. These are advanced options and are not documented in the XBeach manual.

    Bed Update Numerics Parameters Input Variable Description Default Notes frac_dz Relative thickness to split

    time step for the bed updating process

    0.7 No units. This is an advanced tool that has been created following the XBeach Manual.

    nd_var Index layer containing the variable thickness

    2 No units. This is an advanced tool that has been created following the XBeach Manual.

    split Split threshold for the variable sediment layer

    1.01 No units. This is an advanced tool that has been created following the XBeach Manual.

    merge Merge threshold for the variable sediment layer

    0.01 No units. This is an advanced tool that has been created following the XBeach Manual.

    Table A.3: Coriolis force parameters used to alter the Coriolis effect on the simulation. These are advanced options and are not documented in the XBeach manual.

    Coriolis Force Parameters Input Variable Description Default Notes wearth Angular velocity of

    the earth 0.0416670 Units are hour--1. This velocity is later

    transformed into rad/s. This is an advanced tool that has been created following the XBeach manual.

    lat Latitude at model location for determining the Coriolis effect

    0 Units are degrees north. The value must be within -90° and 90°. This is an advanced tool that has been created following the XBeach manual.

    Table A.4: Discharge boundary condition parameters used to specify locations of discharge. These are advanced options and are not documented in the XBeach manual.

    Discharge Boundary Conditions Input Variable Description Default Notes disch_loc_f Discharge locations N/A No units. If this input does not work try

    . This is an advanced tool that has been created following the XBeach manual.

    disch_times Discharge time series file N/A No units. If this input does not work try . This is an advanced tool that has been created following the XBeach manual.

  • DRDC-RDDC-2018-D166 31

    Discharge Boundary Conditions Input Variable Description Default Notes ndischarge Number of discharge

    locations Off by default

    No units. This is an advanced tool that has been created following the XBeach manual.

    ntdischarge Length of discharge time Off by default

    No units. This is an advanced tool that has been created following the XBeach manual.

    beta Breaker slope coefficient in roller model

    0.1 No units. This is an advanced tool that has been created following the XBeach manual.

    Table A.5: Drifters parameters used to perform a simulation of drifters. These are advanced options and are not required for most simulations.

    Drifters Parameters Input Variable Description Default Notes drifterfile Name of the drifter

    input file N/A No units. This text file must be structured

    so that each drifter is associated with four numbers indicating X and Y coordinates of release location, release time retrieval time (s).

    ndrifter Number of drifters 0 No units.

    Table A.6: Flow boundary condition parameters used for switching the method of flow computation at the boundary.

    Flow Boundary Condition Parameters Input Variable Description Default Notes front Parameter switch for the

    seaward boundary condition

    1 (abs_2d) This can be set as any integer from 0 to 4. The value 0 applies “abs1d” for absorbing-generating boundary in 1D. The value 1 applies the “abs2d” for absorbing-generating boundary in 2D. The value 2 applies “wall” for no flux wall. The value 3 applies “wlevel” for water levels from a file. The value 4 applies “nonh_1d” for a nonhydrostatic boundary condition.

    left Switch for left lateral boundary condition

    0 (neumann) This value can be set as 0 or 1 where 0 is Neumann boundary condition and 1 is wall boundary condition.

    right Switch for right lateral boundary condition

    0 (neumann) This value can be set as 0 or 1 where 0 is Neumann boundary condition and 1 is wall boundary condition.

  • 32 DRDC-RDDC-2018-D166

    Flow Boundary Condition Parameters Input Variable Description Default Notes back Switch for the bay side

    boundary condition 1 (abs_2d) This value can be set as any integer from

    0 to 3 inclusively. The value 0 applies “wall”, the value 1 applies “abs1”, the value 2 applies abs2d and the 3 value applies “wlevel” (see “front”).

    ARC Switch for active reflection compensation at seaward boundary

    1 This value can be set as value 0 or 1 where value 0 is turned off and value 1 is turned on. This is an advanced tool.

    order Switch for order of wave steering at seaward boundary

    2 This value can be set as value 1 or2 where value 1 is first order and value 2 is second order. This is an advanced tool.

    carspan Switch for carrier greenspan test/free long wave input

    0 This value can be set as 0 or 1 where 0 is “use cg” and 1 is use “sqrt(gh)” in instat = 3 for c&g tests.

    freewave Switch used for free wave propagation

    0 This value can be set to 0 or 1 where value 0 is “cg” and value 1 is “sqrt(gh)” for instat = 3. This is an advanced tool.

    epsi Weighting factor for steady flow and particle velocity

    0 Marked as obsolete in manual.

    nc No documentation 3 No documentation. tidetype Switch for offshore,

    velocity or instant water level boundary

    velocity This is an advanced tool that has been created following the XBeach manual.

  • DRDC-RDDC-2018-D166 33

    Table A.7: Flow numeric parameters used for placing limiters on methods for calculating flow. These are advanced options and are not required for most simulations.

    Flow Numerics Parameters Input Variable Description Default Notes eps Threshold depth for drying

    and flooding 0.005 Unit are metres. This is a limiter used to

    determine if points are dry or wet. eps_sd No documentation 0.5 No documentation. umin Threshold velocity for

    upwind velocity detection 0 Units are m/s. This is a limiter used to

    avoid unrealistic values for velocity detection and for vmag2 in equilibrium sediment concentration.

    hmin Threshold water depth for concentration and return flow

    0.05 Units are metres. This is used as a limiter to prevent strong return flows or high concentrations.

    secorder Second order corrections to advection/non-linear terms based on McCormack scheme

    0 No units. This an option used for non-hydrostatic conditions. This is an advanced tool.

    oldhu Switch for turning off and on the old hu calculation

    0 No units. This is an advanced tool.

    Table A.8: Flow parameters used for specifying the viscosity and friction factors of an XBeach simulation. These are advanced options and are not required for most simulations.

    Flow Parameters Input Variable Description Default No