I think this document may be of some use to you:

https://docs.google.com/spreadsheet/ccc?key=0ArsPAkgK5ZypdE5FS0twUXVJRVg0a0N1T0kyX1hDamc#gid=0

They're the same size.  Currently inputs are required to be 100% of the cell size.  As cells evolve there can be partial conversion of cells that would be reflected in tables of data but raster outputs show the dominant class in a given cell.   Best -- J

Wetland succession under SLR is entirely driven by the SLAMM decision tree (page 40 of the SLAMM 6.2 tech doc, and then more detail in the category-by-category description of wetland fate that follows...)

Vegetated tidal flat is a rarely-used category and, unless salinity is modeled and specific salinity rules are set up, SLAMM has no way of predicting whether a flat would have vegetation or not.  Therefore it will never be produced by SLAMM.

Tidal swamp will not be produced unless salinity is being explicitly modeled or if a polygon is designated as a "freshwater influenced" zone in which dry lands or non-tidal swamps would convert to tidal swamps if inundated. 

The rigidity of the SLAMM decision tree is something that we plan on addressing in future years to assist in site-specific modeling that doesn't fit in with the primary conceptual model.

Best regards -- Jonathan

OK, sorry if it's an error in the installer!  -- J

Windows 7 (and probably is very picky about allowing software to write to files in the PROGRAM directory.  There is an ini file in the same directory as the executable that saves the recently used files list. 

For this reason, the default installation location is to the desktop.  The model may also be installed to any directory for which the user has "Read-Write-Execute" permissions.  To change the permissions of a folder, see page 4 of this document http://water.epa.gov/scitech/datait/models/aquatox/upload/installationguide31.pdf

Hi Hayley:

It is certainly possible that the area is too large (especially if combined with a very small cell size).  I have not seen an "integer overflow" myself.

I assume you are using the 64-bit version of this software now available through the forum?  (http://warrenpinnacle.com/SLAMMFORUM/index.php?topic=201.0)  That truly helps with memory issues if you have a 64-bit machine and more than 4GB ram.

One helpful tool is at the bottom of the "file setup window" that tells you the memory utilization in GB (you may need to recount to get this).  If that exceeds 2GB in a 32 bit system then you'll likely be in trouble.  The sky is more the limit with a 64 bit machine, depending on the RAM installed.

If this problem persists and you cannot work around it, consider putting your source data on FTP and we will reproduce the problem here in "debug mode" and try to help you get beyond it.

Good luck!   -- Jonathan

Unfortunately modeling well up a river is pushing your domain to or beyond the edge of what the SLAMM model can be expected to do without explicitly accounting for salinity and model artifacts are to be expected.  More thoughts below:

QuoteWe are seeing salt marshes in the output files up and down the river.  We would like to restrict salt outputs anywhere north of where they would realistically occur.  Is it possible to break up the geographic component models at a designated point and only allow salt outputs in the southern extents? note:we did not use the salinity model in the first SLAMM run.

I'm afraid this is not possible without code changes.  You can designate a zone as Freshwater influenced which changes the decision tree.  However, once marshes get to a certain elevation and are regularly tidally flooded they will be assumed to be converted to regularly flooded marshes (note part of the reason this is not called "salt marsh" in the model is that we usually are not explicitly accounting for the salinity of the water the marsh is "regularly flooded" with.) 

2)      We noticed a lot of irregularly flooded marsh in the output, some of which didn't make sense to us.  There are many examples of tidal swamp or tidal fresh marsh becoming irregularly flooded marsh.  This might be related to salinity above, but we would like to better understand the model behavior that causes this particular transition.

The SLAMM freshwater model is based primarily on succession of marshes seen in classic large estuaries like in Georgia where there is a secession, based on salinity of tidal swamp (least saline) followed by tidal-fresh marsh, followed by brackish marsh (irreg. flooded) followed by salt marsh (reg. flooded and most saline).  In the absence of a salinity model, in a freshwater influenced zone, we must take frequency of inundation as the best surrogate for salinity that we have.  Therefore tidal fresh marshes convert to irregularly flooded marshes. 

We have in a proposal for SLAMM 7 that will produce a more flexible decision tree, enabling the decision tree to be editable and more applicable to special cases such as yours.  Unfortunately it won't be available for several years, even if funded...

Definitely not normal.  Hard to tell if it's a model error or a problem with your input files.

Some questions -- what is the habitat type there?  Are you modeling dynamic accretion feedbacks (accretion as a function of tide range)?  Have you rendered your elevation map to ensure that that is not the source of the strange patterning?

-- J

Since we started generally working with cell sizes less than 30m, the state of our practice has been to not use the overwash model.  It produces streaky unreasonable output at under 30M and we have not had funding to update and refine the model.

That being said, the model is described in the Tech Doc as follows:

Overwash
As erosion of backshore and dune areas occurs and as other lowlands are submerged, wetlands on the lee side of coastal barriers are subject to conversion due to overwash, the process by which sediments are carried over the crest of the barrier and deposited onto adjacent wetlands. This process is simulated only for areas having a beach and only during the time step in which the lowland is breached.

SLAMM default assumptions are that 50% of the adjacent transition marsh and salt marsh, and 25% of mangrove (if present) in the adjacent 500m to lee is converted to beach and tidal flat; the percentages are professional judgment based on observations of existing overwash areas (Leatherman and Zaremba, 1986). Beach migration occurs as well with estuarine beach within 500m of the ocean beach advancing by 60m. The front edge of the ocean beach will recede by 30m. Dry land adjacent to ocean beach will be converted to ocean beach. These professional judgments may now be edited as part of the sub-site input parameters.

SLAMM 6 assumes that a barrier island or narrow peninsula is present when there are estuarine waters, salt marsh, scrub-shrub, irregularly flooded marsh, or mangroves within 500m to lee of the front edge of an ocean beach. The user may specify the frequency of large-storms during which overwash is predicted to occur. All overwash effects are estimated to be localized to the 500 meters to the lee of the front edge of the ocean beach. The 500 meter cutoff may also be edited as a model parameter.

The parameters are described below along with their defaults:

Max Width Overwash (m)   500

The model needs to interpret which lands are subject to overwash.  In this case, a horizontal determination is made.  If a spit is found with ocean beach on one side and fresh waters on the other of less than 500 meters then every large storm this spit is assumed to be subject to the same overwash.

Beach to Ocean Overwash (m)   30

This much ocean beach is converted to open ocean from an "overwash event."

Dryland to Beach Overwash (m)   30

If dry land is up against beach, this much dry land is assumed to convert to beach as part of the barrier island migration.

Estuary to Beach Overwash (m)   60

On the back side, this much estuary is assumed converted to beach as part of the migration.

Marsh Pct Loss Overwash (%)   50%
Mang. Pct. Loss Overwash (%)   25%

If marsh and mangrove are present on the horizontal spit being overwashed this much of these categories are assumed lost (converted to beach), distributed evenly across the island.

This model, while very simple, has been applied with site specific data by USFWS in modeling Chincoteague island.  These parameters can be varied on the subsite basis.  Still, we hope to make improvements in this model some time in the near future.

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:

http://warrenpinnacle.com/prof/SLAMM6/SLAMM6_64.exe

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

http://warrenpinnacle.com/prof/SLAMM6/SLAMM6_32.exe

Here are direct links to the new documents

http://warrenpinnacle.com/prof/SLAMM6/SLAMM6.2_Technical_Documentation.pdf

http://warrenpinnacle.com/prof/SLAMM6/SLAMM_6.2_Users_Manual.pdf

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:

http://warrenpinnacle.com/prof/SLAMM6/SLAMM6.2_Open_Source.zip

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

  -- Jonathan

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

Marco writes:

I have checked the project rasters. The main issue is that the project is really big. If you are tracking all cells the project size is 61 GB of RAM memory . This can be reduced 2.7 GB by not tracking blank cells and high elevations. However, if you try to open the map or executing with show maps on screen option selected, then you need at least 10 GB of memory (I did not get any error message except that the map was too big to open on my computer). This means that first you need at least  a 64-bit version of SLAMM (I can send you a copy if you want), and second you need enough RAM memory to support this project.

If your available RAM memory is not that big, then probably the best course of actions is to split the study area in more manageable sizes, eliminate the not useful areas full of no data and/or reduce the cell resolution (3 m is a pretty small cell size ...)

Glad that the problem is solved, except that we routinely use "no-data" cells to designate blank areas in our models.  Therefore, I was stumped by your question.  Glad it's fixed anyway.  -- J

Each data value in the DEM file is the mean elevation of each cell.  Each data value in the slope is the slope of each cell.  It is generally derived from the DEM file.  The units of the DEM file must be meters (generally with an NAVD88 vertical datum) and the units of the slope file must be degrees.   The slope is relevant because SLAMM can calculate partial cell conversion (and sometimes hydraulic connectivity is affected by the slope as well).

See the section on Input File Requirements in the Tech Doc.   Best regards!

-- Jonathan

It sounds to me like a bug somewhere but I haven't seen that bug.  I am emailing my team and also sending you a link to the latest version of the code.   For general information, we recently got permission from USFWS to release SLAMM 6.2 (64-bit) publicly as soon as we get around to posting it!