January 20, 2018, 08:14:05 AM


Due to SPAM attacks, new members must be approved before posting.  Please email jclough@warrenpinnacle.com when registering and your account will be approved.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Jonathan S. Clough

Model Formulation & Parameters / SLAMM DMMT Webinar
September 28, 2017, 07:23:42 AM
On November 3rd, at 10:30 AM EST, Warren Pinnacle Consulting Inc. will present the results of a multi-year sea-level rise modeling project supported by the New York State Energy Research and Development Authority (NYSERDA). This project has produced a new decision-support tool designed to help decisionmakers understand the benefits of different adaptation strategies for wetland management under uncertain future conditions. The presentation will focus on background of the project and results from three New York county case studies, as well as presenting a tutorial for users interested in learning how to use the tool.

SLAMM Marsh-Management Tool
Friday, November 3, 2017

10:30 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr 30 mins
After your request has been approved, you'll receive instructions for joining the meeting.

Need help? Go to http://help.webex.com.

Prioritization of marsh-management strategies can be a difficult undertaking. Ideally, a manager could evaluate the relative benefits of adaptation strategies and maximize wetland benefits while considering uncertainty both in future sea-level rise and dynamic marsh response. Warren Pinnacle has developed a modeling framework to evaluate the costs and benefits of management strategies while accounting for these uncertainties using the SLAMM marsh migration model. Model results are combined with ecosystem-valuation assessments from stakeholders that define a set of relative "wetland benefits" (e.g., habitat preservation, flood protection), and each site's wetland benefits can then be projected into the future and compared to the estimated costs for each adaptation strategy. By calculating the "wetland benefits per estimated cost" ratio, one can identify the most effective marsh management strategies.

Now on GitHub https://github.com/WarrenPinnacle/SLAMM6.7

Editable Max Fetch Threshold for Marsh Erosion -- Marsh horizontal erosion rates will now be applied when an editable marsh fetch has been exceeded for each marsh cell (previously this was hard-wired at 9km and this value will be loaded as a default into older SLAMM6 simulations.).  The threshold may be edited on a subsite by subsite basis.  (This parameter is not relevant if the wave-energy erosion submodel is being utilized.)

We meant to add this as a feature of SLAMM 6.7 initially, but got so caught up in the new fancy wave power formulation that we forgot to modify the basic model.

Also -- the "Last year of simulation" variable is always utilized even if "run specific years is selected."  The interface was modified to make this more clear.
Written by Warren Pinnacle Consulting, Inc. scientists.  The paper is open access:


• Marsh fate modeling was applied to coastal NY State at a 5 m horizontal resolution.
• Simulation results predict extensive marsh losses in microtidal regimes.
• Results also indicate changes in the composition of marsh types.
• An uncertainty estimation of model results was also reported on.
• Uncertainty results suggest output variability is primarily due to SLR signal.


The Sea-Level Affecting Marshes Model was applied to coastal New York State at a 5 m horizontal resolution to investigate marsh conservation and potential migration under multiple sea-level rise scenarios. Feedbacks between sea-level rise and marsh accretion rates based on mechanistic modeling were included. Simulation results predict extensive marsh losses in microtidal regimes behind the barrier islands of Long Island, vulnerable dry lands on barrier islands, and opportunities for upland migration of coastal marshes. Results also indicate changes in the composition of marsh types. Confidence of predictions due to model parameter variabilities and spatial data error were estimated with the uncertainty estimation module. Likelihood maps of land cover changes were produced. Uncertainty results suggest that variability in land cover projections is mostly due to the wide range in potential sea-level rise signals by 2100 while impact from uncertainties in model parameters, spatial data errors and linked models is less significant.
Dear Colleague,

We are pleased to announce a webinar to present the results of our updated Sea Level Affecting Marshes Model (SLAMM) to work more effectively in California Estuaries.

This webinar is open to the public so we encourage you to share the link to thee webinar (below) widely with any interested colleagues.

Project Overview

The Nature Conservancy (TNC) funded Warren Pinnacle Consulting Inc. (WPC) and Environmental Science Associates (ESA) to collaborate with us on an initial phase to revise SLAMM for California estuaries by updating the habitat classifications, conceptual models, and decision tree pathways for multiple types of California estuaries including seasonally closed.

