COVE: Coastal Vector Evolution Model

The conservation equation for beach sediment expressed in terms of local coordinates states that the change in position of the shoreline \(d\eta\), perpendicular to the local shoreline orientation \(s\) through time \(t\) is a function of the divergence of alongshore sediment flux \(Q_{ls}\):

\(\frac{d\eta}{dt} = f\left(\frac{dQ_{ls}}{ds}\right)\)

The nature of the conservation of mass function is dependent on the geometry of shoreline cells. If we were to use rectilinear cells we would violate mass conservation because the cells would either diverge or converge offshore, depending on the planform curvature of the shoreline (i.e. convex offshore vs concave offshore respectively).

In COVE, coastline cells are not rectilinear, but rather triangular, trapezoidal or polygonal. The change of shoreline position for such cells is calculated by inverting quadratic and cubic equations for the volume of sediment in these cells (see Hurst et al., 2015).

Each coastline node has an orientation calculated as the azimuth angle of a vector connecting the two adjacent nodes. Cell edges seperating adjacent cells have an orientation that is perpendicular to imaginary lines between the node of interest and each adjacent node, and they bisect these lines. The cell is thus defined by the cell width at the shoreline \(W_0\), and two angles describing the difference between the cell orientation and the cell boundary orientations \(\eta_1\) and \(\eta_2\) for the upcoast and downcoast boundaries respectively.

The model builds coastal cells by projecting offshore the cell edges defined above. The procedure is as follows: . A priority queue is built so that cells with the largest value of latexmath:[\eta_1+eta_2] are prioritised. . Starting with the most acute, cell boundaries are projected offshore until…​ .. They intersect, in which case the cell is closed and a new boundary for adjacent cells will be created from the intersection point, and adjacent cells will be added to the priority queue again; or .. The bottom of the shoreface \(D_{sf}\) is reached and the cell is closed by a straight line across the shoreface defining the bottom of the shoreface. . The procedure continues until all cells have been meshed.

Git is version control software. The model is stored in a repository on github. This allows us to track all of our updates and developments and avoid duplication. You can install git from the command line:

Getting to grips with git can be a steep learning curve at first. The github glossary is useful for getting up to speed with the terminology, and I found a good cheat sheet for git commands.

If you are using a Linux machine (e.g. the recommended Ubuntu VM) then you should have the GNU Compiler Collection installed. Depending on your experience and whether your developing the model, the GNU debugger can also be helpful (should already be installed with GCC), not to mention Valgrind (you probably know what you`re doing better than I do if you`re using Valgrind!). We will also need the make utility (this should also be ready installed). No additional C++ libraries are required at this stage.

A text editor is required for viewing and editing both the main code and driver files (shorter bits of code that interact with and control the main model objects). Ubuntu ships with gedit, which I find works well once you install and activate some useful plugins.

Some of these can really increase productivity while writing code.

