With regards to Question 1:

Thank you for your question, I'm not sure this is adequately addressed in the technical documentation.

The way that the "include dikes" and "dike location raster" works is that the model uses the connectivity algorithm to see if there is a connection between the land behind the dike and a "salt water source."  Specifically, the categories "riverine tidal," "estuarine water," "tidal creek," and "open ocean." must not appear behind the dike.  Otherwise the dike location raster will not work and the results will be no different.

You may check the connectivity of your site using the connectivity map option when setting up your model.

With regards to Question 2:

The time-zero run is a very important step.  To the extent possible, it should not be any different than the model's initial conditions.  It tests that the conceptual model, the wetland coverage, the elevation data, and the tide range data are all consistent.  In the results the initial condition is shown as "0" and the "time zero" result is shown as the first date of the simulation.

From the tech doc:

I am a student from China. I had several problems using slamm:
1\ I want to simulate the influence of the presence and absence of dikes on the coastal wetlands in the current and future situations. The data type of the dikes I used is the type of position and height. In the execution window, I made the Settings including and excluding dikes respectively, as shown in the screenshot below.However, the result is consistent with the fact that there is no dike, but obviously this is not consistent with the actual situation, please help me how to solve this problem.

2\In the process of model simulation, I noticed there are run model for NWI photo date (0) in execution window , refer to the technical manuals, but I still don't quite understand, why no matter whether the check this option, the result is 0 year which is not  consistent with the   starting year wetland distribution  in simulation , please help me to solve, whether in the simulation of actual need to check this option.
 
thanks a lot for your help sincerely

There always will be outliers in terms of the elevation to wetland to tide range relationship.  (Influences of ground water can have fresh marsh occurring lower, or wind tides can have salt marsh occurring higher.  Also, elevation data can be uncertain especially in areas of high vertical relief.  Or wetland maps have horizontal error. So we very often have outliers outside of the modeled range for wetland categories.)

In general, you don't need to include these elevation outliers in your accretion to elevation relationship.  Those wetlands that fall below the modeled lower range (we often set this to approximately the fifth percentile of the wetland elevations) will be lost at "time zero."  You can then check to see if this is reasonable or not based on satellite imagery and make changes if required. 

Those wetlands that fall above the modeled higher range will be set to the accretion rate modeled at the highest range.  We usually do not model those wetlands as "drying" because they are too high, assuming some other local factor has those wetlands perched at that elevation.  So they will generally remain persistent unless the SLR becomes extreme. 

Overall, the accretion model should try to match the majority of the data (5th to 95th percent confidence interval?) and not worry about the outliers.

Hope this is helpful, thanks!

Hello Jonathan,

Thank you for in-depth and easy to follow instructions. Your response helped clear a lot of my confusion.

A follow-up question I have is, on the SLAMM accretion spreadsheet it states under the min and max "not parameters but reflective of elevation range of wetland type". Would it be better to have min and max across the whole estuary being modeled or would it be better to have the average min and max of vegetation types around SET tables?

Happy to hear that you like the username!

First calculate the longest term average elevation-change rate for your SET tables that you have available.

Then calculate the elevation of the SET table relative to MTL in "half-tide units."  As a reminder, half-tide units are "elevation-in-meters / (0.5 * GTU-in-meters )"

Then, plot these data on a graph so you can understand the relationship between SET elevation and measured elevation changes.   

A line using the accretion spreadsheet data can then be fit through the data to the best of your capability.

e.g. Fig 4 from https://www.sciencedirect.com/science/article/pii/S1364815216302705#fig4

Often SET tables are not set at elevations throughout the tidal range and are focused up around MHW so you would need to estimate the other portions of the range or use a model such as MEM3 to help fill out the relationship between marsh platform elevation and predicted accretion rates.

This is a quick birds-eye view of the procedure, please ask specific questions about the spreadsheet and we will answer them ASAP.

Love the user name BTW.

Regards!  - -Jonathan

Hello Jonathon and Marco,

I am new to SLAMM and have had some difficulties understanding how to vary accretion rates as a function of cell elevation for different NWI wetland codes. I am hoping you can provide some more guidance on how to go about this.

I would like to use surface elevation change data from SETs that were placed in marsh and mangrove regions. Rather than breaking up the dataset for subsites around each SET, I would like to have accretion rates vary with elevation and tidal range for marsh and mangroves. I'm not certain about how to input this data into SLAMM though. Could you provide a step by step overview?

I have read through the user manual and technical guides, and have tried playing with the Excel SLAMM6_Accretion file included with the download. However, I'm still confused about how to go forward.    Could you also provide an overview of the SLAMM6_Accretion file- bit of an introduction on how to utilize the spreadsheet?

Thank you ahead of time for all your help!   

Hi Johnathan,
thanks for the helpful reply.

Yes, the same 10m resolution data set works in 6.0 but not in 6.7
I tried the 2m resolution set in 6.0 and it went to write to disc then crashed...unsurprisingly; they are pretty big files.

I have ordered more memory for the laptop and will try the binary option for both datasets in 6.7 as you advise.

If this doesn't work I will zip up the 10m data for you to diagnose stepwise in 6.7, but that will be my last option knowing how busy you are.
All the best
Andy

The DEM must have some vertical datum to which elevations are referenced -- are the elevations in terms of the 1974 datum?

The MTL-NAVD88 parameter is set up such that if you looked at a gauge and there was a referenced MTL height and a referenced NAVD88 height, the value would be the difference of the two numbers referenced.

For example, at this station

MTL is 4.451 and NAVD88 is 3.134 meaning that MTL-NAVD88 would be approximately 1.3 meters.


NAVD88 can be substituted for whatever the datum of the elevation data set is.  So you can convert your datum of elevation to MTL (often ~MSL) and then set the MTL-NAVD88 parameter to zero.

In the case of your figure, if your elevation data are in 1974 datum, MTL-NAVD88 would be 1.46 meters.

Been traveling, sorry about the delay in response -- hope this helps.

Hi.

The 64-bit version of the software should be able to accommodate nearly any map size -- the limitations are the memory of the machine (and there are also practical limitations in terms of how long it takes to load and run simulations.)   We have found the maximum size that is reasonably practicable to run is approximately 26 GB of memory (~250 million cells) but that obviously requires 32 GB of memory or more. 

Note the memory utilization in GB is given in the SLAMM File setup window and different optimization options are available a the bottom of the screen. 

e.g. "Cells to Track 7,169,539, memory utilization in GB 0.7478"

Are you saying that data can be input at 10m resolution in 6.0.1 but that 6.7 crashes with the same data set?  Have you tried converting the data to binary using the binary button?  This significantly optimizes input/output and may shed light on the problem.  If you cannot solve the problem, you can send me the data files and I can look at it, but I'm afraid I have not been very responsive in terms of loading other people's data lately.  Sorry that the software is not giving you a more helpful error message. 

I hope your problem resolves shortly.

Hi,
A further update.
The data works in version 6.0.1 at the 10m resolution level but runs out of memory at the 2m resolution.

It would nice to run 6.7 version to get the carbon module.

Kind regards
Andy