The Sea Level Affecting Marshes Model (SLAMM) (http://warrenpinnacle.com/prof/SLAMM/ ) has proven useful in other geographies to assess the vulnerability of coastal habitats to sea level rise and to identify marsh migration pathways. Its relative simplicity and modest data requirements allow application at a reasonable cost. SLAMM uses topography and parameterized physical conditions to predict the evolution of marsh habitats in response to sea level rise. The model does this by traversing a decision tree simulating changes in tidal marsh area and habitat type in response to long-term sea-level rise by accounting for five dominant processes involved in wetland conversion: inundation, erosion, overwash, saturation, and accretion. The model uses a complex decision tree that incorporates both geometric and qualitative relationships to model habitat conversions in coastal habitats through spatial relationships (e.g. adjacency, elevation). The decision tree was developed for the Georgia and South Carolina coasts and therefore works well for East and Gulf Coast estuaries.

However, until now SLAMM has not had the correct habitat types, physical processes, or decision tree pathways to properly model marsh transitions in response to sea level rise for many West Coast estuaries.

We drew from the Inventory and Classification of West Coast Estuaries to develop this SLAMM update for the three different Coastal and Marine Ecological Classification Standard (CMECS) estuarine classes: Embayment, Riverine, and Lagoonal. For this, "Phase I," we developed physical conceptual models, ecological conceptual models and decision tree pathways to be incorporated into SLAMM to model marsh response to sea level rise for each of these classes of California estuaries. We used best available data from representative California estuaries to explore relationships between GIS data inputs into SLAMM to help develop our physical and ecological conceptual models and decision tree pathways. We worked closely with NWI and other experts to crosswalk NWI categorization into SLAMM habitats. We also received great peer-review across expertise to improve our update to SLAMM to work for California estuaries. As a result, SLAMM 6.7 works for the great diversity in estuary type and morphology found along California's diverse coast. Other updates included in the new versions of SLAMM include: editable sea level rise curves, "Run-record" file, improved modeling of marsh erosion, and quantification of carbon sequestration for different scenarios.

We look forward to presenting these and other updates to SLAMM to you in the webinar 9:30-11:00 a.m. PST, Thursday July 28, 2016.

Webinar info is below please allow time to download any software plug-ins necessary.


Join Skype Meeting      


We are pleased to announce a symposium on  SLAMM: "the maturation of a landscape-ecologic model," part of the International Society for Ecological Modelling Global Conference 2016 in Baltimore MD, on May 8-12 of 2016.


The deadline to submit an abstract for the symposium on is Oct 16.  http://www.isemconference.com/submit-abstract.asp

Early registration deadline is Dec. 18 and the early registration fee is $520; after that date the standard fee will be $620; the standard student fee is $300. We anticipate fruitful interactions among participants as part of the symposium. Unfortunately, the field trip to Blackwater Wildlife Refuge has fallen through, but if there is interest, we may be able to prepare a guide for a self-guided tour.

We hope to see and meet many SLAMM users there.
Model Formulation & Parameters / SLAMM 6.2
March 28, 2014, 06:25:43 AM
I am happy to announce that we have completed the 64-bit version of SLAMM and it is ready to be downloaded and installed.  The installer is located here:


The Technical Documentation and Users Manual is included in the installer which (not surprisingly) requires a 64-bit version of Windows.  However, a 32-bit version of the installer is located here for those who don't have 64-bit machines


Here are direct links to the new documents



We performed major revisions to both documents-- changing the structure of the Tech Doc to be more logical and checking all of the "flow-chart" logic at the back of the document against the source code.  The User's manual has been made current to document all new interface updates.

The source code is also available for download directly through the model interface or here:


Many thanks to USFWS for funding this step forward in model development.

  -- Jonathan
Using SLAMM / Latest Versions of SLAMM
March 28, 2014, 06:22:31 AM
SLAMM 6.7 was released in July 2016. 

This version is being updated in an on-going basis at GitHub https://github.com/WarrenPinnacle/SLAMM6.7

This includes updates to installers, executable, source code, and documentation.

A summary of recent releases may be found here:  http://warrenpinnacle.com/prof/SLAMM/SLAMM_Versions.pdf
August 01, 2013, 03:20:26 PM
 Due to SPAM attacks (hundreds each day), new members must be approved before posting.  Please email jclough@warrenpinnacle.com when registering and your account will be approved.
Using SLAMM / Question and answer from new user
June 19, 2013, 06:25:05 AM
Quote1. When I save simulation, it is very common to have the error show "unable to write to C:\Program Files\SLAMM6.2Beta\SLAMM6.INI."

It is not recommended to install to c:\program files as Windows 7 tends to guard that directory jealously.  Make sure you have read-write-execute privileges to whichever directory you are installing.

Quote2. When I have done the elevation analysis and want to look at the Histogram, I am not able to select any of the land type (all of them are in grey color).

There does seem to be some sort of an intermittent interface bug in this version.  We'll look into it.  What was happening to me was not that everything was grayed out, but rather that the whole interface could not be clicked.  I did manage to find a workaround, I think by closing both the histograms and elevation analysis windows and reopening again.  Try clicking around a while and maybe it will unfreeze.  Meanwhile we'll try to reproduce and fix the problem.
Model Formulation & Parameters / MTL - NAVD88 Parameter
January 24, 2011, 02:02:19 PM
It has become clear to me that the documentation is not particularly clear with regards to this parameter.  This is the MTL elevation (relative to some vertical datum) minus the NAVD88 elevation (relative to that same vertical datum).

In other words, if you have a NOAA gage such as http://tidesandcurrents.noaa.gov/data_menu.shtml?unit=0&format=Apply+Change&stn=8452660+Newport,+RI&type=Datums

And you see the following lines:

MTL           1.148  Mean Tide Level
NAVD          1.199  North American Vertical Datum

In this case, the parameter would be 1.148 - 1.199 or negative 0.051  (-0.051).

To get the correct sign (+-) that SLAMM expects using VDATUM, convert from MTL to NAVD in units of meters.

I have a question to ask you. since the test data of S1_puget, includes six text format data ,and in each text format data, six parameters are list on the top,i want to ask whether the parameters of xllcorrner and yllcorrner is the up-left corrner coordinate value ,and what is the projection system of the coordinates?

By the way , I have registered in SLAMM FORUM twice before, and the first time is in February. Each time i received a email telling me the request would be reviewed and approved, such a long time has passed, I still have not receive another email yet, would you please tell me why.
 thank you.

I am sorry that you are having difficutly registering for the SLAMM Forum.  I have had many many spammers attacking the forum so need to approve all people.  Unfortunately your URL shows up again and again on STOP FORUM SPAM's list.  So I assumed you were a spammer and banned you.

Please re-register using this email address and I will approve you immediately.

For information on the ESRI ASCII format please see this article.  http://en.wikipedia.org/wiki/ESRI_grid  "LL" stands for "lower left"

SLAMM does not care what projection is used; however to reduce error, an "equal area" projection should be utilized.
SLAMM has long assumed that salt water will inundate any non-diked dry lands or fresh water wetlands that fall below the "salt boundary."  For the most part this seems to have been an effective assumption (our "time-zero" or "current condition" model results have never extensively indicated that there are natural ridges protecting low-lying dry land or freshwater wetlands from saline inundation).

However, a few recent sites have challenged this assumption and therefore we have implemented an optional connectivity sub-model within SLAMM following the methods documented in the paper below.  Initial tests look promising and provide for interesting results.

Here is the paper, mentioned above: Poulter, B. and Halpin, P. N. (2007) 'Raster modelling of coastal flooding from sea-level rise', International Journal of Geographical Information Science, 1 - 16...   http://portal.acm.org/citation.cfm?id=1452072.1452075

One of the assumptions that we have followed from this paper "We also assumed that the vadose zone (unsaturated soil) and surface roughness did not affect inundation because the time (t) for diffusion was infinity (i.e. the process of sea-level rise overwhelms diffusivity constraints)."   This matches well with SLAMM's large-time-step configuration and the attempt to calculate what will happen "at equilibrium" when the sea level rises by a certain extent.  (In other words, SLAMM is not likely to turn into a hydrodynamic model any time soon.)

I will update this thread when the capability has completed its testing and documentation and is ready for public consumption.  -- J
Using SLAMM / MTL to NAVD88 Correction
March 29, 2010, 11:52:41 AM
The question was asked:
QuoteFrom: rloiselle   on: March 26, 2010, 02:49:06 PM
Examining our elevation data for conversion errors in the data processing of date and datum conversions, stated on pg 9 of the manual, has lead us to question whether we should be adding or subtracting the difference between MTL and NAVD88 from the DEM elevations.  In our mind, because we want to set the NAVD88 elevations to an MTL datum, and our NAVD88 elevations are located below our MTL, we feel like we should be adding that difference to bring our elevations up to the MTL level.  My understanding is that the East Coast MTL is lower than their NAVD88 and so subtracting that difference would bring their elevations down to MTL?

The NAVD to MTL correction (or more generally [any vertical datum] to MTL correction) is utilized to convert the elevation data maps from a fixed vertical datum to a datum based on the Mean Tide Level of the site.  It is defined as MTL minus NAVD88 based on the following type of data from a NOAA gage:

( e.g. http://tinyurl.com/yepwwkb )

          MTL           8.235  Mean Tide Level
          MSL           8.224  Mean Sea Level
          MLW           7.440  Mean Low Water
          MLLW          7.025  Mean Lower-Low Water
          LWI           1.27   Greenwich Low  Water Interval (in Hours)
          NAVD          7.176  North American Vertical Datum

You can see from these results that, at this site, an elevation of 1.0 meters in NAVD88 units will actually be located below MTL.

In this case, the MTL minus NAVD88 will be roughly 1.06 meters.  As a general rule, if your MTL-NAVD parameter goes up then elevations go down.

If you are using the NOAA VDATUM product: (http://vdatum.noaa.gov/) you output "height" in "meters" and then use "MTL" as the input and "NAVD88" as the output.  That should give you the number that you are looking for with the proper units and sign.
On February 23rd, the Ecosystem Based Management (EBM) Tools Network invited Jeff Ehman and myself to give a demonstration of our products' interfaces.

The organizer wrote
QuoteFor all of you who had to miss today's excellent webinar on SLAMM and SLAMM-View or would like to see parts of it again, a video and audio recording of the webinar can be downloaded from the following FTP site.  It is a Windows Media Viewer file.


After following the above link and reaching the natureserve site, my recommendation is to "right click" on the link and "save file as."  Then download the 100 meg file and view at your leisure.  

-- Jonathan
A question was asked:

QuoteWhy do my model results look different when I select to "ignore dikes" as I have no dike layer associated with my simulation?   I am using the elevation pre-processor due to a low-vertical-resolution elevation coverage.

I responded: I think I now understand the source of this difference.

We have some logic in the pre-processor that will "boost" dry lands and fresh water wetlands above the "salt boundary" if they fall below the salt boundary.  Say, for example, that you have a contour interval of 10 feet.  In your digital elevation map (DEM) you might have a lot of dry land that, according to the NED, is below that 10 foot contour.  I have found that the DEMs from the NED assign pretty much everything under the lowest contour to some fairly arbitrary low value (Jim Titus once told me how they assigned the shoreline but I can't quite remember... maybe MHHW?... anyway).  Unless the pre-processor intervenes, a whole lot of fresh marshes and dry land convert immediately. 

To solve this problem we "boost" all of those dry-land elevations below the "salt boundary" to above the "salt boundary" (or "salt elevation.")  Like wetlands we use a uniform distribution moving away from the "direction offshore" up to the elevation of the lowest contour (this is now editable as the "upper bound" in the elevation analysis screen).

Recently I had a problem when running a site with dikes.  Land behind dikes should never be "boosted" because it often falls below the salt boundary due to the seawalls surrounding it.  I tried to run a simulation with dikes removed and did not find any conversion of dry lands that I knew were well below the salt boundary.  That was because the dikes were not being included so the software assumed that these lands needed to be "boosted."

Therefore I put in this piece of logic:

   If a cell is protected by dikes OR if the dikes are not included, then do not boost the dry land elevations.  (1-8-2010)

I did not realize that this meant a site would have different results if the site has no dikes file and if the "use dikes" option is changed.

The upshot is, with the current version, please do not run the model with "dikes turned off" if you don't have a dike file to begin with.  I guess that I need to change that logic so that it knows whether a location is diked or not, even if dikes are not included so that SLAMM knows which land to boost and which land not to boost.  (Previously the software was not even loading in the dike layer as it wasn't planning on "including dikes."   So I will have to change that logic in the software.) But in the short run, leave "include dikes" on and that will give you the "correct" answer for this site.  I'll also change the code so that it reads

   If a cell is protected by dikes OR (if a dike file exists AND if the dikes are not included), then do not boost the dry land elevations.  (2-22-2010)

That line of code should prevent further confusion as you experienced though it is not perfect (as it does not discern which lands should remain "boosted" due to their non-diked status and which lands should not).

I have to say that I have become a lot more comfortable using the model when there are high-vertical-resolution elevation data available.  This whole pre-processing and "boosting" set of procedures is really trying to make the best of a bad situation.  The model assigns uniform distributions to each wetland type from their lowest estimated range to their highest.  LiDAR data have shown us that some wetlands are perched precariously above their lowest elevation (the elevation at which point they will convert to tidal flats or open water) and other wetlands are safely located high above it.  These initial-condition elevations therefore make a difference in the extent and timing of wetland-loss predictions.  When we are forced to use the pre-processor, lacking all of that information, we just assign the wetlands with elevations over their existing range.  Boosting dry lands is similar.  You need to hope you have the correct salt elevation assigned and there is not some other factor (like tide range reduction) that allows dry land to persist at a lower elevation.

Also, when running the model with LiDAR, you have a good sense of whether your MTL to NAVD88 correction is working, and your tide ranges are parameterized properly because, if not, then you have problems with your "time-zero" results or elevation analysis.  With no LiDAR data, the model just "corrects" elevations that do not match its conceptual model, so you have no such check on your input parameters...

The uncertainty of the pre-processor is something that should be firmly caveated in any discussion of model results.  "Model uncertainty for this site is quite a bit higher due to the absence of high-vertical-resolution elevation data."

I hope that this resolves your problem, thanks for being such helpful beta testers, and I'm sorry that I didn't think of this possibility when solving my other problem with what seemed like an innocuous line of logic!  Let me know if your problem persists or if you find any other strange results.

-- Jonathan
Using SLAMM / Vertical/Horizontal Streaks in Model Output
December 14, 2009, 07:19:27 AM
FAQ:  What are these vertical/horizontal streaks in model output:


QuoteSoil Saturation: 

Maps of SLAMM results occasionally include green linear stripes of fresh marsh moving through what was previously dry land (red).  These stripes are a result of the SLAMM soil saturation algorithm which is geographically quite simple.  The water table for each cell is estimated by moving unidirectionally in the off-shore direction and finding the nearest wetland cells.  This water table is then adjusted for the estimated increase in the fresh water table due to sea level rise.  If the estimated water table is greater than the elevation of the dry land, saturation takes place and the dry land is predicted to be converted to wetland.

Because of the unidirectional search algorithm, horizontal streaks may appear on model results as shown above.  Despite this minor loss of geographic realism on output maps, the algorithm does provide useful information about the susceptibility of dry land to water saturation due to changes in the water table.
December 11, 2009, 06:35:53 AM
SLAMM6 has arrived, don't miss it in the Model Formulation Forum http://warrenpinnacle.com/SLAMMFORUM/index.php?topic=55.0

The interface is superior.  The core code that generates SLAMM5 predictions is all but unchanged.  The model has strong backward compatibility to SLAMM5.  The code is open-source.  Feel free to post new questions or thoughts about the SLAMM6 interface in this forum.
Please use this forum to discuss successes or problems compiling the open source code so that we can continue to refine this process.

As I noted in the instructions for Open Source Compilation, the OpenGL library that we used for this project is not available on the web as the website went down.  However, I found a way to access it using the "Internet Archive"  This link should do the trick for now:


If this doesn't work, please contact me directly and I will see what I can do to find another link or help the file compile.  I don't have permission to distribute the OpenGL library at this time but am trying to contact the developer. 

Also, please let me know about successes / failures compiling on other platforms such as Delphi 2010, Lazarus, etc. Thanks!

FYI, here are the compilation notes:


SLAMM Open-Source Code Distribution, 11/30/2009
Code Produces SLAMM 6 beta
Code is object oriented Pascal written with Borland Delphi 2007 development platform

This code is licensed under the Common Public License (CPL), see SLAMM_License.txt


To compile this source code as-is, the following steps must be taken:

1. Install Borland Delphi 2007 for WIN32.   It is recommended that the latest Delphi 2007
   hot-patches and updates be installed though this does not appear to be strictly necessary to
   compile this particular code.

2. Unzip this zip file into a single directory.  This will be your main program directory.

3. Download the Delphi OpenGL Toolkit: http://www.delphi3d.net/ ; The resulting file structure
   must be placed in an OPENGL directory off of the main program directory, including the
   FRAMEWORK folder.   

   IMPORTANT UPDATE 11/30/2009.  This website is down, hopefully temporarily.  I  will
   do some research as to other sites to download this library or link in an alternative
   library.  Unfortunately I am unable to distribute the library directly via request from the
   developer who writes:  "Please do not redistribute the Dot source code. If you want to share
   the Dot with others, please provide a link to www.delphi3d.net/dot instead, so people can
   download the latest version of the Dot from there." 

   As noted above, you may use the web-archive for now:

4. Select File, Open Project, and Load SLAMM6.dproj file  Executable may be produced by selecting
  "Build" from the Project menu. 

Please send questions to jclough (at@) warrenpinnacle.com

The SLAMM 6.0.1 model has now been released along with an updated Users' Manual and Technical Documentation

Start with the Release Notes here


You may download the Installer here


The Users Manual is located here, and also available as "context sensitive help" from the executable.


The Technical Documentation may be downloaded here


The open source code has been updated to match this latest version (Build 6.0.0008)


Sample input data may be downloaded here.  These data are provided for model testing only.


Please provide feedback and questions using these forums.  Ideas for new capabilities, bug reports, questions about existing capabilities, etc.

Thanks for your interest in the SLAMM model.  -- Jonathan Clough
Model Formulation & Parameters / Vertical Datums
November 11, 2009, 02:33:21 PM
A Scientist with National Geodetic Survey writes:
QuoteI'm writing to follow up on the question of how the tidal and geodetic datum offsets are applied in 6.0. In a nutshell, the issue is that in 5.0 the tidal / geodetic datum offset value for a single tide station was applied over large geographic areas where that relationship does not necessarily hold constant, therefore adding increasing sources of error/uncertainty in areas farther away from where the tidal geodetic relationship was established.

Jonathan Responds:

I have to clarify a few points about SLAMM 5--

The tidal / geodetic datum could be and usually was defined within smaller polygons or "sub-sites" as we call them in SLAMM jargon.  This allowed us to utilize a gradient based on multiple NOAA tide stations or the VDATUM product when it was available.  In recent model applications we have defined sub-sites as regions in which differences in the vertical datum correction would be minor.  Given that the vertical resolution of our best elevation (LiDAR) is in the range of 5-10 cm we usually would define these areas as having differences of 1 cm or less.  Given the vertical resolution of our input elevation data, the tidal / geodetic datum uncertainty was almost always an order of magnitude or so less. 

Perhaps more importantly, there is an "unpublished" capability in SLAMM 5 to read a raster map of tidal / geodetic datum offset values which we produced using the NOAA VDATUM product.  We have used this capability in many of our SLAMM applications where VDATUM coverages were available.

When there was no VDATUM coverage and considerable distances between NOAA stations, we generally used a spatial interpolation between stations.  In a recent workshop, Allison L. Allen of Center for Operational Oceanographic Products and Services stated that, absent VDATUM results, interpolation of "MTL to NAVD88" between stations is the best manner of determining the "MTL to NAVD88" correction.   

In SLAMM 6 the only difference will be that the VDATUM Raster import capability will be "published" that is to say, written up in the technical documentation and users manual.  Given the fact that VDATUM is now nearly ubiquitous throughout the continental US, I think this should solve the problem for the majority of our users.