Python is a programming language that is great for analysing and visualising data, and is used here to visualise the output of COVE and running further analyses on model results. Again Python comes preinstalled on Ubuntu, but you could also use it on Windows/Mac. The key package required is SciPy ("scientific python"), which includes NumPy and Matplotlib. These are included with Ubuntu`s preinstalled version of Python.

It is recommended that you install a Python IDE in order to run plotting functions and perform post-processing. The preferred IDE is Spyder. The easiest way to install is from the command line:

Mencoder is a command line tool that is part of MPlayer that allows you to encode video files. We use it here to stich together still images of model output in order to create videos of our model coastlines evolving. To install, from the command line, type:

Cygwin is a collection of tools that provides functionality similar to a Linux distribution on Windows. It provides a Unix-like environment and command-line interface for Windows. You can install Cygwin by downloading one of the binaries found on the installation page. We will require certain packages to be installed to Cygwin, most notably the GNU GCC compilers and the GNU Debugger. A good guide for the installation process of Cygwin and the required packages can be found here. Once Cygwin is installed, all of the command line instructions for Linux found in this documentation can also be used with Cygwin.

Code::Blocks is an IDE with built in compiler and debugger functionality. Head to the download page for Code::Blocks and select the binary executable with the suffix "…​mingw_setup.exe". Run through the installation procedure selecting the default options. Once finished, Code::Blocks should load automatically.

Notepad is a free text editor for Windows often recommended by developers, with support for several programming languages, including C. It can be downloaded here.

Python is a programming language that is great for analysing and visualising data, and is used here to visualise the output of COVE and running further analyses on model results. The key package required is SciPy ("scientific python"), which includes NumPy and Matplotlib. If you are using Windows/Mac then we recommend installing a Python distribution such as Anaconda.

The code can be compiled in a Linux environment from the command line, using one of the makefiles. These are contained in the driver_files subdirectory. The driver files are C++ scripts that control the initiation, running and saving of a COVE model run. In this tutorial we will use the example for running a spiral bay as used in Hurst et al. (2015).

In a terminal, navigate to the driver_files subdirectory:

Compile COVE for running a spiral bay by launching the makefile:

This will create an executable spiral_bay.out which can be launched from the command line to run the model. First, let`s move the executable to the parent directory, and navigate to the same directory:

The file spiral_bay.out generated by compiling the code can be launched from the command line:

Running it in this way will result in it terminating with an error, which will tell you that the program requires a number of input arguments in order to run. In the spiral bay example, the offshore wave climate is represented with three Gaussian distributions, for wave period, height and direction. Each of these is described by a mean and standard deviation, and these are fed to the model as arguments. To run the model with mean wave period of 6 seconds, standard deviation 1 second, mean wave height 1 metre, standard deviation 0.1 metre, and mean wave direction 035^o and standard deviation 25^o:

The model should then run for fifty years. This example evolves a crenulate-shaped bay from a straight initial coastline between two fixed headlands or sea walls. Sediment is transported out of the model domain by alongshore sediment flux and the shoreline gradually adjusts to the distribution of wave directions. The bay eventually reaches a state of equilibrium where the net alongshore flux is close to zero everywhere. The model is setup to run for 100 years, more than enough time for an equilibrium bay configuration to form.

While running the model will print the current model time to screen, it may also print some other messages, particularly including intersections in the coastline. The intersection analysis detects when the coastline intersects itself, such as when it erodes back behind the headland. Once this has happened the coastline is prevented from eroding any further.

Since Code::Blocks is not the current development environment favoured by the COVE team, there is no Code::Blocks project file maintained in the COVE repository, and thus you will need to create one from scratch. Luckily, this process is pretty simple. Having opened Code::Blocks, from the startup click to create a new project:

Select the "Empty project" project template then click through the empty project creation wizard. You will be asked to name the project and provide a file/folder structure (see example) and then to select a compiler (select the GNU GCC Compiler; see example). Keep the default options for "Debug" and "Release" configurations and then click Finish.

Next we need to populate the project with the required C++ files. From the top menu, click on Project → Add files…​ then navigate to the COVE repository directory. Add the following list of files to your project:

You should be able to expand the project in the Management side-bar to see these files organised by their file type (header or source).

To compile the code, from the top menu, click Build → Build. This will compile and link all of the code automatically and create an executable named YOUR_PROJECT_NAME.exe in the bin and debug folders of your project folder. You can then run the code from Code::Blocks by going to the top menu and clicking Build → Run. If the driver file you have chosen or created requires input arguments, these can be set by clicking Project → Set programs' arguments…​.

The model loop is pretty simple really, first grab a new wave from the wave climate, second pass it to the Coastline object when calling the TransportSediment function, third print the coordinates of the new Coastline to file.

And in code that looks something like this:

The driver file spiral_bay_driver.cpp can be found in the driver_files subdirectory. You can navigate to it and open in a text editor from the command line with:

or open it from the explorer window.

