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:
SLAMM can also simulate a "time zero" step, in which the conceptual model can be validated against the data inputs for your site. The time-zero model predicts the changes in the landscape given specified model tide ranges, elevation data, and land-cover data. Any discrepancy in time-zero results can provide a partial sense of the uncertainty of the model. There will almost always be some minor changes predicted at time zero due to horizontal off-sets between the land-cover and elevation data-sets, general data uncertainty, or other local conditions that make a portion of your site not conform perfectly to the conceptual model. However, large discrepancies could reflect an error in model parameterization with regards to tide ranges or dike locations, for example, and should be closely investigated.
Last post by zhiliehui1 - November 14, 2019, 01:40:26 AM
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.
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.
Last post by slammdunk - October 29, 2019, 06:55:29 PM
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?
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.
Last post by slammdunk - October 01, 2019, 04:19:42 AM
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?
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.
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.