There are several possible reasons for this issue --

Elevation data have incorrect units.  Please go through the Set Map Attributes and then into elevation analysis and run an elevation analysis to ensure that your model data are reasonable with respect to the conceptual model here:  http://tinyurl.com/SLAMM-Elev-Defaults

You must supply a DEM date and an NWI date.  Sometimes if one of these are set to zero elevations become highly distorted.

Ensure that your NAVD88 to MTL correction is set properly.

All maps must have units of meters.

Good luck, continue to examine your map in the Set Map Attributes tools and you should figure out your problem.

Indeed, this is our conceptual design for SLAMM 7.0 to introduce significant flexibility in regards to adding and removing wetland categories and allowing user control over the flow chart of wetland succession under SLR. 

The DEM uncertainty module tries to create a number of equally likely maps that would have the same error statistics as the (hopefully LiDAR-derived) elevation layer.  The fact that elevation errors are spatially auto correlated complicates the matter to some degree.

The only down-side to including DEM uncertainty in an uncertainty analysis would be that the default random spatial auto-correlation is not good enough.  LiDAR error is known to be greater in marshes for example, and possibly biased high (due to difficulty in lasers penetrating the marsh surface).   DEM error is also known to be greater in higher sloped areas.  There may be a known spatial component to error in ground-truthed LiDAR and this cannot yet be brought into the existing SLAMM analysis.  However, if you only know the RMSE of the data set, this is probably the best that can be done for the moment.

The lack of accounting for elevation data uncertainty was a criticism of early SLAMM work.  Some researchers will take the 95th percent confidence interval for the entire data set (based on RMSE) and apply that uniformly across the data set.  I don't believe that this is an appropriate characterization of elevation data uncertainty as you are applying individual cell statistics as though they apply to model bias.  If you assume a data set bias of zero but apply error fields that reflect the RMSE of the LiDAR data that is a much better way of characterizing additional uncertainty.  The effects on model results have been fairly modest when evaluating effects of state-of-the-practice LiDAR data error.

Nava -- when using SLR estimates that account for local subsidence and other local factors (RSLR scenarios as opposed to eustatic), setting the historic trend to 1.7 mm/year is the correct approach.   (Just as a side note In more recent versions of the model we have allowed the user to specify the historic eustatic trend, recognizing that local historic trend data may have a different time period than 1900-2000 which is the time-period for the 1.7 mm/year estimate.)

That is the only place that historic trend is sued in the model so it is our practice to use 1.7 mm/year when using RSLR estimates.

Furthermore, if you use 1.7 mm/year, no subsidence effects will be calculated as a function of the difference between NWI and DEM dates.  Unless your dates are off by a lot and your subsidence estimate is great it is probably not worth the effort to adjust the DEM based on subsidence.  The amount of change in elevations is probably less than the model would show sensitivity to.  Good luck in your modeling!

Sorry about the delay in response:  The SLAMM salinity module is still largely experimental and inadequately documented I'm afraid.  Unless we get some additional funding to develop, document, and test the model it's likely to remain primarily shelved.  In SLAMM  version 6.3 we added a capability to import salinity as a function of SLR and rivermile or to import salinity using time-varying raster maps.  This requires an external salinity model, however.  This is likely the direction of future salinity modeling in SLAMM as hydrodynamic salinity models certainly seem to be the state of the practice as opposed to steady-state salt wedge models.

The WA work was never published and I'm not sure of the plans to publish the GA work at this time.   The model did seem to work well in these locations -- and the conformation to data at low and high tide was especially good in Georgia as it showed that the model could predict reasonable salinities given an elevation change in the "salt water head."  But it remains a very simple geometrical salt wedge model that is not by any means universally applicable. 

Hi Tom:  Thanks for the thoughtful post.

