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.

NWI is a product of considerable technical expertise from US FWS that includes satellite data, infrared photography data, photographic interpretation, and considerable GIS expertise. 

https://www.fws.gov/wetlands/nwi/Overview.html

You do not need an NWI data set to use SLAMM however.  You do need some sort of high-quality vegetation land-cover polygons that can be cross-referenced to the SLAMM categories.

Hello:  Thanks for your interest in the model.

1. "ASTER DEM standard data products are produced with 30m postings, and have Z accuracies generally between 10 m and 25 m root mean square error (RMSE)."  I'm afraid that that Z accuracy is not going to be compatible with modeling the effects of 1-2 meters of SLR on marsh systems.  You will need LiDAR or ifSar.  I would say you wouldn't want a vertical RMSE of above 25 cm.

2.  In US applications we get MHHW and MLLW data from NOAA gauges.  You can use whichever type of tide gauge or water level monitoring data that you have available -- long term data are best.

3.  The SLAMM model usually assumes that tidal flats have a lowest elevation at MLLW.  That means that you would need aerial imagery that is tidally coordinated (taken at low tide) 

Best regards -- Jonathan

The cells are updated every time step, correct.

SLAMM actually tracks partial conversions of cells over time -- it was originally created many years ago when computers were much less powerful and cell sizes were therefore much larger (150-500meter).  For this reason it has always tracked multiple land types in each cell.  For this reason the tables of output are not always precisely what you would get when adding up the area of the raster maps.  After erosion to tidal flat, the elevation of the cell would be set to the elevation of the flat or MTL if there is no adjacent flat. 

In some of our older runs we found that the flat itself, became protective against further erosion at the marsh-to-open-water interface.  For this reason marshes erode directly to open water.   https://github.com/WarrenPinnacle/SLAMM6.7/blob/master/PROGRAM/Categories.pas  line 627

-- Jonathan

You are correct.  However, soil saturation is not affected by dikes which could be causing the differences you are seeing.   Try turning soil saturation off.

Are you rendering the dike layer in "Set map attributes" to ensure that the software is interpreting your data layer correctly?  

And I think you get this, but you define the entire area protected by dikes using "classic" mode rather than the location of the dike itself.  

If none of these answer your question, feel free to post or email me some screen caps showing what you are seeing.

Thanks!  -- Jonathan

So glad you solved the problem!  I will make a note for the next version to override the Windows settings so that a decimal point is used in either case, so this does not pose a problem in future versions.  Thanks -- Jonathan

1. Yes, this replaces the default 9km.  It will not use the 9km default if 0 is used, therefore if you wish to use that default, please input 9.0.

2. Leaving these as zero should not have an impact on your simulation. 

3. These can be left at zero.  Please see the latest model application documents for some information about how we have set this parameter in the past.

https://www.nyserda.ny.gov/-/media/Files/Publications/Research/Environmental/18-04-Integrating-SLAMM-Results-Marsh-Adaptation-Strategies.pdf

http://warrenpinnacle.com/prof/SLAMM/NROC/SLAMM_NROC_Report_Final_Corrected.pdf


Sorry about the long delay in response!  -- Jonathan

I guess we've never run with just an 010 and not also a 100 year storm.  I think it's fair to say that this portion of the model has only been utilized by our team and is not deeply user friendly.  I'll look into the code to understand the requirements.

Yes, if you have no correction factor for NAVD88 then using the MTL datum would be correct.  This is because, while the model will try to convert data from NAVD88 (which has been the format we generally received data in) it would use the zero conversion factor, so there would be no change.

Sorry about the deficiency in documentation.  This is from some metadata we created when running the model:

Inundation maps were created by running SLAMM for 5 different inundation elevations (H1-H5 in the subsite parameters)

Raster values are: 0 (zero) - open water, 1 - inundated at H1 level (we often set this to the 30-day inundation level), 2 - inundated at H2 (we have used 60 days), 3 - inundated at H3 (90 days) 4 - inundated by H4 (we often set this to the 10 years storm), 5 - inundated at H5 (100 years storm), 6 - above H5,  7 - below H5 but not connected, 8 - protected by dikes, -99 no data/blank

I downloaded the executable and sample files and was unable to reproduce your problem.   

Are you unzipping all of the files rather than trying to run out of the compressed folder?   
What happens when you press the "Set Map Attributes?"  Do the map and editing tools appear?
What happens under the file-setup window?  Are files showing as red -- invalid or are the list of NRows and NCols shown under each one.
In some cases you must point the file system to the correct file, but this may not be required if the files are in the same directory as the SLAMM6 file.

Good luck!  -- Jonathan

Sorry I misspoke.  The code must be compiled on Delphi XE3 -- my version is Embarcadero® Delphi® XE3 Version 17.0.4625.53395

I cannot port the code to other development platforms at this time.

Sorry you are having difficulty with the sample files.  I'm out of my office until Monday and I will look at your question then.

Hi Scott:

First of all, please note that there is a difference in datum used for the two parameters (which is probably not an ideal design.)   GT is expressed as meters between MLLW and MHHW.  The salt elevation is expressed as height above MTL (the mid point between MLLW and MHHW), so is a lower value than the GT generally.

As you have likely seen in some of our reports, this is based on "frequency of elevation" analysis from observed-data analysis so that it takes into account wind tides as well as astronomical tide cycle data.  I can point you at one of these analyses at some point if you'd like.   If you calculate a daily high water level using NOAA data for several years and then calculate the 0.967 percentile of those data that pretty much will get you there.

Best!  -- Jonathan