OK, let’s look at the driver file. There are some helpful comments that are ignored when we run the program, these start with "//" or are in blocks "/*" to "*/". At the top of the file there are some #include statements that allow the program access to some libraries we will be using, including the model`s main coastline and waveclimate objects.

The spiral_bay_driver uses a Guassian representation of the wave climate. The parameters to set up the wave climate are required as input arguments at runtime. The wave climate is defined by a mean and standard deviation value for:

and hence 6 input arguments are required. The driver file runs a check at the start to make sure it has the correct number of arguments, and will terminate with an error message if not.

In order to initialise the wave climate the 6 input arguments first are assigned to 6 variables:

and the corresponding input arguments are converted from character sequences to numerical values and passed to these variables.

The wave climate is initialised by declaring a GuassianWaveClimate object called WaveClimate and passing these variables as input arguments in the correct order.

We then also declare an individual wave object. This holds the period, height and direction of an individual wave MyWave which we later pass to the coastline object in order to drive coastal evolution. We will sample a wave from WaveClimate and pass it to MyWave

Various parameters are required to control the length of the model run (in years), how often the coastline position is output to file (in years), how often to sample a new wave from the wave climate object (days), and how big the model timestep should be (days). We suggest leaving these as they are for now, but as you start customising model setup you may need to adjust them.

The spiral bay model is initialised as a straight coast with fixed boundaries at each end of the coast line. In order to generate the coastline object, we need to prescribe some attributes that dictate the properties of the generated coast, which we will pass to the new Coastline object when we declare it.

OK now that we have these variables in place we can go ahead and declare the Coastline object.

We declare a Coastline object whech we have called CoastVector, this is our coast, and all of its morphological properties are stored internally within the object. We provide the input arguments to the call in the order listed.

Note there is also a call to declare a Cliffline object called CliffVector. It has no input arguments and therefore generates an empty Cliffline object (i.e. there is no actual cliff line inside it). Our spiral bay experiments don`t require a cliffline object so that is OK, but this declaration is required to keep the model happy (it needs to be able to look at a cliff to know it doesn`t really exist, it`s a dummy cliff). Don`t worry about this for now, this will generate a warning when we come to run the model but we are OK to ignore it.

Finally, for our spiral bay runs, we want to allow some simple rules for the refreaction and diffraction of waves behind coastal obstructions to be operating. To do this we need to set a flag within the Coastline object, 1 = on, 0 = off.

Finally, before we run the main model loop, we’ll write the initial conditions to file:

We’re all set up and ready to go! The model loop is pretty simple really, first grab a new wave from the wave climate, second pass it to the Coastline object when calling the TransportSediment function, third print the coordinates of the Coastline to file.

The model evolves until the Time exceeds the prescribed EndTime:

We grab a new wave from the wave climate if it’s time (GetWaveTime depends on WaveTimeDelta which sets how often we get a new wave):

Notice that GetWaveTime is in years, but WaveTimeDelta is in days, so we divide through by 365 to convert.

Now we evolve the coast by calling the Coastline function TransportSediment. This requires three input arguments, TimeStep is the length of time that sediment is transported over, we also give it the wave MyWave, and finally the dummy Cliffline object CliffVector:

A whole lot of things happen inside this function (see a later section of this documentation that is yet to be written). The shoreline geometry is recalculated at each timestep. The wave is transformed from offshore to wave breaking conditions following linear wave theory, and any wave shadowing and refraction/diffraction are calculated. Alongshore sediment transport for each cell is calculated and the change in the volume of sediment in each cell calculated from the divergence of alongshore flux. The volume change is inverted for a change in the position of the coast and the position of each node is updated accordingly. The coastal geometry is updated for the next timestep.

There is a crude attempt written in here to allow adaptive timestepping. This hasn’t fully been tested yet, and usually if it’s called it’s because there is a bug in the model not actually associated with the adaptive timestep. If you run into this problem please email me.