The code does attempt to account for erosion that exceeds one cell width in a given time step.  I did step through this in the compiler's "debug mode" and thought everything was working properly at the time.  However, you are right in that  we often run with large enough cell sizes and small enough erosion rates that we may not have noticed if there was a problem given a prediction of multi-cell erosion in a single time step.  I'll look into that portion of the code again ASAP and see if I can identify a problem there.  

We have tested the sensitivity of the model to erosion parameters and found the sensitivity to be smaller than the other parameters, but certainly not zero.  

You have an interesting point about the marsh to open water interface.  If a tidal flat is produced between the marsh and open water interface it is assumed to be protective of the marsh in terms of erosion until the tidal flat itself is inundated or erodes away.  This further desensitizes the model to marsh erosion parameters.  I like your suggestion of allowing marshes within the plus or minus 1 HTU range to experience erosion regardless of what is in front of them (omitting a dike, of course!)  I will look into making this an option in the model for future model versions.  

I'll let you know when I get a chance to test the code further with respect to both multi-cell erosion and the marsh-to-open water interface.  We are looking for opportunities to continue to make the erosion portion of the model more sophisticated in general.

Best regards -- Jonathan

Thanks for sending me that file.  For some reason all of your distributions were set as "uniform" with the minimum value greater than the maximum.  The interface shows a "distribution error" but if you then leave the setup without fixing the parameters the error prevents you from getting back into the setup to fix the problem.  I have fixed that and this should not be a problem in future versions.  I will send you a version of your file with the minimum less than the maximum for your testing purposes.

Remember that each distribution acts as a multiplier on the point estimate.  This is designed so that a single multiplier can be relevant to multiple subsites that may have slightly differing parameters. 

Can you email me the SLAMM6 file?   That will help me find the problem quickly.  Thanks!  -- Jonathan

Here's a start to answering your question:

The mangrove accretion rate is now editable and not "hard-wired" to 7 mm/year.

1.) the MLLW that is the mangrove lower boundary is "mean-lower-low water" for each subsite defined.  That is the mean tide level minus 1/2 of the "GT Great Diurnal Tide Range" in the site or subsite parameters.
2.) erosion will be triggered based on sufficient fetch over open ocean, estuarine water, or riverine tidal water (not tidal creek at this time)
3.) yes, at this time the swamp erosion parameter is used if erosion is triggered.
4.) anytime a mangrove is present, mangrove accretion will control the accretion.

There is another problem that could cause this error.

If under file setup the "base output file name" has an invalid character for a file name or points to a nonexistent directory this error will be raised.  I have improved the error message in our code base and it will be more clear in future versions.  For now, please leave that section blank and see if that solves your problem.

Try un-checking the box to write to MS Word -- J

Hmm, when is this error raised?  When writing results to Word?   If so, try saving your maps to gif instead... 

What version of the model are you running?  Please upgrade to 6.2 if you are not already using that. 

If exporting data to Word you must have the fully paid version of word and not word starter for the software to work.

If you give me more information about which version you are using and what steps you are taking precisely when using the model I may be able to provide more information.   Good luck -- Jonathan

Also, as you are modeling Grand Bay, I hope you are aware of this:

http://warrenpinnacle.com/prof/SLAMM/TNC/SLAMM_MS_Grand_Bay_Report_4-22-2011.pdf

Best regards -- Jonathan

Here are two sets of example study files for model testing.  Let me know if any of you have problems with either of them.

http://warrenpinnacle.com/prof/SLAMM6/Examples/Stmarks_SLAMM_6.2.zip

http://warrenpinnacle.com/prof/SLAMM6/Examples/S1_puget.zip

This is an old thread but this paper comes to mind:

http://onlinelibrary.wiley.com/doi/10.1029/2010GL045489/pdf

Limits on the adaptability of coastal marshes to rising sea level
Matthew L. Kirwan, Glenn R. Guntenspergen, Andrea D'Alpaos, James T. Morris, Simon M. Mudd andStijn Temmerman
Geophysical Research Letters
Volume 37, Issue 23, December 2010