Finally, the model prints the updated X and Y coordinates to an output file. See Writing Results to File for details of the resulting file format.

Compile COVE for running a spiral bay by launching the makefile:

The file spiral_bay.out generated by compiling the code can be launched from the command line. The program takes the wave climate parameters as inputs \(T_{mean}\), \(T_{std}\), \(H_{mean}\), \(H_{std}\), \(\theta_{mean}\), \(\theta_{std}\):

The model should then run for fifty years. This example evolves a crenulate-shaped bay from a straight initial coastline between two fixed headlands or sea walls. Sediment is transported out of the model domain by alongshore sediment flux and the shoreline gradually adjusts to the distribution of wave directions. The bay eventually reaches a state of equilibrium where the net alongshore flux is close to zero everywhere. The model is setup to run for fifty years, more than enough time for an equilibrium bay configuration to form.

While running the model will print the current model time to screen, it may also print some other messages, particularly including intersections in the coastline. The intersection analysis detects when the coastline intersects itself, such as when it erodes back behind the headland. Once this has happened the coastline is prevented from eroding any further.

A series of plotting functions are included in the subdirectory plotting_functions. To plot the results of your spiral bay model run, open the file plot_coastline_evolution_figure.py in your favourite python IDE, and run. You should get the following figure:

The appropriate driver file is straight_periodic_driver.cpp and can be found in the driver_files subdirectory. You can navigate to it and open in a text editor from the command line with:

or open it from the explorer window.

The driver file has been commented up helpfully to explain what is going on throughout. The driver file structure follows that laid out in section 5.1 (add link). We will assume you are already familiar with the spiral_bay_driver.cpp example.

Out straight, periodic boundary model run uses a UA wave climate, and hence 2 input arguments are required:

Other wave parameters (period and height) are assigned explicitly within the driver file. The wave climate variables are assigned:

and these provide the corresponding input arguments for initialising the UAWaveClimate object. The wave climate is initialised by declaring a UAWaveClimate object called WaveClimate and passing it these variables as input arguments:

We then also declare an individual wave object. This holds the period, height and direction of an individual wave MyWave which we later pass to the coastline object in order to drive coastal evolution. We will sample a wave from WaveClimate and pass it to MyWave:

Similar to the spiral bay example, we need to declare parameters to control the length of the model run, how often we save results to file and when to sample new waves from the wave climate.

There are two possible boundary types in COVE, fixed or periodic (at the moment). We want boundary conditions that are periodic, so sediment passed out of one end of the model is provided to the other. This means the end two nodes are geometric copies of each other and always experience the same amount of flux and change. We use an integer flag to specify boundary conditions, where 1 = periodic and 2 = fixed:

For periodic boundary condition runs initialise coast as straight line with a node spacing of 100 m and orientate the coast nort-south.

So now we can initialise the coastline as a straight line. With this call, we are creating a Coastline object which we will call CoastVector. To do this we need to provide this initialisation member function with 5 arguments so it can setup the coastline as we want it. We also create a Cliffline object, but because we do not assign it (there is no = sign), it will be completely empty (i.e. there is no cliff). When COVE checks to see whether there is a cliff to work with, it needs to see an empty cliff object to know that no cliff exists. I’d like to find a way to put thi "under the hood" but this will have to do for now.

The periodic coast expreiments do not require a Cliffline object but the declaration is required to keep the model happy. This will generate a warning when we initialise the model but we are OK to ignore it.

Next we need to set some other model parameters required to describe the shoreface and the style of sediment transport. There are a series of public set_ member functions that allow us to do this. Each of these have default values, so if you don’t set them the model will jsut use the defaults. The values we’re going to set here are the default values, just for illustrative purposes. They are

First we will declare some temporary variables for these, and then call the functions to set them within the model:

We will automatically create an output file name based on the wave parameters provided as input arguments, and write the initial conditions to file uing the WriteCoast member function (see Writing Results to File section for more details).

This follows the same structure as outlined in section X.

Compile COVE for running the straight, periodic coast example by launching the makefile:

This should create an executable file called Straight_Periodic.out which can be launched from the command line. The program requires two input arguments, U and A:

This will run the model with 70% of waves coming from high angle, and 50% of waves coming from the north-east quadrant. This should result in the formation of sand waves that migrate down the coast (untested!). We should also be able to observe waves that migrate off the bottom of the model domain reappearing at the top.

While running the model will print the current model time to screen, and may also print some other messages recording unusual model behaviour!

To plot the results of this run, we are going to create an animation! Open the file plot_periodic_animation.py in your favourite python IDE, and run. You should get a series of figures whose file names are numbered sequentially and each looks a bit like this:

The python script creates a file called filelist.txt which contains a list of all the output filenames. These frames can then be stitched together to create a video of the coastline evolving using Mencoder, a command line tool that is part of MPlayer that allows you to encode video files (Linux only). Thus once you have run the python script, you can run the following command to stich the output together into a nice video:

Once you’ve made the video, you can delete all the individual png frame files to keep things tidy:

The driver file benacre_driver.cpp can be found in the driver_files subdirectory. Hopefully the comments in the code will be helpful as you look through. These are ignored when the program is run. At the top of the file there are some #include statements that allow the program access to some libraries we will be using, including the model`s main coastline, cliffline and waveclimate objects.

Various parameters are required to control the length of the model run (in years), how often the coastline and cliffline positions are output to file (in years), how often to sample a new wave from the wave climate object (days), and how big the model timestep should be (days). We suggest leaving these as they are for now, but as you start customising model setup you may need to adjust them.

Using a real coastline, the model will require three input files in order to initialise the coast. A coastline x-y file, a cliffline x-y file and cliff type file. These are available in the example_inputs subdirectory of the repository. From the driver_file directory copy these across at the command line ready for running the model:

These files have been declared in the driver file:

The coastline and cliffline *.xy files have the same format as the model output, consisting of a header line with two space-separated integers representing the start and end boundary conditions, followed by lines containing the x and y coordinates of the coastline, preceded by the time (see "Read a coast from file" in the "under the hood" section).

The order that your x and y coordinates come in is very important. The model ALWAYS assumes that the sea is on the left side as it works its way down the coastline or cliffline vector. To be sure you get this correct, imagine you are standing at the first node on your coastline, looking towards the second node. The sea will be on the left of the line, and the land on the right (see Figure 5). If this is backwards, you will get some very strange behaviour, because the model will ignore alot of waves (since they are coming from the land) and beach widths will be negative. If your first attempt at modelling a stretch of coastline blows up straight away, this is the first thing to check. We should probably write some error checking into the beach width calculator to flag negative values and warn you. This will get added in later.

The third file required is a cliff type file. This tells the model whether a cliff node can erode or is fixed (this can later be expanded to include different types of geology). Currently a value of 1 represents a fixed coast (e.g. defended by sea wall/revetment) and a value of 0 is a normal erodible cliff. The file format is a header line followed by two columns, one for the node index (i=0 to i=NoNodes-1) and the second for the cliff type integer.

Wave data from the Southwold wave buoy shows that our example coast is hit by a bimodal wave climate. The wave buoy is in 25 m water depth and suggests high angle waves impinging toward the coast, which if fed directly to the model results in high angle wave instability that is not observed on this stretch of coastline. A legacy data set from a previously deployed AWAC wave buoy shows that these dominant wave modes get rotated to lower angle of incidence by the time they reach the shoreface, so for these example experiments, we have chosen a similar lower angle, bimodal wave climate.

Our bimodal wave climate consists of two Gaussian wave climates as used in the spiral bay experiments. The parameters for these have been declared in the driver file diectly rather than being passed as input arguments.

So we have two wave climate objects, WaveClimate1 and WaveClimate2. As before we also need to declare an individual wave object:

In the main model loop, we will use a random number generate to select which wave climate to grab a wave from at random, and assign it to MyWave ready to evolve the coast.

We initialise both the coastline and the cliffline objects by pointing them to the respective input files as detailed in the previous subsection. We then provide an extra call to the CliffVector object to tell it to read whether the cliff is fixed or erodible:

Then we declare a couple more file names where we will write the output files for both the cliffline and the coastline object:

There are a few other things we need to set up for this run; how fast the cliffs can erode, how high the cliffs are, what the critical beach width is that maximises cliff erosion, and how much cliff material gets lost offshore when the cliff erodes.

First, we will setup the maximum retreat rate. This is the fastest retreat rate the cliffs can manage, and can be informed or calibrated by historical observations of cliff retreat. For our section of the Suffolk coast, we will set this to 5 m yr^-1, guided by Brooks and Spencer (2010).

Second, we will set the cliff height. At the moment this is spatially and temporally continuous, but functionality can be added later to extract this value from a DEM as the model evolves.

Third, we set the critical beach width. This is the beach width at which the maximum rate of cliff retreat occurs. For wider beaches, the rate of cliff retreat declines exponentially. We will set this to 5 m, suggesting that a 5 m wide beac provides the optimal balance between protecting the cliff and providing abrasive tools such that cliff erosion is maximised.

Fourth, we set the style of cliff retreat. ErosionType = 1 if using a Valvo et al. (2006) type of relationship between beach width and cliff retreat (this is effectively the same as setting CriticalBeachWidth = 0 and thus redundant). 'ErosionType = 2' uses the Limber and Murray (2011) relationship between beach width and cliff retreat where cliff retreat rate peaks at CriticalBeachWidth.

Fifth, we set the proportion of cliff material assumed to be lost to the sea:

And finally, since the Suffolk beaches are mixed sand/shingle, we tell the coastline object to use an alongshore flux equation that has been modified to better reflect gravel transport rates:

Good to go! The model loop is pretty simple really, first grab a new wave at random from one of the two wave climates, second pass it to the Coastline object when calling the TransportSediment function, third call the Cliffline object’s ErodeCliff function, and finally print the coordinates of both the Coastline and Cliffline to file.

The model evolves until the Time exceeds the prescribed EndTime:

We grab a new wave from the wave climate if it’s time (GetWaveTime depends on WaveTimeDelta which sets how often we get a new wave):

rand1 selects a random number between 0 and 1. When rand1 < 0.5 we use WaveClimate1 and otherwise we use WaveClimate2 so we should be sampling equally from both wave climates. Notice that GetWaveTime is in years, but WaveTimeDelta is in days, so we divide through by 365 to convert.

Now we evolve the coast by calling the Coastline function TransportSediment, followed by the Cliffline function ErodeCliff. Each requires three input arguments. For the Coastline.TransportSediment call, TimeStep is the length of time that sediment is transported over, we also give it the wave MyWave, and finally the Cliffline object CliffVector so that it can only erode beach material that fronts the cliff. For the Cliffline.ErodeCliff call, we pass TimeStep again, the Coastline object, and the type of erosion law ErosionType.

A whole lot of things happen inside these functions (see a later section of this documentation that is yet to be written). Coastline and Cliffline geometry is recalculated at each timestep. The wave is transformed from offshore to wave breaking conditions following linear wave theory, and any wave shadowing and refraction/diffraction are calculated. Alongshore sediment transport for each cell is calculated and the change in the volume of sediment in each cell calculated from the divergence of alongshore flux, checking with the Cliffline position that sediment is available for transport. The volume change is inverted for a change in the position of the coast and the position of each node is updated accordingly. The coastal geometry is updated for the next timestep. The width of the beach is calculated by comparing the Coastline and Cliffline objects and this determines the amount of cliff retreat. The Cliffline position is updated and the amount of volume lost is supplied to the adjacent beach, minus the amount lost to the sea.

Finally, the model prints the updated X and Y coordinates to two output files. See Writing Results to File for details of the resulting file format.

Compile COVE for running the Suffolk example by launching the makefile:

The file benacre.out generated by compiling the code can be launched from the command line without any input arguments :

The model should then run for fifty years. This example evolves the Suffolk coast such that the cuspate foreland Benacre Ness migrates northward up the coast at rates in keeping with historical observations. While running the model will print the current model time to screen.

A series of plotting functions are included in the subdirectory plotting_functions. To plot the results of your Suffolk model run, open the file benacre_evolution_animation.py in your favourite python IDE, and run. You should get a series of figures whose file names are numbered sequentially and each looks a bit like this:

The python script creates a file called filelist.txt which contains a list of all the output filenames. These frames can then be stitched together to create a video of the coastline evolving using Mencoder, a command line tool that is part of MPlayer that allows you to encode video files. Thus once you have run the python script, you can run the following command to stich the output together into a nice video:

Once you’ve made the video, you can delete all the individual png frame files to keep things tidy:

Input files for the position of the coast take the same format as output files. The first line is a header containing integer values for the StartBoundary and EndBoundary conditions. The next two lines are the X and Y coordinates of the line respectively, but both preceded by the time (in years). We use \| to indicate a white space delimiter here such as a space or tab.

So for example, a 5 metre long coastline with fixed boundary conditions oriented at 135^o with a \(sqrt{2}\) node spacing, at Time = 0 would have an input file:

The makefiles used for compiling COVE typically include the required flags to allow GDB to function correctly (you have to tell your compiler that you want to debug when you compile the code). To launch GDB for compiling a particular model (e.g. the spiral bay model executable), run the command:

You will be presented with the (gdb) console from which you can make commands to the debugger.

To run the model in debug mode, type run, followed by any required commandline arguments:

The model will execute as if you launched it from the command line, and all being well will complete. If you have already run the model once inside the current debug session, you can rerun by just typing run, without the additional arguments, and it will execute with the same arguments as the previous run.

If you’d like to pause the model while it is running, press CTRL-C on your keyboard. You will be returned to the (gdb) console. To resume the model, type c at the console. When paused this way, we have no idea where abouts within the model it is paused.

We can find out where in the model we have got to by typing:

This will print to screen a history of where the model has been to get to where it is currently:

This is telling us the model is #1 inside the main function of spiral_bay_driver.cpp at line 144. This happens to be the TransportSediment function, and #0 tells us that it is at line 3838 within that function in the 'coastline.cpp' file.

The backtrace function can be particularly useful for pinpointing where memory leaks and segmentation faults have occurred if the model fails for one of these reasons.

Before executing the model, or whilst paused, we can set up break points to tell the model to stop when it reaches a certain place in the code. For example:

This tells the debugger to automatically break (pause) the model whenever line 186 in the spiral_bay_driver.cpp file is reached. This has been assigned a number Breakpoint 1.

You can tell the debugger to only implement the break point if a particular conditions is met, using the same conditional syntax as you would use in C++ code. In the next command, we’ll tell the model to break when the variable Time is greater than 0.1, using the cond command, telling it to apply to Breakpoint 1, and telling it what the conditional statement is:

Typing c for continue, or run to run/rerun the model will execute the model until this condition is met, upon which the model will pause/break.

In the case above, line 186 happens to be inside the main model loop. To see how much model time has elapsed, we can use the print (or p for short) command to display the Time variable on screen:

Telling us that Time has a value of 0.1. We can also access and print values from within objects, such as the coastline object called CoastVector. Let’s print the number of nodes in our coastline object:

So there are 57 nodes. Another way you can find out how many nodes there are would be using

The coastline object CoastVector contains a variety of vectors, such as the Orientation vector. To print the whole vector, simply type:

If you jsut want to know what the Orientation of the first node or last node is, try: